At 11:20 AM 6/11/2001 -0600, Alastair David Reid wrote:
The problem is that my test program runs out of stack (not heap) on both GHC and Hugs when parsing a large-enough file (about 150K for GHC, a lot less for Hugs).
The classic cause of this problem in parsers is tracking line numbers. The problem is that line numbers have to be built but rarely get observed. This means that a line number like 33 will be represented by a thunk like this:
1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1
This uses a lot of heap space (though it may not be too bad because of sharing) but, more seriously, it takes stack space proportional to the line number - hence the stack overflows you've been seeing.
Thanx! That makes sense, kind of. I'm still not sure why the hit is in the stack. I guess the stack must be used in a different manner than in the lazy evaluator I programmed not long ago in C++ (it was a learning experience). In that evaluator, a line number represented like that would be just one more heap token/pointer stored in the stack, regardless of the internal complexity of the expression. Unless the stack overflow happens on evaluating the line number for printing it out. But then, in my evaluator, it would have been the previous line number plus one, and the previous line number would have been computed already when printing the previous line of code. Hmmm... Do you think I have to re-evaluate what I know of the internals of how Haskell works? Thanx for your help. Salutaciones, JCAB --------------------------------------------------------------------- Juan Carlos "JCAB" Arevalo Baeza | http://www.roningames.com Senior Technology programmer | mailto:jcab@roningames.com Ronin Entertainment | ICQ: 10913692 (my opinions are only mine) JCAB's Rumblings: http://www.metro.net/jcab/Rumblings/html/index.html