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.
