Re: in defense of GC

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

Ray Blaak <rAYblaaK@STRIPCAPStelus.net> writes:

> But to do closures properly, one really does need GC.

My words. Or to be truthful: They could have been. :-)

BTW, you've been discussing (with ... I don't remember) the possibilty
of switching GC off. My idea (even with ML-like languages) was always
to define a subset of the language which the compiler can implement
with a stack only. One could use this subset to embbed real time
capable procedures (as prioritized tasks or as interrupt handlers) in
a system with as a whole (user interface) does only provide "soft
realtime" (i.e. +/- garbage collection times). This should cover even
most cases with hard real time requirements.

Suitable subsets again could be compiled to pure C code which works
without GC (compile time garbage collections) or without heap. It's
the compilers job (maybe with help of the annotations) to
discover/prove that the code can be translated like that.

Seems to me a more useful approach than explicit pointer management.

One advantage of that would be that one could start out with code that
requires GC, but is "obviously" correct and then transform in
correctness preserving steps it into code that doesn't require
GC. Both implementations could be tested against each other, at least
as far as their computational function goes, not the real time
capabilities that are perhaps only possessed by the 2nd variant.

Regards -- Markus