I'll add one more thing: static binding. It's the only functional language/LISP dialect I've ever seen developed after the 1970's (besides Emacs Lisp) that still does dynamic binding. I decided that this would be lots of trouble for programming in the large, which is why I never decided to pursue it.
This NewLisp fragment (which is also valid Scheme) illustrates this:
This form evaluates to 5 in NewLisp but 3 in Scheme. The equivalent in Arc:
(let x 1
(let f (fn (y) (+ x y))
(let g (fn (f y) (let x 3 (f y)))
(g f 2))))
as expected evaluates to 3, so Arc also does static binding. Dynamic binding makes safe use of free variables in different contexts that much harder, and essentially makes referential transparency all but impossible. I cannot for the life of me, especially after reading Steele and Sussman's "The Art of The Interpreter", imagine why the designers of NewLISP thought it would be a good idea to use dynamic binding in their language. Static binding had a reputation in the past as carrying with it a performance hit, which is why RMS didn't use it for Emacs Lisp, but research done afterwards has shown that there are ways of doing it properly that don't sacrifice performance.
Unless I'm not understanding something, and am not quite grokking this whole list/functional language thing (entirely possible I'm still learning).
newLisp appears to have the following from this list (by way of a quick look at the documentation on the site):
macros via define-macro and lamda-macro (and not autmatically hygenic ones...)
pass by reference.
And closures via let and lambda forms.
garbage collection
hash tables
Im really not for or against newLisp. It seems that since you last looked some of the stuff got implemented. The thing Im really not sure of is macros. It seems to me that the newLisp maros are very much the same as arc macros. If this is wrong, can someone please help me grok it?
One of the things I don't like about newlisp is that from their site, they appear intentionally misleading about what they can and can't do.
They don't have hash tables, this they openly admit and they make do with self balancing trees.
They don't have macros, they have f-expressions. F-exprs are strictly more powerful, but execute at run time not at definition time. This means every abstraction you use incurs a penalty fee each time it is executed, rather than just once when it is compiled. They call what them macros anyway.
They don't have garbage collection at all. The whole language is basically allocated on the stack, and objects are deleted or copied and returned when a function ends. This means they can't have true closures, or pass by reference with indefinite extent for the objects.
As far as I can tell, the hacks they suggest to get round the lack of closures won't work if you want to create and destroy many anonymous fns. bound to data with indefinite extent.
They still refer to these hacks as `closures'.
Their pass by reference work around, amounts to passing symbol names from different contexts and can't do the right thing when you(for example) want to merge existing lists and then rebind one the original symbols.
Having said all that, if one of the newLisp guys wants to prove me wrong, and show something like partial application code to demonstrate that it really does have true closures, it'd be great to see, and I'd probably go back to the language and have another go with it.
