ndmitchell: > 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.
I think that's a reasonable rule of thumb -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe