[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FYI: default %printer/%destructor
From: |
Hans Aberg |
Subject: |
Re: FYI: default %printer/%destructor |
Date: |
Tue, 21 Nov 2006 22:11:54 +0100 |
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
- Re: FYI: default %printer/%destructor, (continued)
- Re: FYI: default %printer/%destructor, Paolo Bonzini, 2006/11/19
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/19
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/19
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/19
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/21
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/21
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/21
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/21
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/21
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/21
- Re: FYI: default %printer/%destructor,
Hans Aberg <=
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/21
- Re: FYI: default %printer/%destructor, Paul Eggert, 2006/11/21
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/21
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/21
- Re: FYI: default %printer/%destructor, Paul Eggert, 2006/11/22
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/22
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/22
- Re: FYI: default %printer/%destructor, Paul Eggert, 2006/11/22
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/24
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/23