convore.json/groups/arc-runtime-project/bug-with-square-bracket/messages.json

[{"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306154165.609935, "message": "And fixed! :D https://github.com/Pauan/ar/commit/8cab0caba8f72e2c8bb0568fac13b52d16d222f5", "group_id": 9739, "id": 1151689}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306152202.8564301, "message": "Okay, this is really weird... it seems that when you use Arc's load, it breaks the square-bracket macro. To be more specific, it seems that Racket's reader is ignoring the custom reader macro defined in ac.ss, so [+ 10 5] is treated as (+ 10 5).\n\nThis doesn't happen with aload, but it does with Arc's load... but load calls read, so why doesn't it know about the square-bracket reader macro?", "group_id": 9739, "id": 1151373}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306152345.683943, "message": "Wait a second... sread is defined in Arc... but it just calls racket-read directly. Shouldn't it be parameterizing arc-readtable* first? Lemme see if that fixes it...", "group_id": 9739, "id": 1151389}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306162176.1229191, "message": "I'm confused by this, because I would have thought that current-readtable would have been already parameterized by arc-eval whenever Arc code was running.  Can you demonstrate this bug in base ar?", "group_id": 9739, "id": 1153463}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306162457.996711, "message": "Hm... not sure, it's possible I borked something on my fork, but... I don't think I messed with anything like that. I'll see if I can reproduce on standard ar.\n\nBy the way, it's not just when Arc code is running... for instance, the \"arc\" file calls (g load) in order to load files like \"arc3.1/strings.arc\". That's where I first noticed the bug.", "group_id": 9739, "id": 1153540}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306163009.047425, "message": "Oh, nevermind, they're basically the same definition. I was looking at the wrong spot. Weird.", "group_id": 9739, "id": 1153652}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306163063.41084, "message": "In any case, I'll try again after the merge. It's possible I broke something, or you fixed something.", "group_id": 9739, "id": 1153660}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306162947.461622, "message": "Hmm... I can't reproduce it. But ac.ss's definition of arc-eval is different, so I'll try again after I merge, and see if it's still a problem.", "group_id": 9739, "id": 1153645}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306163479.4508591, "message": "ah yes, perhaps current-readtable isn't being parameterized when the arc file calls (g load) directly.", "group_id": 9739, "id": 1153715}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306163576.196171, "message": "But, calling (g load) in \"arc\" doesn't cause any errors when I tested it, so I'm rather confused myself at why it broke on my fork.", "group_id": 9739, "id": 1153725}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306333700.035507, "message": "Hm... okay, really weird. I did a merge with official ar, and I'm still seeing it.\n\nWhy does racket-eval parameterize it anyways? Shouldn't it only be parameterized with ar-load and sread? Would there be any speed gains by not parameterizing current-readtable in racket-eval?\n\nWait... it already *is* parameterized in ar-load, so why is it parameterized in racket-eval?!", "group_id": 9739, "id": 1178810}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306336657.4595921, "message": "(though a way to explicitly override it, so it uses your readtable would probably be a good thing to have)", "group_id": 9739, "id": 1179578}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306337827.7525549, "message": "Hm... yeah, that seems like a tricky problem. Maybe what we want are two different ways to parameterize, a normal way, and a way to override a runtime's parameters.", "group_id": 9739, "id": 1179709}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306336525.9779069, "message": "I confused as to where the right place to parameterize is.  Originally we'd start up an Arc runtime, make whatever changes to the readtable, and it would just run.  So I was imagining that the readtable would be parameterized once when we went into Arc to eval something, which would include the REPL and any subsequent read's.  Now that an Arc runtime can be embedded (of which running Arc from the command line is a special case), where is the right place to parameterize?  If \"a\" is another runtime, and I say\n\n(a!read \"[+ 3 _]\")\n\nDo I want it to be using *my* readtable or a's readtable?", "group_id": 9739, "id": 1179553}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306337555.2660029, "message": "So if a is reasonable and uses Racket's stdout, like ar, then it'll go to the same place either way, right? And if a wants to do something funky, then that's a's business.", "group_id": 9739, "id": 1179669}, {"user_id": 32737, "stars": [{"date_created": 1306337977.5833931, "user_id": 32943}], "topic_id": 36419, "date_created": 1306336630.2441671, "message": "I think it should be the job of \"read\" to parameterize it, so it would be using a's readtable.", "group_id": 9739, "id": 1179575}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306337681.1040161, "message": "But then\n\n(tostring (a!prn \"foo\"))\n\nwouldn't work.  a's stdout would be restored to what stdout was when we created the runtime.", "group_id": 9739, "id": 1179677}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306337376.145951, "message": "I think having it use a's readtable by default is the right idea.  But a question is how do we want to support using implicit variables in runtimes.  One answer is that readtable's are *not* parameterizable in Arc, and so we just parameterize Racket's readtable down in the internals of read because we have to, but that's not visible to the Arc code.  Or, we say we do want to be able to parameterize things from Arc (such as readtable's if we want to), which means that having read parameterize it is the wrong choice because then it would be overriding my parameterization.  I wonder if I can figure out a way to use dynamic-wind to do the right thing, so that parameters would be automatically restored whenever we go into a runtime, and we wouldn't have to add code to every function like read that uses parameters?", "group_id": 9739, "id": 1179653}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306337480.2225649, "message": "On the other hand, if I say\n\n(a!prn \"foo\")\n\nI probably do want it to use *my* stdout, so having all parameters automatically restored to the runtime's version when we go into the runtime is probably the wrong thing to do.", "group_id": 9739, "id": 1179660}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306337529.0450349, "message": "Actually, I would expect that to use a's stdout too. :P But I would also expect a's stdout to be the same as your stdout, at least by default, since ar uses Racket's stdout port.", "group_id": 9739, "id": 1179665}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306340483.8566461, "message": "(By the way, ar-read already parameterizes, and on my fork, sread calls ar-read, so that's already been implemented. :P It doesn't parameterize read-string, though, so I should add in some tests for that and implement that)", "group_id": 9739, "id": 1180305}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306338288.18332, "message": "I don't see (tostring (a!prn \"foo\")) as a problem. As Pauan said, it's a's business what a!prn means.", "group_id": 9739, "id": 1179798}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306338546.368474, "message": "Here's a thought.  Imagine we had our own reader implemented in Arc.  Then we would choose whether we wanted to use an implicit variable (parameter) to select which parser to use or whether to use some other mechanism.  In my own code, I notice sometimes I start with using an implicit variable but I notice it isn't a good fit, so I take it out.  So perhaps we would want to use an implicit variable and perhaps not.  If we did, then we'd see why and how we'd want it to interact with runtimes.  In the meantime, I'm starting to like your suggestion that read would parameterize Racket's readtable internally, which would let us get something to work now and let us think about how we want to parameterize at the Arc level at our leisure.", "group_id": 9739, "id": 1179868}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306338548.8039081, "message": "Regarding readtables, I think they should be treated on the same level as namespaces, ideally. I'd like to be able to capture the current namespace, the current readtable, and the current set of framework extensions all at once, using a (current-language) form or something. (Dunno if I'd want the current parameterization to be part of that, but it's possible.)", "group_id": 9739, "id": 1179870}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306338803.267118, "message": "(tostring (a!prn \"foo\")) is important for getting different languages to work together.  For example, you've implemented your own favorite language on top of ar which happens to be incompatible with Arc 3.1, so Arc's web server won't work in your runtime; but you'd like to be able to use Arc's web server without having to rewrite in your language.  Now you're going to have Arc's web server responding to op's by calling functions in your runtime with stdout set to the TCP connection.", "group_id": 9739, "id": 1179940}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306339045.0217891, "message": "I don't see what you're getting at.... Suppose we have the ability to use namespaced macros by way of an 'nsmac macro. If I want to parameterize a's stdout to mine, I'll say (tostring (nsmac a w/stdout stdout (a!prn \"foo\"))).", "group_id": 9739, "id": 1179996}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306339551.8600781, "message": "From an axiomatic perspective, what I'm looking for are primitive building blocks out of which people can build what they want.  So from this perspective, having to add code to get around the runtime doing something that isn't wanted is the wrong approach; if someone doesn't want a runtime to do something they should be able to have it not do it in the first place.  Then if you want a system that automatically captures parameters in a runtime, you should be able to do that.", "group_id": 9739, "id": 1180134}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306340374.142983, "message": "I agree now that we should have read parameterize Racket's namespace.  Then we can figure out the more general question of how parameters should interact with runtimes when we have more examples.", "group_id": 9739, "id": 1180286}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306340033.413213, "message": "The problem is that then when you *do* want it to use a's stdout (or anything else) then you need to explicitly parameterize it. So you need to add in code either way, so I think it should be optimized for the common case.\n\nBy the way, you mentioned a runtime choosing whether to parameterize or not. Well, yeah. What I'm suggesting is that Arc's \"read\" parameterize, while still allowing non-Arc runtimes to parameterize or not, as they wish.", "group_id": 9739, "id": 1180221}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306343590.1927111, "message": "arc> (read \"[3]\")\n(3)\n", "group_id": 9739, "id": 1181037}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306343869.1737199, "message": "@Pauan I be checking in a fix shortly, now that I have a failing test.", "group_id": 9739, "id": 1181091}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306343315.9586439, "message": "I wouldn't want Arc libraries to limit the programmers who use them, but if someone encounters issues with composing libraries, I'd like it to be clear which codebase isn't conforming to its (informal) promises. If and when Arc's big enough to have a dependency network of independently developed projects, it would be frustrating for one person's idea of a fix to be another person's idea of a bug.", "group_id": 9739, "id": 1180956}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306342437.0528121, "message": "\"having to add code to get around the runtime doing something that isn't wanted is the wrong approach\"\n\nThen my point stands. The runtime shouldn't worry about whether (tostring (a!prn \"foo\")) uses my or a's stdout. If it goes to any extra effort to make it work one way or another, people will just have to work around it when they want the other behavior.\n\nI do think it would be likely for my runtime and a's runtime to both use the same lower-level interface to implement their stdout parameters, in such a way that my 'tostring affects a's 'prn. But even if \"a\" created a fresh parameter each time it's loaded, that would be no big deal, 'cause I could still use a's own tools to parameterize its stdout.", "group_id": 9739, "id": 1180740}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306342705.0008659, "message": "In fact, I'm a bit worried about the whole process here. If we're using two sub-runtimes, whose fault is it when they interact in unexpected ways? Maybe runtime A decides it has a better idea about how to use stdout, and it no longer parameterizes runtime B's stdout automatically.", "group_id": 9739, "id": 1180785}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306343245.780885, "message": "The runtime should be able to be simple.  Then you can wrap it something if you need to do something so that you can interact with it in the way you want to.", "group_id": 9739, "id": 1180929}, {"user_id": 32737, "stars": [], "topic_id": 36419, "date_created": 1306343614.2170031, "message": "Yeah, exactly, that. That's what I was working around, but readstring doesn't parameterize, so I need to fix that.", "group_id": 9739, "id": 1181043}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306343572.0071411, "message": "arc> (read \"[3]\")\n(fn (_) (3))\n", "group_id": 9739, "id": 1181031}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306343935.7983711, "message": "@rocketnia it was in reply to your previous comment, \"In fact, I'm a bit worried about the whole process here...\"", "group_id": 9739, "id": 1181113}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306343715.8243721, "message": "\"The runtime should be able to be simple. Then you can wrap it something if you need to do something so that you can interact with it in the way you want to.\"\n\nWhat's this in reply to?", "group_id": 9739, "id": 1181057}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306343560.4835119, "message": "Aha, I've been able to reproduce the square-bracket bug.  In Arc 3.1:", "group_id": 9739, "id": 1181028}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306343582.053128, "message": "In ar:", "group_id": 9739, "id": 1181036}, {"user_id": 32737, "stars": [{"date_created": 1306344140.0562651, "user_id": 25438}], "topic_id": 36419, "date_created": 1306343984.620043, "message": "By the way, I didn't find it with a string, it was while loading a file, so you'll want to test that it works properly with input ports too:\n\n(read (instring \"[3]\"))", "group_id": 9739, "id": 1181127}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306346646.5702419, "message": "@awwx Then what runtime(s) are you talking about wrapping, ar itself or A and B?\n\nIf you're talking about wrapping A and B, then if I wrap those to make a nicer interface to them, that *wrapper* is still code, and if it breaks I might want to \"fix\" it by sending a patch to project A and breaking other A users' code.\n\nIf you're talking about wrapping ar, then maybe what you mean is that runtimes like A and B should just be convenience wrappers over a common runtime, not end-application components, and that nobody should really have to deal with A and B beyond extracting components people have written in them. That's just fine, but I think interaction with stdout is on the application-component side of the scale, not the convenience-layer side. How A's application components interact with stdout is still A's business.", "group_id": 9739, "id": 1181687}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306347410.4671259, "message": "There are two approaches in general: we can anticipate problems and make more complicated systems to avoid them in advance; or we can make simple systems and then create strategies to resolve problems when they actually occur.  I don't claim that one approach is always better than the other; in fact I imagine that each approach may be better in different situations.  But ar is based on the second approach: every design decision has been made on the side of choosing smaller, simpler components.  I imagine at some point this will fail, and I'll need to back up and do something over.  (But to get me to back up I'll need to see an actual example of something not working).", "group_id": 9739, "id": 1181844}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306347441.792002, "message": "(or at least want to see an example)", "group_id": 9739, "id": 1181855}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306350945.3400509, "message": "Well, for an example, jazzdev made Jarc with dynamic scope and wrote some code that way, and then official Arc was released and had lexical scope. The solution? Ask official Arc to change to have dynamic scope (http://arclanguage.org/item?id=5529). No dice. Over time jazzdev brought Jarc in line with official Arc and had to rewrite a bunch of code so it could work again.", "group_id": 9739, "id": 1183076}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306351201.9862411, "message": "I said \"simple\", not \"broken\".  If you know of something that's not going to work, do share it.", "group_id": 9739, "id": 1183121}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306351210.940208, "message": "If you're waiting for a specific code snippet which demonstrates how good composability between codebases would simplify things, good luck. When composability is important, people tend to choose languages which already have good support for it.", "group_id": 9739, "id": 1183124}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306351786.2524929, "message": "I've been a contractor doing code maintenance for ten years.  I've seen all the *theories* people have for what will make software composable, and after the software architects have built the system and left to architect their next project, I've gone in and figured out out to work around their architecture so that I can integrate the software in *practice*.  So again, if you have some *specific* example of something that doesn't work, I'd like to hear it sooner rather than later, otherwise I'm going to continue to work on ar.", "group_id": 9739, "id": 1183234}, {"user_id": 32943, "stars": [], "topic_id": 36419, "date_created": 1306358069.7731531, "message": "Nah, nothing specific, and I'm sorry if I've been confrontational. No system I've ever seen has *all* the kinds of composability I want (even in my own designs!), and it often makes me feel doomed to writing code that a contractor will have to go in and maintain, which is very discouraging. I don't mean to discourage you too. I already program in Arc in ways that clearly identify which of my modules is buggy, or at least clearly identify it *to me*, and in ar I'll probably enjoy the same kind of non-issue. (I should write a wiki page about it.)\n\nAnyway, back on the topic of (tostring (a!prn \"foo\")), I was saying to go with whatever semantics were easiest, but all I really meant was that to me, I didn't share your intuition, so it was okay either way.", "group_id": 9739, "id": 1184404}, {"user_id": 25438, "stars": [], "topic_id": 36419, "date_created": 1306358204.290844, "message": "ok", "group_id": 9739, "id": 1184435}]