"it would be nifty if you could use Arc macros (or even functions, with an Arc hack to put enough metadata on them) in the s-expressions sent to the compiler."
I had the same reaction.
"But since the namespace seen by the (js ...) Arc isn't nearly the same as the namespace seen by the raw Arc, it seems like the sort of undertaking that would completely change the structure of the code."
Perhaps I'm missing something. I imagine you could implement a macro, say jsdef, to store translation functions in a table and then replace (def js-fn..) with (jsdef fn..). js would then replace keywords in car position with functions before eval-ing the whole shebang. This way you wouldn't need to update js everytime you want to implement a new arc function in js. You'd also be able to avoid quoting when you don't need backquotes.
Hmm, perhaps this runs into a similar problem to my yrc (http://arclanguage.org/item?id=11880) -- since you're doing keyword replace, is there a scenario where the keyword won't show up until after the replace step? My mind is getting bent out of shape thinking about this.
Yeah, I think essentially you could compile Arc to JavaScript approximately the same way it's compiled to Scheme. The issue I was referring to when I was talking about "the namespace[s]" is that a function may be defined in Arc proper but not in js.arc, or conversely, a function may exist on the JavaScript side (like alert()) that has no analogue in Arc. Either the library has to manage that or the programmer does, and it seems like the kind of thing a library should do.
...
Whoa, I'm now realizing just how especially intriguing this is to me; I've been getting into the thick of working on namespace organization for Blade, and this is really relevant for that. How might one go about having a language where programs may have access to significantly different core functionality depending on how they're compiled... but where it could be swapped out for a substitute implementation on a mismatched platform...
Oooh, a whole JavaScript primitive operation suite (indexing, +, -, *, certain global variables, JSON syntax, new, and so forth) could come in a parameter. When you call a 'jsdef function in Arc, the JS-runtime parameter can be obtained from some dynamic binding or global variable, and when you compile a 'jsdef function to JavaScript, references to that parameter can be given special treatment by the compiler. As for as Arc primitive operations, the Arc-to-JS compiler may be able to detect uses of those operations and translate them so they refer to some JavaScript-side global variable(s) defined in arc.js. I think this could work. ^_^
It isn't especially novel, I suppose, 'cause it still boils down to special-casing in the compiler, but at least it's limited to special-casing the JS-runtime parameter, which is part of the library itself.
To go on, I'm thinking that the primitive operations would be treated as faithfully as possible rather than approximated by similar operations in the other language. For instance, Arc numbers would be annotated strings or something in JavaScript, rather than being demoted to the width of a JavaScript number, and Arc + may throw an error in JavaScript if a bignum arithmetic library is unavailable. More language-lenient utilities can be built up on top of those. If it's annoying to come up with names for those because they clash with all the Arc-native names, well, that could indeed be a problem....
