Re: FYI: default %printer/%destructor

[Joel E. Denny]

On Sun, 19 Nov 2006, Hans Aberg wrote:

> If there would be a syntax change/extension, I would favor it to approach
> standard notation, as in the book by Waite & Goos, "Compiler Construction".
> Rules are written a -> b.

As long as we don't use `:' in the value name notation, then the issue of 
whether to provide `->' as an alternative to `:' is separate from the 
value name notation issue.

> Perhaps a "." would do. Then one one get:
>   exp.sum: exp.term1 '+' exp.term2 {...}

You later seem to take the view that sum is an instance of exp rather than 
an attribute.  I prefer viewing it as an instance, so I don't like the 
above notation.

> > For example, these look ambiguous to me:
> > 
> >   a: b/ c
> 
> Does "/" have another use?

Ok, I think I miscommunicated.  The ambiguity I meant is whether `b/c' is 
the same as `b/ c' as discussed below.  `c :b' and `c:b' have the same 
issue....

> > Compare with:
> > 
> >   a: b() c
> >   a: c b()
> 
> So what would these empty parenthesizes mean?

We've been proposing that they tell Bison that the semantic value of b is 
intentionally unused.  This would prevent a warning when b has a 
%destructor.

If we use `:' for value names (and thus `->' after the LHS) or `/' for 
values names, I guess the following would mean that b has no value:

  a -> c :b
  a: b/ c

But I think that looks ugly.  (Maybe I was unjustified in calling it 
ambiguous though.)  The parenthetical notation looks better to me.

> Also see the EBNF proposal I made n the Bug-Bison list (subject "EBNF"). It is
> relatively easy to make such an extansion, and it should then not clash with
> any other extension.

I have no desire to work on an EBNF extension.  However, I see your point 
that parentheses sometimes have a different purpose in grammars, and I 
guess Bison could one day grow such a purpose for them.

> > In TODO, I just noticed a couple of other issues for this area that I had
> > forgotten.  I don't much care for making values regular variables as
> > suggested by this example:
> > 
> >   r:exp -> a:exp '+' b:exp { r = a + b; } ;
> 
> My hunch is that the grammar variable should come first - easier both to
> humans and make a grammar.

You mean exp:r?  I don't see how that's easier.  Also, I'm used to the 
instance:kind notation in UML, so r:exp makes sense to me.

> And then in the action use x.value, x.location

That's an interesting possibility, but I think people are too infatuated 
with $ and @.

> , x.token, x.name

Why are these necessary?  The grammar author knows the token number and 
name when he writes the rule.  On the other hand, the value and location 
are computed dynamically.

> > This would also make it possible to declare a value as unused but still
> > access the location.  The only value used in the following is the LHS
> > value:
> > 
> >   exp($sum): exp(, @term1) '+' exp()
> 
> So some such OO notation might simplify such notational problems.

Your OO notation doesn't address the issue I was trying to address here.  
How do you declare that the semantic value is unused but still use the 
location?  Will we make the gamble that this is never necessary?