[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: |
Sun, 19 Nov 2006 22:35:37 +0100 |
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
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/17
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/18
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/18
- 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,
Hans Aberg <=
- Re: FYI: default %printer/%destructor, Joel E. Denny, 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, Hans Aberg, 2006/11/19
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/19
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/20
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/20
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/20
- Re: FYI: default %printer/%destructor, Joel E. Denny, 2006/11/20
- Re: FYI: default %printer/%destructor, Hans Aberg, 2006/11/21