Would it be useful to isolate an intersection of Arc and JavaScript, and make a macro which generates JS code from this subset of Arc, to run on the client-side?
Does anyone have thoughts/links along these lines?
There was some reason I didn't do it that way (I'm the author of ArcLite). IIRC, it was because the semantics of Arc forms differed in a way that would basically require an Arc interpreter anyway, even if you compiled them. For example,
(foo "bar" 1 2)
is only a function call if foo is a function object. If foo is an array, it's an array index; if it's a hash, it's a dictionary get (both ill-formed in this example). Other operations are similarly polymorphic, eg. overloading + for addition and concatenation. In order to translate that reliably to JavaScript, you'd need to turn every funcall form into a type-dispatch. At that point, you're basically writing an interpreter anyway.
Yes definitely! I was writing an Arc application that was using a lot of Javascript, and I soon realised that I could be 10x as productive if I could generate the code using macros. No syntax errors, repetitive code automated etc. In the end though I gave up on that project, so I never did it. It was a bit too ambitious for a first project!
We could add an arc->rainbow-applet translator. It might be too expensive to declare applets inside webpages, so we need a toplevel defapplet-macro and macros for embedding applets into webpages and for the applets to communicate with the server.
