Arc Forumnew | comments | leaders | submitlogin
1 point by rocketnia 5037 days ago | link | parent

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....

Thoughts?