SearchYC.com

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.

Can't prove a negative, but I've already explained why I think I'm right.

>Intentionally? How so?

When they claim to fake closures with contexts, they're wrong. Now they're either confused or trying to confuse other people.

>Cite please.

"In newLISP lexical state-full closures are not realized using lambda closures but using lexical namespaces." http://www.newlisp.org/ExpressionEvaluation.html

It's the first hit on google for `newlisp closure'.

>What if I called you a jerk?

Pattern matching is completely orthogonal to hygiene.

You could add in another operator, %, that performs exactly the same as ` but hygienically. Personally I'd settle for just being able embed procedures in code trees like you can in common lisp. Being able to write.

  (let this (fn (x) x)
     (mac na-na-na(y)
      `(,this ,y))) ;Can't touch "this". It's lexically bound.

However, as this is optional, it can also be switched off in places to handle code that the type system can not prove correct.

To make a similar system work, you'd have to label the inputs and return type of each function, and enforce the consistency of this, all at compile time. There is a complete prolog system buried in QI allowing the types to self reference and be turing complete in terms of complexity.

Dynamic languages with no possibility of optimal type declarations come first, followed by statically typed type inferring languages, then a ragbag of stuff including dynamic languages with optional type declarations like SBCL.

Then Java and Ada at the back.

Well last time I looked at newLisp you were missing:

1)closures

2)callcc

3)pass by reference

4)macros (you've only got f-exprs)

5)argument checking for functions at run time

6)a compiler

7)Garbage collection

8)hash tables

I stopped looking after that but I'm sure other people can keep the list going...

  (def $ (x . lists)
         (if lists
             (apply map x lists)
             (fn (lists) (apply map x lists))))