help-bison
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]