Re: FYI: default %printer/%destructor

[Hans Aberg]

On 21 Nov 2006, at 19:30, Joel E. Denny wrote:

> > One of my worries, is what happens if one adds variables for token  
> > values and
> > names.
>
> To be more general, some day Bison might possibly need symbol  
> attributes
> other than semantic value and location.

Right. After reality preventing me from doing this stuff, I was just  
fiddling with getting my C++ parser working without having to tweak  
Bison itself. Then I arrived at the idea to perhaps put into the  
token values and names as parser features, along side with location.  
But my plan was to take up this idea later; it came up rather  
prematurely. So something else might come up in the future, though I  
do not know exactly what.

> > Suppose, just to focus on something, the latter have symbols #, %.
> > Then one would end up on combinations like:
> >   a(name1): b c() d(@#name2) e($#%name3)
>
> I would prefer:
>
>   a(name1): b c() d(@name2, #name2) e($name3, #name3, %name3)
>
> That is, (name1) makes all attributes available.  If you want a  
> specific
> subset, list the items in that subset.
>
> Yes, we're back to the previous verbosity, but I think it's not  
> terrible,
> I think it's better than ($#%name), and we appear to have no need  
> for it
> any time soon anyway.

I think that all that makes the grammar rues harder to read should be  
avoided. The often come out pretty dirty as it is. Though I do not  
know what is the best method might be. Also, it is good if the user  
as far as possible can avoid writing repetitions. So I think the idea  
above is good if one normally would use different names for the same  
stack position semantic, location, etc., values. But I suspect that  
is not going to be the case. So therefore, I think it is probably  
best to think OO: giving the parser stack position a name, and from  
that extract subfields, whatever the syntax may be.

  Hans Aberg