Don:

> But it seems to me that a dedicated GC for pure functions has enormous 
> unexplored potential, and might be relatively easy to implement.

- In D we have not even started to exploit the full potential of purity and 
pure functions.
- In D reducing the work of the normal GC is a very good thing (because of 
problems caused by not moving GC, its not precise nature, its not advanced 
implementation, and because D is a complex system language).
- CommonLisp programmers and designers know that's it's good to give some hints 
to the the GC. Optional information that help the GC do its work more 
efficiently. The D1 "scope" attribute for class allocations was a not well 
designed&implemented example of this.


> (Note that the compiler can determine if a function makes any 
> memory allocations, simply by inspecting its body -- it isn't any more 
> difficult than checking if it is nothrow).

Time ago I have suggested a @noheap that makes sure a function tree doesn't 
allocate memory. 
What you say makes me think that here user code may just desire to know what 
the compiler knows: a __traits that given a function name returns a true if the 
function performs heap allocation.


> With no changes required to the 
> language, and not even any changes required to existing code.

Phobos and other many small things (D too, like some form to express 
conditional purity, etc) need to change to allow D programmers to use purity 
more widely in their programs. This in turn will make your pure GC more and 
more useful.

Bye,
bearophile

Reply via email to