The memory management scheme is very novel: http://www.newlisp.org/MemoryManagement.html I don't get how it can work since it would require most objects to be passed by value and not reference.
It isn't novel. Basically, it assumes that objects are stack allocated and blows them away when expressions finish evaluating. Anything which escapes out of an expression is copied, so there is no reference graph.
Copying objects to avoid lifetime computations is far, far from novel. It is ancient. Think about all the C program modules that use strdup on strings that are passed around, over the place, so that they can then `free` their copy with confidence that nobody else has a pointer to it. In C++, there are smart pointers for one-reference only, like std::unique_ptr. (Long before that became standard, C++ coders did similar things from scratch.)
Stack allocation of temporaries which go away when a stack frame is blown away is certainly not new. The implementor of NewLisp just had to look to the implementation language C to get this idea.
Mature Lisp implementations have this as a built-in optimization in their compilers. That is to say, recognizing non-escaping temporary objects and optimizing their reclamation, and even allocating them on the stack. ANSI Common Lisp also has the (declare (dynamic-extent ...)) declaration to manually request, or suggest that this may be done with an object. (The programmer promises not to let that object escape, and in return, the implementation can stack-allocate it.)
NewLisp's claim is that the memory managent is novel in interpreters (because the author knows that Lisp compilers can identify temporary objects that don't need to be retained past the evaluation of their containing expression). Is it really novel? It might be true of the limited number of interpreters that the author knows about. If we were to exhaustively research the history of computing, we'd probably find other interpreted languages with copying memory management. Oh, here is one: GNU Bash. Look for uses of the function copy_word_list in the Bash sources. GNU Bash seems to be implementing "ORO" memory management for lists of strings passed around as arguments and other structures.
I'm not able to make sense of why it would not just be region-based memory-management. (http://www.sciencedirect.com/science/article/pii/S0890540196...). The usual way this fails is that everything ends up bubbling up to the top-most context, which is basically uncollectable. So you leak to death unless you limit yourself in awareness of this possibility.
I was hoping that their might actually be a linear type system hiding out in there, but alas, such is not the case.
