LOL. In my off-time in the office I'm building a package system for that lisplike, basing off a macro that must enclose all forms that need to use packages; basically what it does is add the package name to the symbols that have been imported from the package.
The upshot of that whole piece is that when making things terser we have to be careful not to make them impenetrable. Not sure that is much of a scoop. I worry about that every time I name a variable or function. It might be an answer to those complaining that Arc is just a bunch of macros atop Lisp: part of the hard part for PG may have been maintaining that very balance between brevity and obscurity. And I hear E=mc^2 was considered obvious by some once Einstein wrote it down. But I digress.
What is your background? One of the more important (to me) questions in my Road to Lisp Survey (an ez goog) was about the background of the respondent. If yours is any Lisp, yawn, if it is COBOL... <g>
Mostly a hobby hacker. Came to Lisp via C++. Loved programming but didn't know how hard the language was making it until around '98 when I read Peter Norvig's PAIP, and was blown away. Couldn't understand why such a great language had been more or less forgotten by the tech mainstream. Soon after that I quit the commercial scene altogether, and have stayed away ever since. These days I hack only as a hobby, and choose whatever tools feel best. Had some fun with Python, but have never enjoyed a language as much as Lisp.
I like Paul's approach with Arc for all kinds of reasons, most of them aesthetic. I look forward to using a language that remains simple and elegant at its core, but knows how to do messy stuff, and isn't sullied by it.
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.
No, there is not. Only with defstructs do you get a copier. But with CLOS instances, unlike defstructs, you can use the MOP to iterate over the slots of an instance to do a rough simulation of copying. That code might have portability issues, but I think Pascal Costanza has a library out there somewhere that tries to account for MOP variations in CLs.
(defun copy-instance (i &aux (i-class (class-of i)))
(let ((c (make-instance i-class)))
(loop for s in (mop:class-slots i-class)
do (setf (slot-value c (mop:slot-definition-name s))
(slot-value i (mop:slot-definition-name s)))
finally (return c))))
Where you see mop: look out. :) The MOP package of the CL implementation you are using may even be nicknamed CLOS. You may have to take the union of class-direct-slots and class-indirect-slots. The slot returned may be the slot name itself. Stuff like that.
(defun copy-instance (i)
(loop with i-class = (class-of i)
with c = (allocate-instance i-class)
for sd in (mop:class-slots i-class)
for sn = (mop:slot-definition-name sd)
when (slot-boundp i sn)
do (setf (slot-value c sn)
(slot-value i sn))
finally (return c)))
But what if necessary side-effects happen in initialize-instance? Though that could as easily make a case for allocate-instance, if Paul needs to avoid those side effects.
I think the bottom line is that I should have emphasized that copy-instance above might not survive first contact with the enemy (the functional requirements).
This breaks down on bigger projects spread across multiple source files, at which point one needs some "make" tool such as ASDF for CL where one can pile macros into earlier files and then make other files with code using those macros dependent on the macro-bearing file(s). This can make for a lot of recompilation after minor changes, so I just take my chances and (yep) recompile all when in doubt (which with today's systems goes pretty fast).
LOOP. I know Paul thinks it was a mistake and I hated it (for its un-Lispyness) until I learned it, but now I will not use anything else for iteration. The funny thing is that loop gives us both shorter code and fewer parentheses, the goal of Arc! In a list processing language, what comes up more often iteration? OK, Arc is closer to Scheme in spirit so the answer to that is probably "Recursion!", but us CLers think using recursion to iterate just means your language is weak on iteration so recursion gets forced into an inappropriate role.
loop (in CL, this is) is a full-blown iteration DSL with its own tricky syntax to remember and everything, all in the name of making such code terser. The only time I use MAPCAR, CL's map, is in the rare case where I can just say:
(mapcar 'length my-strings)
That is shorter than:
(loop for s in my-strings collecting (length s))
loop has an initially clause, a finally clause, several kinds of ways to iterate and step, and has special keywords for different kinds of value accumulation. Like I said, it really is its own little iteration language that cuts waaay down on parentheses and otherwise makes for more terse and more efficient iteration.
I don't know, look at how GvR treats lambda: a weak version and he still tried to back it out of the language at one point. Even when benevolent the judgment can stumble -- hell, McCarthy still does not like sexprs! :) The good thing about Arc is that it has decent macros, so not even PG can dictate to users -- we'll just MAC an end run. :)
Perhaps the pro-hygiene crowd needs to step up and tell us unhygienic types how long they have programmed with unhygienic macros and how often they have run afoul of variable capture. I am reminded of static/dynamic debates in which the pro-static crowd wants it to be taken as a given that it is better to have type errors detected at compile time. There is a prima facie compellingness to such assertions that may not pan out in practice, and at bottom the pro-safety crowd might just be imposing their (sorry) timidity on those of us who prefer to climb unroped in return for getting up the peak faster, which itself does more for safety when the climber is capable. uhoh, here comes my Reinhold Messner analogy....
I regard it more as a lexical binding/dynamic binding debate. DEFMACRO or MAC are like dynamic binding, because the meaning of a macro can be affected by local variable bindings surrounding its site of use, contrary to the intended meaning of the macro writer at the definition site.
I would recommend getting a Common Lisp (nice free trial versions available from commercial vendors) and PG's ANSI Common Lisp book, second choice Peter Seibel's Practical Common Lisp. Ignore things in CL you do not see in Arc <g>. But the core ideas documented in solid CL references will help directly with Arc.
Scheme is a second choice, but if you catch fire and want to start programming in anger with some Lisp I think CL gets the edge. Just my opinion, of course.
