Re: FYI: default %printer/%destructor

[Hans Aberg]

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

> > As long as it does not close any doors, if some of the other stuff  
> > needs to be
> > implemented, whatever it may be.
>
> I've been thinking about your comment about parentheses.  It's  
> conceivable
> that Bison may one day want to use parentheses to group symbols as  
> in EBNF
> syntax.  More importantly, that's the customary usage of  
> parentheses that
> I suspect many users are familiar with in a grammar, so our  
> proposed usage
> may be misleading.

I made my EBNF proposal (in Bug-Bison, "EBNF"), because Akim seemed  
wanting to have it in Bison, and the notation, I took straight out  
the book:
> Waite, Goos, "Compiler Construction", Appendix A, p. 383, gives  
> some EBNF to BNF translation rules. I rewrite in local notation,  
> suitable for implementation in Bison:
>   1.  a(b)c := axc, x: b.
>   2.  a[b]c := ac | a(b)c.
>   3.  au+ c := axc, x: u | xu.
>   4.  au* c := a[u+]c.
>   5.  a || t := a(ta)*.
> where a, b, c are arbitrary RHS rules, x a unique non-terminal, u a  
> single or parenthesized grammar symbol, and t a terminal.
For more details, see this post.

But here, the LHSs should somehow be adapted to Bison notation. As  
you note, the symbols "( ) [ ] + * ||" become occupied. Though there  
are EBNF variations, it must be synced with the variable notation.

> Why not brackets instead?
>
>   a[name1]: b c[] address@hidden
>
> This would also encourage your braces suggestion should we ever need
> attributes in addition to value and location:
>
>   a[name1]: b c[] d[name2{@,#}] e[name3{$,#,%}]
>
> I hope we don't need that.

So the problem is that EBNF might use up "[ ]". I think "[ ]" will  
work much better than "(...)?", which is sometimes used - one needs  
to attach actions to these EBNF constructs as well, and postfix  
operators like "?" may cause problems.

Another thing that might come up is the "grammars with constraints"  
method I wrote about to prohibit certain rule expansions, as  
generalization, or grammar proper implementation of operator  
precedences. (The current token precedences are parser algorithm  
dependent.) Clearly, there is no standard notation for this :-), but  
it illustrates the problems that might come up.

  Hans Aberg