Re: warning: unused value: $3

[Hans Aberg]

On 25 Oct 2006, at 22:13, address@hidden wrote:

> On Wednesday 25 October 2006 21:22, Hans Aberg wrote:
> > On 25 Oct 2006, at 17:05, address@hidden wrote:
> > > My grammar set a number of attributes in an allocated structure
> > > using $0 to
> > > reference the structure on the stack. The full rules are as follow
> > > procoption:
> > >         MAIN { if(setTristateAttribute(&($<pol>0)->main,1)<0)
> > > YYERROR; }
> > I think you should take away the use of $0, because it may no longer
>
> This I find a bit disturbing, but thanks for the warning.
> Are there anywhere a list of removal of features from Bison?

One has look into the Bison distribution files.

> > be guaranteed, in view of that Bison is switching to other types of
> > containers than an underlying array.
> but should the container still support the $0 notation ?

My memory is hazy, so you will have to wait for the developers with  
the full story. I think this feature may never have been official,  
but only something people used, in view of that there was an array  
used for parser stack. But when switching to C++ containers, such as  
std::deque, it may not hold up anymore.

> > Then you mid-rule action becomes
> > unnecessary.
> is there any recommendations for the best solution for this kind of  
> parsing ?

In C++, I would use a reference count structure, so that $$ = $1  
results in handing over a reference, rather than copying over the  
whole structure. Then one way is to write:
  item_list:
    item { $$ = $1; }  /* Initialize */
  | item_list "," item {
      $$ = combine($1, $3);
    }
where combine is a function that somehow creates a new list out of $1  
and $3. If one should avoid unnecessary copying, I think one can use  
a function mutates the list $1 by appending $3. One then hands over  
the reference to $$. When using C, one has to think carefully about  
destruction in order to avoid memory leaks - there is a %destructor  
or something that handles cleanup during error recovery.

> it is a shame though, because the checking, setting of the parsed  
> values are
> now tied together in just the parser rule.

I think this is a problem of the bottom up parsing methods, like the  
LALR(1) that Bison uses. Formally, the parser, only knows the  
semantic values, as they are constructed from the leaves and up of  
the parse tree.

  Hans Aberg