We don't need Garbage Collection

http://www.newlisp.org/MemoryManagement.html

Memory management in newLISP does not rely on a garbage collection algorithm. Memory is not marked or reference-counted. Instead, a decision whether to delete a newly created memory object is made right after the memory object is created.

Empirical studies of LISP have shown that most LISP cells are not shared and so can be reclaimed during the evaluation process. Aside from some optimizations for part of the built-in functions, newLISP deletes memory new objects containing intermediate evaluation results once it reaches a higher evaluation level. newLISP does this by pushing a reference to each created memory object onto a result stack. When newLISP reaches a higher evaluation level, it removes the last evaluation result's reference from the result stack and deletes the evaluation result's memory object. This should not be confused with one-bit reference counting. ORO memory management does not set bits to mark objects as sticky.


Why are you still using garbage collection?

>>2
No. Garbage collection implies a sub-process which is responsible for collecting objects which are out of scope. There is no such thing in ORO. Perhaps you're are mixing up automatic memory management with garbage collection.

ORO is an automatic memory management technique, but not all automatic memory management techniques are garbage collecting ones. ORO uses the evaluation stack to determine the precise lifetime of objects, backed by traditional manual memory heaps/freeps/arenas/etc.