Hi
implementations. Certainly my experience of library tuning tells me that (with ghc at least), designing your code and data structures to keep heap allocation down to an absolute minimum is very important.
Yes. Keeping allocation low is very important, be it heap or stack. Heap allocation is not free, its just not any more expensive than the stack.
A lot also depends on compiler (and associated rts), such as whether or not it translates to CPS, thereby in effect building a "stack" (in all but name) on the heap.
If you burn a lot of heap, for not much gain, that's still a bug, albeit one which large limits might be able to paper over for a short amount of time. Is the GHC stack not stored on the heap? I thought it was. I know the Hugs stack is stored on the stack, and the Yhc one isn't.
Surely the alleged buginess of programs should not be dependent on choice of compiler/rst?
Hmm, debatable. Things like the garbage collection inside tuples can change the space behaviour and implementability of some things, and are supported by GHC but not Hugs.
As nobody has provided any sensible justification for the assertion that using lots of stack (vs. heap) inherently is bad
My claim is that "any program which needs to adjust the stack size has a laziness leak" - since I've made a universally quantified claim, a couple of real examples should blow it out of the water. Thanks Neil