Re: FYI: default %printer/%destructor

[Hans Aberg]

On 19 Nov 2006, at 21:17, Joel E. Denny 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, ...

I haven't followed this one

> ...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.

I think of it as a rule
  exp -> exp '+' exp
with other attachments: semantic values, etc. The grammar exists  
without the latter, the attachments, but not vice versa.

> > > 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....

I think there should be normal tokenization the Bison .l file, with a  
general rule, stripping out space and newlines. I think this leads to  
the most intuitive grammar.

> > > 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.

The %destructor is only needed with output language C. So perhaps it  
is not worth, or even prudent, to let the whole grammar be affected  
by that: I think that the input grammar and the output language  
should be separated as much as possible, to simplify the addition of  
other output languages. Just a hunch.

> If we use `:' for value names ...

WHat do you mean by value names, here? Is that the semantic value  
variables?

> (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.

I think of finding symbols that simplifies the Bison .y grammar.  
Stuff, like ";" that optionally can be omitted, which is there for  
legacy, causes problems.

> > 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.

It depends what comes first in the definition. It is easier  
implementing with defined names first, and then the definee.

> Also, I'm used to the
> instance:kind notation in UML, so r:exp makes sense to me.

I think of C, which had something that wasn't successful, relative to  
the functional notation. But the functional notation on each grammar  
variable might become too heavy, so I am striving for something  
simpler. This is my line of thought.

> > And then in the action use x.value, x.location
>
> That's an interesting possibility, but I think people are too  
> infatuated
> with $ and @.

At this point, I just mention it as a way to think in OO terms.

> > , x.token, x.name
>
> Why are these necessary?  The grammar author knows the token number  
> and
> name when he writes the rule.

If the token number should be used with type, it is has been into the  
parser class, making a C++ forward declaration impossible. If Bison  
should by a default write out the token name in errors, there needs  
to be standard way for that. If both these are moved over to Bison  
standard features, the a polymorphic semantic type needs only hold  
one object, simplifying the choice between different models (under C+ 
+). So these are some of the motivations I play around with.

> 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?

I haven't considered this. Now that you mention this, I think some  
special notation might be the prudent way. The location value will  
probably be used more often with Bison improved parser diagnostics.  
This suggests that one indeed needs some special way to indicate it.

  Hans Aberg