Generic and fundamental language design issue

Tommi tommitissari at hotmail.com
Sun Nov 4 15:20:44 PST 2012


On Sunday, 4 November 2012 at 21:27:36 UTC, Walter Bright wrote:
> You can't determine this, even at runtime, because you don't 
> know what subsequent calls will use enough stack to overflow it.

Right, I didn't take into account that heap allocations use some 
stack anyway to store the pointers.

Since it's not possible to completely stop the stack from filling 
any further once it's been filled up, some kind of conservative 
heuristic should be used then for determining whether things 
should go on heap or not. That heuristic would be based on both 
compile-time and run-time analysis of the program. The heuristic 
cannot guarantee that there won't be a stack overflow, but 
neither can the programmer.

It's great that optimizations could be used to eliminate 
unnecessary heap allocations. But it could be interesting to 
imagine a language where it was impossible for the programmer to 
explicitly specify the allocation method. Things would go to heap 
if it was determined necessary by compile-time analysis, and also 
when the heuristics determine there might a danger of stack 
overflow. Otherwise things would go to stack. Pointers (or rather 
re-directable references) would always be used for referring to 
existing variables (that could be on heap or not). Pointers would 
never represent "a variable allocated on heap".


More information about the Digitalmars-d mailing list