Stack leak... (?)

[Juan Carlos Arevalo Baeza]

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