On 23/11/2008, at 9:18 PM, Robin Green wrote:
It occurs to me that garbage collection can be seen as some kind of dual of laziness. Laziness means deferring the creation of values until later in the future (or even never).
A program optimisation might also have the same effect (of avoiding a computation/work). Also note: if you want to take an extreme position, then most (all?) programming languages can be seen to be somewhat "lazy", since computations are goal directed, and therefore functions (or procedures) are only evaluated on points in their domain which are "needed" by the rest of the computation (consider a function defined on an infinite domain). However, that is not the traditional definition of lazy.
Garbage collection means eagerly destroying data created in the past, and reclaiming the memory used by it, before some other event which would do so (in most garbage-collected languages, I think process destruction is the only other thing that frees memory, leaving aside foreign functions).
Don't forget the stack. Besides, I'm not sure how "eager" most GCs are.
If you don't have enough laziness (e.g. because of strict pattern matching on tuples) your program might do unnecesssary work (time wastage); if you don't have enough garbage collection (e.g. because a value will never be accessed again but is still referred to from something live), your program might leak memory (space wastage).
Of course, space wastage can lead to time wastage, and vice-versa.
Can this intuition be made any more formal? Is it merely of pedagogical use, or does anything interesting follow from it?
If you are looking for interesting (and perhaps unconventional) musings on GC, then you might enjoy this paper: "Thermodynamics and Garbage Collection", Henry G Baker. http://home.pipeline.com/~hbaker1/ThermoGC.html Maybe that will spark some new ideas. Cheers, Bernie.