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