Re: FYI: default %printer/%destructor

[Hans Aberg]

On 19 Nov 2006, at 00:03, Joel E. Denny wrote:

> > I have looked at this, and tried to find an examples of other  
> > similar uses,
> > though I failed.
>
> Thanks for responding.  I think Akim got this from Lemon.  There  
> are some
> examples here:
>
>   http://www.hwaci.com/sw/lemon/lemon.html

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. It does not treat semantic  
values, though. In an attribute grammar, though, they us a ".".

> > One variation might be
> >   exp/sum: exp/term1 '+' exp/term2 {...}
> > Instead of the proposed
> >   exp/sum -> exp/term1 '+' exp/term2 {...}
>
> Parentheses are easier on my eyes than slash or colon is. (Colon is
> discussed in TODO.)

Parenthesizes should not be overused; becomes hard for human to read.  
And ";" is already overused, which may cause a grammar hard to  
implement. This lead me trying something else.

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

> For example, these look ambiguous to me:
>
>   a: b/ c

Does "/" have another use?

>   a -> c :b

And "->" would just be an alternative to ":" - the grammar the same,  
only a different lexer, returning the same token.

> In either case, is b's value named c?  Or is c another RHS symbol  
> and the
> value for b is not used?  Yes, the space between them probably  
> indicates
> the latter interpretation, but it still looks ugly to me.

I favor a grammar where spaces do not affect the grammar, only as a  
delimiter between tokens. In the first case, it would then be the  
same as
  a: b/c
And in the second case
  a : c : b
which I think generates an error, as Bison first sees a rule ":". One  
wants to make a difference between ":" and "->", then the latter  
might require rules to have a termination. In the theory book above  
it is a "."

> Compare with:
>
>   a: b() c
>   a: c b()

So what would these empty parenthesizes mean?

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

As for not having $, one will still need to have a symbol for  
locations. And I think of making a proposal for token numbers (used  
when making definitions in a language) and token names (apart from  
language implementation, can be used for better error messages).

> Bison currently detects uses of values for the sake of warnings, and I
> think searching for variables will make parsing the actions difficult
> especially when faced with new target languages.

I think on should settle for something that is not too difficult to  
implement.

> On the other hand, what if $ is special in some target language?
> Declaring $ as part of the value name might help:
>
>   exp($sum): exp($term1) '+' exp($term2)
>
> That is, one could potentially choose something other than $.   
> There's an
> example of this in TODO as well.  For now, we could require that  
> the first
> character be $ since searching for any arbitrary sequence in an action
> will take some work.  I'd just like to get the notation right for now.
>
> As TODO notes, there's still the issue of how to handle locations.
> Perhaps Bison could automatically append `_loc' to the value name.   
> So,
> exp($sum) would have a value of $sum and a location of $sum_loc.
>
> Or maybe it should be possible to name these separately:
>
>   exp($sum, @sum): exp($term1, @term1) '+' exp($term2, @term2)
>
> The notation is getting verbose, but how many sym locations do you
> typically use in a semantic action anyway?  You'd only need to  
> specify the
> ones you use.

I am not sure this gains anything because one is essentially  
referring to the same location on the stack, but different  
subcomponents. Another variation might be
  exp.sum: exp.term1 '+' exp.term2 {...}
And then in the action use x.value, x.location, x.token, x.name,  
where x in {sum, term1, term2}.

- I am essentially here illustrating what is going on.

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

  Hans Aberg