newLISP does not support sharing of subobjects among objects, cyclic structures, nor multiple variables pointing to the same object. Objects are (physically) copied when stored in data structures or passed to functions

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...

This NewLisp fragment (which is also valid Scheme) illustrates this:

  (let ((x 1))
       (let ((f (lambda (y) (+ x y))))
            (let ((g (lambda (f y) (let ((x 3)) (f y)))))
                 (g f 2))))

  (let x 1
      (let f (fn (y) (+ x y))
             (let g (fn (f y) (let x 3 (f y)))
                 (g f 2))))

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?

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.

"...they appear intentionally misleading..." Intentionally? How so?

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?

Regard the comparison of Arc with NewLisp , I think the main goal (for now) with Arc is this so-called 'exploratory' programming , where the focus is more on 'playing' with ideas and new ways of design (through a cycle of test-error), and from there on, start and continue the building of a language for 'solving' in a elegant way much of the tasks a general purpose programming language should be able to do ; this approach, opposed to the traditional way of language design where you fight against the problems right away and build the language on top of that fight, could give a sense of slowness to Arc , but at the end,it could result in something cleaner and more elegant than what it is currently offered by many other languages.