On 21 Nov 2006, at 19:30, Joel E. Denny wrote:
One of my worries, is what happens if one adds variables for token
values and
names.
To be more general, some day Bison might possibly need symbol
attributes
other than semantic value and location.
Right. After reality preventing me from doing this stuff, I was just
fiddling with getting my C++ parser working without having to tweak
Bison itself. Then I arrived at the idea to perhaps put into the
token values and names as parser features, along side with location.
But my plan was to take up this idea later; it came up rather
prematurely. So something else might come up in the future, though I
do not know exactly what.
Suppose, just to focus on something, the latter have symbols #, %.
Then one would end up on combinations like:
a(name1): b c() d(@#name2) e($#%name3)
I would prefer:
a(name1): b c() d(@name2, #name2) e($name3, #name3, %name3)
That is, (name1) makes all attributes available. If you want a
specific
subset, list the items in that subset.
Yes, we're back to the previous verbosity, but I think it's not
terrible,
I think it's better than ($#%name), and we appear to have no need
for it
any time soon anyway.
I think that all that makes the grammar rues harder to read should be
avoided. The often come out pretty dirty as it is. Though I do not
know what is the best method might be. Also, it is good if the user
as far as possible can avoid writing repetitions. So I think the idea
above is good if one normally would use different names for the same
stack position semantic, location, etc., values. But I suspect that
is not going to be the case. So therefore, I think it is probably
best to think OO: giving the parser stack position a name, and from
that extract subfields, whatever the syntax may be.
Hans Aberg
