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