The difficult part is, of course, to test if the choice of axioms is optimal you have to build number of different real applications on top of it, and real applications need vast libraries.
Something which seems so harmless as 'standard input port' needs to be reconsidered if you start supporting large character set. Another example is the history of the quest to find the right way to do asynchronous inter-process communication---the flaw of the core model only surfaces when some applications try to push the envelope.
News.YC is a real application and I wouldn't call its libraries vast. I suspect it would be enough to do 4 or 5 fairly different types of applications, maybe a couple thousand lines each.
I'd love to do a graphics application next, preferably web-based. Anyone have opinions about the right structure for such a thing?
I don't deny that News.YC is a real application. OTOH, I've used my Scheme implementation for several commercial projects and I don't think I can port them to the current version of Arc straightforward. So I try to pinpoint the reasons. Libraries can come afterwards, so here I think of the core features.
A couple of things I think indispensable are the ability to write non-consing inner loop and O(1) access structure (vectors)---combining these with macros I can make the speed-critical routine run pretty fast. Although this seems an optimization issue, it is so critical to the extent that, if I weren't have them I couldn't have used Scheme to the projects.
Managing concurrent processes and threads safely and efficiently is another part that the language can help tremendously if it provides a right model. Arc's current choice of atomic-invoke is simple and clean, but questionable in terms of scalability; at least I cannot use that model in my app. (And that model is so fundamental that it'll be pain to change later to go through all atlets and atwiths to replace them for the different primitives.)
Oh BTW, I think the primitive 'dead' in ac.scm line 1083 is missing wrapnil.
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...
I haven't yet heard of any Scheme -> JavaScript compilers that support eval (and thus a REPL)... so ArcLite (or some other interpreter written in JavaScript) would be a good way to support interactive programming in the meantime.
Not sure about the structure being right or not, but the script interface to The Gimp comes to mind, at least for graphics primitives, only because it is Lisp and could be translated to Arc w/o reinventing the wheel (reinvention could be Phase II:-)).
I'm not sure what you have in mind with graphics app, but I think a wiki whose pages could contain some kind of simple, "object-oriented" vector graphics (e.g. using a small Flash app) would be cool.
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.
