Re: Problem finding cause of memory exhausted

[Laurence Finston]

On Tue, 13 May 2008, Frans Englich wrote:

> On Saturday 10 May 2008 21:00:50 Laurence Finston wrote:

> I agree, I don't think this is caused by wrong recursion. I can't change my 
> grammar, and I can't discard tokens based on the test expression because it 
> cannot be evaluated at parse time. My language(XQuery) is functional in 
> syntax, which is the reason to why the if expressions has to be parsed in one 
> go: they're expressions, not statements.
> 

Is there a difference between parse time and run time with 
respect to your program?  Is your parser building a syntax tree or 
doing something similar, which is traversed later?  In this case, 
you might still be able to solve the problem without it being 
necessary for symbols to pile up on Bison's stack.  It's not always necessary 
or desirable for the rules in the Bison grammar to reflect the rules of a formal
grammar one-to-one.  One has access to the tokens and their semantic values 
in the actions.  It might be possible to put them onto a different data 
structure 
which you define yourself.  In other words, the parser doesn't need to "know" 
that it's processing a conditional, as long as you keep track of this 
information somewhere;  perhaps in the scanner, perhaps somewhere else.

> However, I don't see how "delimiters" like semi-colons would help anyway, the 
> grammar has a non-terminal for expressions so each test/then/else expression 
> can be reduced(see "Reducing stack by rule 77 (line 1678):" in the debug 
> output link).

Delimiters make it easier to determine when to stop discarding items of input, 
if one chooses to use this approach.

> sizeof(YYSTYPE) yields 84 -- it's very big(and hence inefficient). Could that 
> be the cause?

I don't know.  If it's being copied a lot, it would probably be a 
good idea to change it, anyway.  I'm not sure how this works, when
semantic values are passed among rules.  I find using `void*' as a
member of the `union' which is used as `YYSTYPE' works well (at the
cost of frequent casting).

Laurence