Tail call elimination

[Christopher Wright]

Nick Sabalausky wrote:
> On a side note, stack overflows are still possible anyway (whether 
> functional or imperative). Is there a reason (other than inertia) that stack 
> frames aren't set up like a dynamic array to grow as needed? (Of course, I 
> can understand not doing that during a debug build to help detect 
> unintentional infinite recursion) I realize the overhead of checking the 
> stack size on every function call might be undesirable, but (not that I've 
> given this much thought) is there no trick to set something up to 
> automatically trigger when the stack fills up? Or, isn't it already 
> detecting stack overflow anyway (I know some languages do that)? (Of course, 
> I'm not saying any of this would be a substitute for TCE, just a good 
> compliment to it.) 

You allocate memory whenever you overflow the currently allocated stack. 
The caveat is that it has to be contiguous to the existing stack 
(virtually contiguous, not physically contiguous). In the best case, as 
soon as you allocate something outside the stack, you've set a limit on 
the stack size.

On Linux, if your stack exceeds its allowed size, you get SIGSEGV. You 
can trap this, but you need to specify an alternate stack to do so. On 
my machine, the default stack limit is 8MB, though you can change that. 
I assume that setting the limit will alter the ranges that heap memory 
allocation can deal with, as well.