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?

>>1

that just sounds like using garbage collection for general objects, but recognizing when a temporary value is used in an expression but will never be referenced again after the expression is evaluated, and then allocating that variable on the stack instead of the garbage collected heap.

>>1

[url]http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generational_GC_.28ephemeral_GC.29[/url]

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

>>3
It's not generational garbage collection. See >>4

>>5

it's generational, its just the generations are on a different kind of stack. similarly to cheney actually being a stop-and-copy algorithm, just without a queue.

http://www.pipeline.com/~hbaker1/LinearLisp.html

>>4

I see. That's exactly what happens in C though.

>>7

this is like crack. rocks.

>>7
sucks dicks.

>>1
Because you are a huge faggot and pissing you off is the best thing ever.

I don't get it. Does this disallow sharing? If so, it's shit.

>>6
You are retarded, sir. It's not generational garbage collection. There is no garbage collection subprocess. There are no generations either, there is no memory compaction into generations or anyway to identify objects belong to a generation.

>>12
Sharing is possible by pushing the shared object onto the result stack of a parent cell further up the evaluation tree, thus ensuring it's lifetime is at least equivalent to the objects referencing it.

>>14
That just sort of sounds like reference counting.

>>14
It's shit, fag.

>>1
Objects in newLISP (excluding symbols and contexts) are passed by value copy to other user-defined functions. As a result, each newLISP object only requires one reference.
Not even Java users are this retarded.

>>13

you can't see the forest for the trees.

accordion to the provided link, newlisp interns objects (and copies of them) on the stack(generation 0) during the evaluation process. and those that survive (bound to var's (by copying)) are moved to the heapgeneration 1.