Arc Forumnew | comments | leaders | submitlogin
A thought: Arc <=> JS
8 points by andreyf 4324 days ago | 13 comments
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?

16 points by drcode 4323 days ago | link

I have a simple arc->js translator just for this purpose. Basically, a "parenscript" for arc.

It's needs a lot more work though before it's worth posting publicly- Not sure if/when I'll get around to doing this.

(If I get six or more points on this post I suppose I'd consider getting it out sooner for others to play with :-)


4 points by drcode 4323 days ago | link

Ok- I still have a bit of work to do on it, but I'll try to release it in a couple weeks or so.


2 points by andreyf 4290 days ago | link

This is a "parenscript" for Allegro Lisp/AllergroServe. Def. worth looking at


1 point by andreyf 4323 days ago | link

I'm pretty n00b to Arc, could you please send me a copy privately to see how these things evolve?


1 point by drcode 4323 days ago | link



3 points by absz 4324 days ago | link

There is (, which is similar to what you mention; however, it's old now.


5 points by andreyf 4324 days ago | link

Cool, but I was thinking more something which would simply translate

    (foo "bar" 1 2)

    foo("bar", 1, 2)
One motivation is that just about all of JS can be written in Arc, but would also gain the advantage of macros.


3 points by nostrademons 4308 days ago | link

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.


2 points by skenney26 4323 days ago | link

A couple months ago I was playing around with an interpreter that translates Arc to Processing ( which is pretty similar to Javascript. It's available at and requires John Resig's Javascript port of Processing (


3 points by almkglor 4324 days ago | link

It would be useful. I've had thoughts along these lines.


1 point by cchooper 4324 days ago | link

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!


2 points by rincewind 4322 days ago | link

What about integrating javascript with the existing macros, e.g. with-ajaxy-link or jquery-modal-aform?


1 point by rincewind 4321 days ago | link

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.