convore.json/groups/arc-runtime-project/the-racket-form/messages.json

[{"user_id": 25438, "stars": [], "topic_id": 34475, "date_created": 1304990837.571924, "message": "My current thought is that there would be a primitive form called \"racket\" or perhaps \"racket-code\" which would only take a string.  It would use Racket's reader on that string and insert the Racket code into the output of the Arc compiler.  It would be defined in ac.ss so that it would be available immediately when arc.arc (or some future base.arc) was loaded.  It wouldn't need to be a macro because it doesn't transform code, instead it quotes it so that the code is passed through the Arc compiler untouched.", "group_id": 9739, "id": 981553}, {"user_id": 25438, "stars": [], "topic_id": 34475, "date_created": 1304991330.063827, "message": "Then, there could also be macros that would be more convenient to work with Racket code in Arc.  One of these macros could be called \"racket\" in preference to calling the primitive form \"racket\".\n\nOne such macro could be the \"racket\" defined in https://github.com/Pauan/ar/blob/3649de149fcd490db3a719a0b0b3dfa00fd180d2/ac.ss  This is quite different than the \"racket\" defined in the current ar (https://github.com/awwx/ar/blob/c375d77bd2dbf6ca8850fda5f611784506efff50/ac.ss), because, as I understand it (correct me if I'm wrong), Pauan's version eval's the Racket code at macro expansion time instead of after the Arc compiler finishes.  That's a perfectly reasonable thing to want to do, just different than the facility provided by the primitive racket form.", "group_id": 9739, "id": 981698}, {"user_id": 32737, "stars": [], "topic_id": 34475, "date_created": 1305049036.1400139, "message": "Also, along similar lines, how about making the Arc namespace inherit from the Racket namespace? That way, rather than using (racket (toarc ...)) you could just use (toarc ...) Because it inherits, it should be possible to overwrite/shadow the Racket stuff without hurting the compiler.", "group_id": 9739, "id": 993445}, {"user_id": 25438, "stars": [], "topic_id": 34475, "date_created": 1305053417.070739, "message": "I don't think we want to shadow Racket stuff... we should be able to *change* the Racket namespace from Arc if we want to.  However we should prefix the names of Racket definitions (with a prefix such as \"racket-\"), so that can we can use short names for things that we want without hurting the compiler.", "group_id": 9739, "id": 994373}, {"user_id": 32737, "stars": [], "topic_id": 34475, "date_created": 1305053907.263164, "message": "No, no, see, that's why you make it inherit, so that you can change stuff in Arc without overwriting the Racket namespace. You get the best of both worlds: not needing to prefix with racket- but still able to muck around with stuff.", "group_id": 9739, "id": 994446}, {"user_id": 25438, "stars": [], "topic_id": 34475, "date_created": 1305055660.5077839, "message": "I also have many Racket functions calling functions defined in Arc.  With this change they would need to be annotated to figure out whether they should be calling functions in the Racket namespace or the Arc one.\n\nBeing able to mess with the compiler in Arc is a feature, not a bug.  It's a primary goal of ar: to make Arc more hackable.\n\nHowever, being able to separate things into different namespaces is a good idea.  I'll often want to put something into a separate namespace so that I can mess with it without affecting something else, or to be able to mess with something else without affect it.  But deciding to put Racket in one namespace and Arc in another is drawing the boundary in a specific place, which may not be where I want it.", "group_id": 9739, "id": 994855}, {"user_id": 32737, "stars": [], "topic_id": 34475, "date_created": 1305056041.9830389, "message": "To be specific: what I'm proposing is that, in Arc, when you look up a variable, if it's not found in the Arc namespace, it will check in the Racket namespace. So if you do (toarc ...) it will check for \"toarc\", but won't find it since toarc is a Racket function, not an Arc function. Then it will check in Racket, find the toarc function, and then call it. This avoids needing to use the racket- prefix and also avoids needing to use (racket ...) in many cases.\n\nAnd then if you overwrite toarc with (def toarc ...) it won't overwrite it in Racket, it will simply assign it to the Arc namespace, shadowing it. It should still be possible to call the Racket toarc by using (racket ...) or similar. I'm not proposing we reduce the power of Arc, or restrict it from using/inspecting/modifying the compiler, I'm proposing a nicer and easier way to grab values from Racket (while within Arc). Assuming my idea is possible, of course.", "group_id": 9739, "id": 994936}, {"user_id": 32737, "stars": [], "topic_id": 34475, "date_created": 1305056334.5709951, "message": "By the way, Arc and Racket already *are* in separate namespaces... if you call (racket hash) it will spit back an \"undefined variable\" error. With my change, it's possible to use (racket hash), which is nice, but by making the Arc namespace inherit from Racket, you could just use plain-old `hash` instead, without needing the (racket ...) part.", "group_id": 9739, "id": 994997}, {"user_id": 32737, "stars": [], "topic_id": 34475, "date_created": 1305056986.7196679, "message": "Oops, I just realized that the change I'm talking about is actually in Arubic, not in ac.ss. But it does demonstrate that the idea is (probably) possible, at least. Racket makes it really annoying to deal with namespaces... ugh.\n\nAnyways, I'm using module->namespace to grab all the globals from ac.ss, which is why (racket hash) and (racket toarc) work in Arubic. You could use a similar trick in as.ss. Unfortunately, I haven't figured out a way to convert the current module into a namespace, so I haven't been able to put it into ac.ss.", "group_id": 9739, "id": 995127}, {"user_id": 25438, "stars": [], "topic_id": 34475, "date_created": 1305060178.962132, "message": "Since the goal of ar is to be very hackable, if you want to load some functions (such as the Racket functions, or the compiler functions), into a separate namespace and inherit one from the other, there should be nothing to stop you.  You can load the Racket functions, the compiler functions, and the definitions in arc.arc (whether split up into smaller files or not) into whichever different namespaces you want, and have them inherit from each other or copy one into the other, as is most useful to you.", "group_id": 9739, "id": 995748}, {"user_id": 25438, "stars": [], "topic_id": 34475, "date_created": 1305058713.432492, "message": "The next step is to get the Racket compiler functions in the Arc namespace as well.", "group_id": 9739, "id": 995446}, {"user_id": 25438, "stars": [], "topic_id": 34475, "date_created": 1305058684.2092991, "message": "arc> (racket-hash)\n#hash()\narc> (racket-hash-ref (obj a 1) 'a)\n1\n", "group_id": 9739, "id": 995441}, {"user_id": 25438, "stars": [], "topic_id": 34475, "date_created": 1305058604.4627349, "message": "This is a recent change so you might have missed it, but Racket functions are now imported into the Arc namespace with a \"racket-\" prefix, and can be used directly without a \"racket\" form:", "group_id": 9739, "id": 995428}, {"user_id": 25438, "stars": [], "topic_id": 34475, "date_created": 1305058932.4957011, "message": "\"To be specific: what I'm proposing is that, in Arc, when you look up a variable, if it's not found in the Arc namespace, it will check in the Racket namespace.\"  Yes, I understand the proposal.  My point is while being able to separate (and perhaps inherit, though that seems more like an optimization) namespaces is a good thing, I might want to do that on some other boundary than between functions that happen to be defined in Racket and functions that happen to be written in Arc.", "group_id": 9739, "id": 995498}, {"user_id": 32737, "stars": [], "topic_id": 34475, "date_created": 1305059409.568069, "message": "Inheriting isn't an optimization. There is a distinct difference between the two, in particular when overwriting. If you merely copied the values, then if you overwrited one in Arc, it would overwrite it in Racket too. That's why you inherit: so overwriting in Arc won't affect Racket. It's still possible to affect Racket, though, by using (racket ...) or similar.\n\nAlso, how is prefixing them with racket- any different than separating into separate namespaces? It's the exact same thing. It's just that with my proposal, you can write `hash` rather than racket-hash or (racket hash).", "group_id": 9739, "id": 995603}]