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.
Have to watch out for corner cases - Arc's usage of 'nil as the list terminator is exposed in several places within the language itself. For example `(is (coerce "nil" 'sym) (cdr nil))` is true under the existing implementation, yet would be false if you just (defined nil '()). You'd need to patch `is`, `coerce`, and possibly a bunch of other primitives to preserve the existing behavior.
Which exposes the problem of "the code is the spec". If there was a prose spec, pg could have just said that such stuff was undefined and we wouldn't care that such things break.
If stuff doesn't work right, having the spec say it's supposed to not work right doesn't help at all.
Prose specs came into being to help multiple implementations interoperate (somewhat) when implemented in low level languages. I don't see the need when you have just one pretty concise and declarative implementation.
You wanna try a port? One of the examples for Yapps is a Lisp reader (http://theory.stanford.edu/~amitp/yapps/yapps2/manual/node2....), and once you've done the reader building an evaluator is standard Lisp stuff. Arc data types map very closely to standard Python types, and Python can do introspection on stack frames with the inspect module, though I don't think you could handle the scope chain using object prototypes like I did in ArcLite (though maybe with a bit of metaclass/getattr hacker...) You've got both the Arc and ArcLite source code to refer back to.
I was kinda curious what a Python port would look like - a lot of the boilerplate in ArcLite is dealing with language issues that Python has solved, like the lack of list comprehensions or decent string methods. But I couldn't justify spending any more time on it. It'd be neat to see the line counts of Scheme, Python, and JavaScript versions all together.
Sorry for misunderstanding! My heretic idea is that given the arc goals we should not improve scheme or lisp but instead improve python given the evidence in benchmarks!
Well, as a Python programmer, I'd be all for that...
However, I don't think that's really Arc's goals, which I think were foremost to create a language that PG would like to program in. If he wanted to program in Python, he would. Also, the existing Arc community seems largely drawn from disenchanted Lispers who really like the syntax and macros of Lisp, but don't want to deal with onions in the existing languages.
I considered it - there was a point where I thought "Wouldn't it be cool if I implemented Cheney-on-the-MTA in JavaScript?" JavaScript doesn't have setjmp/longjmp, but it can be faked with exceptions. But I wasn't sure about the garbage-collection aspect, since you don't have the same fine-grained control over memory that you do in C, and I was afraid that just holding onto the continuation closure would accidentally capture the whole rest of the stack (because of arguments.caller), trading a stack overflow for a massive memory leak. And since I didn't want to spend too much time on the project, I decided to punt on the whole thing.
I think the setTimeout trampoline is better anyways - in addition to cleaning everything up, it also gives the browser's event loop a chance to run, so you don't risk locking up the browser.
SVG still needs a plugin in many of the popular browsers. If you want something that'll work out of the box, I'd use Canvas (or excanvas.js for IE compatibility). SVG's a better technology, but the winner tends to be the one that works now, not the one that will work better eventually.
I've heard that a lot, but I don't quite buy it. Thing is, distributed computing is the current big thing in architectures. If you can't scale your architecture across multiple commodity PCs, you're in for lots of pain, regardless of whether it supports multiple cores or not. Nobody wants to have to buy a SunFire just because their website got big.
If you have distribution, it's no big deal just to run multiple processes on one box and let the OS handle concurrency. You can treat each processor like it's a separate machine, let the OS handle scheduling, use your architecture's distributed-computing features, and silently take advantage of the blazingly fast IPC between different processes on the same machine.
There's another very obvious counterexample: assertions. Buried within the source code to ArcLite is an assert function and several assertions. These are not strictly necessary; the functional behavior of a program is the same whether or not it has assertions. But they were very necessary for debugging, and they continued to catch other bugs long after they'd served their original purpose.
The source itself is pretty close to ActionScript compatible. Problem is, I mess with the __proto__ property a lot for basic data types and for scope chaining. It's what lets me use JavaScript's native lookup mechanism for variable lookup; instead of searching down an a-list, I make each activation frame a JavaScript object and knit their prototypes together, so I can lookup variables with 'env[symbol]' and the whole search process is in C. __proto__ is a non-standard property; it's supported in all major browsers, but I wouldn't bet on it appearing in Flash. And I'm not sure it'd be fast enough if you had to implement variable lookup in the interpreter itself.
I thought about writing a compiler instead of an interpreter, but macros & quasiquote present a bit of a problem. You can compile the code down to JavaScript...but if you run into a quasiquote, you've got to jump back into the compiler to evaluate it, then splice that code back into your function, then eval the newly-generated JavaScript code to get back a real function. Remember, even ordinary functions like setforms (in the standard library) call macex at runtime, so you can't just separate things into a compile-time-only macroexpansion pass. And ActionScript doesn't have an eval function, so that gets a little complicated.
I understand your point about macros but not quasiquote... I thought `(a b ,x ,y c d) was an abbreviation for (list 'a 'b x y 'c 'd)? What am I missing?
I wonder if it might work if you have an identical Arc implementation in your compiler and in your runtime so that all the macro expansions can be done at compile time.
ActionScript3 flash.display.Loader.load() says it loads SWF files... does this include compiled ActionScript? If so, maybe a REPL inside the Flash application could be written by calling back to your server which ran the compiler. Not ideal, but certainly more fun than an edit -> compile -> run -> debug cycle.
`(a b ,x ,y c d) is an abbreviation for (quasiquote (a b (unquote x) (unquote y) c d). The quasiquote returns a literal list, except that whenever it encounters an unquote or unquote-splicing it hops back into the evaluator and evaluates the form in the local environment.
Flash load() is probably your best bet. My startup has a similar problem - dynamically generating code that will run in a browser - and we eventually decided it was easier to go with JavaScript/eval than Flash, even though we have to support Flash anyway for the finished product. Our other option was to send the code back to the server through Flash's XMLConnection, compile it there, returns a URL of the compiled SWF through the connection, then loadSWF() it and hope we can figure out how to dynamically reference the new classes. Check out MTASC for the server; Macromedia's Flash Compiler won't run on the command line.
Or you could just punt on the dynamic features. I don't support continuations in ArcLite, and I know someone doing a native-code port that's planning to leave out a few of the more dynamic features. Beware that I found (= ...) doesn't work if you leave out (macex ...), though.
Yeah, it was a deliberate design decision by Macromedia. They wanted to keep the VM small, so they deliberately left out anything that smacked of a runtime compiler. Eval, regexps. Though I heard regexps may have come back in AS3...
Fixed the hanging. Was kinda a fun fix too...manually CPS'd the loading of the libraries and then inserted a call to window.setTimeout after each iteration, which gives the browser's event loop a chance to run.
