Re: improving yysyntax_error()

[Christian Schoenebeck]

Es geschah am Thursday, 21. June 2007 20:18 als Hans Aberg schrieb:
> How should %atomic be implemented?

How it "should" be implemented is the wrong question, or at least addressed to 
the wrong person, since I'm not familiar enough with the bison implementation 
yet. That was actually my main reason to write to this list, to probably get 
suggestions how this could fit into the current implementation of bison.

> > The rest
> > would be needed for implementing UTF-8 support.
>
> No, as sequences of bytes can be put directly into the rules.

Either we have a misapprehension here, or this is exactly what I did in my 
example, so I don't get the point.

> > And yes, for now it would
> > just be useful for better error and debug messages.
>
> So here I want to know how it should be implemented.

Same as above, so far I can only suggest the behavior concept, but not a good 
implementation approach.

> > Another future
> > application would be integrated type completion support within the
> > bison
> > skeleton parser.
>
> I cannot parse this. Please elaborate.

With "intergrated type completion support" I mean a convenient way for parser 
developers (or actually interpreter developers) to let the user "complete" 
the current input upon the current parser state, in case there is only one 
possible shift transition, that is for highly redundant languages. In this 
case it would follow the shift transitions (and reductions) until a parser 
state is reached with more than one possible shift transition. That auto 
completion procedure could be triggered in either predefined parser states or 
all parser states upon a certain terminal ID coming from yylex(). In case the 
auto completion procedure was requested from within a parser state where more 
than one shift is possible, it would stay in the current parser state and 
just call a dedicated function, i.e.

        // vPossibilities - null terminated list of possibilites
        yycompletionerror(const char** vPossibilities);

which could i.e. print out the expected inputs to stdout, or however the 
parser developer defines that function. With other words, a functionality 
that is supported by any good interpreter (i.e. '\t' in bash), but which is 
currently hard coded by all interpretes I know of, which is inconvenient and 
error-prone, because you have to maintain the BNF definition and the code 
completion code and thus is a redundant development effort. That's why I 
think that should be possible to be automatically handled by the generated 
parser.

CU
Christian