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. I think a starting point would be to forget about the suggested "atomic" keyword completely for now and just to manually modify the yysyntax_error() function in the skeleton to always and only reflect possible NT symbols and never reflect terminal symbols. Hints for how to achieve that very much appreciated! > > 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 _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison