Not that this is necessarily a bad thing - it's good to take your time thinking about hard problems. I just hope the Arc community doesn't get too pissed off with pg's slow pacing that they go off and create yet another could-have-been-great-but-for-x-y-and-z new lisp dialect.
newLISP's default dynamical scoping fits very neatly among its other daring innovations (and, let me remark, such are wholly in the spirit of Lisp.)
One of those is the notion of a "context". Apart from neatly giving provision for all your lexical scoping needs, it adds the freedom of choice between argument passing by-value (which is default - another idiosyncratic bold feature of newLISP) and by-reference (through contexts). And - again, in line with Lisp's more traditional superiorities - contexts are first-class objects in newLISP.
My initial proposal here was not that newLISP is anyhow better than Arc. It cannot be, for Arc may eventually turn out to be anything; and, after all, this is an Arc forum.
It was, rather, that we should all go and use newLISP, to help Arc's developers learn from an existing complete powerful Lisp that has brought into practice many new design ideas.
Ah, but of course dynamic scoping is bad for any, any language, whatever the design goals. Everybody knows that since ages ago. <end of my turn to be clever>
My fascination about newLISP was exactly that: "What?! Dynamic scope by default?! ...Oh, but look, they say you can scope lexically & do closures with no fuss... Context as an explicit first-class object? hey, that's an idea, for once."
newLISP indeed has real flaws, - which can be mistaken for mistakes, unless you take into account the exotic design requirement for newLISP: to fit a Swiss-army-knife function library, together with functional and O-O programming support & a stand-alone web server, into a 300kb executable.
We can but guess of the author's intent. My guess is that the built-in distributed computing functionality has something to do with the plan.
