Fabien COELHO <[EMAIL PROTECTED]> writes:
>> ... your proposed changes are going to make the grammar a whole lot
>> larger yet, at least in terms of states and actions.
> Not really in terms of state. The state should basically be the same.
> However yes in terms of "explicit" state that are given explicit names.
> And definitely in terms of actions, as you say.
But mid-rule actions are implemented by inventing additional internal
productions (see the bison manual's discussion of them; the O'Reilly
lex & yacc book says that all yaccs do it like that). That's not only
more states, but more symbols, which is going to impose an O(N^2) cost
on the raw tabular representation of the parsing rules. Maybe much of
this will be bought back when bison compresses the tables, and maybe
not. Have you checked how much the size of gram.o grows with the stuff
you've installed so far?
(I'm also slightly worried about what this will do to parsing speed,
but evidence about that would have to wait for further development of
the patch. In any case it'd be more attractive if the cost of this
could be paid only when we've already detected an error...)
> I'm afraid it looks like "internal state 1232, 43425 and 42523", but there
> may be some support enough in the generated code to get something more
> interesting. It would require to be able to get textual meta informations
> out of the state number, which is possible if bison/flex people did
> something about it.
The string names of the grammar symbols are all embedded in gram.c
anyway, so if you can figure out the symbols that are expected next,
their names could be printed directly. We could alter the symbol names
to be more useful to novices, or alternatively install an additional
lookup table to substitute reader-friendly phrases.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
