[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sticking custom meta informations to grammar rules
From: |
Hans Aberg |
Subject: |
Re: sticking custom meta informations to grammar rules |
Date: |
Thu, 30 Jan 2014 19:11:11 +0100 |
On 30 Jan 2014, at 17:55, Christian Schoenebeck <address@hidden> 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