On 30 Jan 2014, at 17:55, Christian Schoenebeck <schoeneb...@crudebyte.com> wrote:
> On Thursday 30 January 2014 18:03:28 Hans Aberg wrote: >> I recall some others in the past that have written on interactive parsers >> showing completions. So it may be of interest integrating it into Bison. > > I am sure this is a commonly requested feature. However my code is C++ and > the > algorithm is calling itself recursively. Advantage is that the amount of code > is very small, can easily be maintained, however it has the potential to blow > the program's memory stack, especially on complex languages and on resource > limited embedded devices. So these two points already disqualify it from > being > accepted of becoming an internal part of Bison itself. The developers might chime in at some point. Akim has written most of the C++ parser. >> The parser algorithms throw away all grammar information; Bison only keeps >> in its table information about the states. So that is not possible. If one >> has context dependencies, that is handled in the parser actions, >> interacting with the lexer, if needed. > > Not really. I also thought so, but in each state for each upcoming potential > reduction you get the associated grammar rule index number. With that grammar > rule index number you can get its full grammar rule definition. I.e. > > std::string sRuleName = yytname[yyr1[rule]]; > > would give you the left hand side of the grammar rule. And then there are the > yyprhs and yyrhs tables to get all right hand side symbols of the individual > grammar rule. So you got all you need. Works fine! The grammar rules are in the input a set that defines the language, and there might be unexpected interaction between them. The safe way to work with it imperatively is with the states. >> They are not officially a part of a public API, and may change without >> notice. Some things have changed, for example, the C++ has a different one >> from the C one. > > Sure, that could happen at any time. But as far as I can see it, Bison's > yyfoo > tables and the fundamental parser algorithm based on them are treated > conservatively. Thumbs up! :-) So I am estimating this risk to be low in the > mid or even long term. And of course minor things change, like defines etc., > but that's trivial to maintain when new Bison versions are released. It has happened with some other features not officially supported. Hans _______________________________________________ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison