Re: ending ;

[Akim Demaille]

| Akim Demaille <address@hidden> writes:
| > It's not 2lhs, it's nlhs.  They would be used for instance in GCC in
| > place of $0, $-1 etc.
| 
| In that case the syntax "a b: c d;" does not seem to be well-chosen.
| To me, that syntax says 'Rewrite "a b" to "c d"', i.e. it is a Type 0
| rule in the Chomsky hierarchy, which doesn't sound like it's what you
| intend here.

Well, Chomsky would have said monotonous, hence Type 1 then :)

| Instead, it would be better to have a syntax that distinguishes the
| context from the left-hand side of the rule.

a b: a c d;  ?

(a)b: c d;

I buy your argument.


| With the current Bison there is little extra code to support the POSIX
| requirement.  If this turns out to be a problem with future extensions
| we can revisit the issue then.  (We'll probably both be old and grey
| by then.  :-)

Let's make it "bold" for myself ;)


| > You also removed the ';' from the in-grammar declarations, so that
| > we also have
| > 
| > %token foo bar baz qux: bar
| > 
| > whereas the code required
| > 
| > %token foo bar baz; qux: bar;
| 
| That actually simplified the grammar in a very small way.  Also, it
| caused the in-grammar declarations to have the same syntax as ordinary
| declarations so it's a tad simpler for users.

We have the same bias: for the very same reason, I wanted to emphasize
the ended nature of the rules section.  I have still extremely
attached to this.  Open rules have always been a problem, starting
with the dangling else.  Open rules are to be avoided, and it's
already quite a problem to my eyes in the case of rules themselves, so
I do not want to reintroduce it for novel features.

Optional tokens are even worse.

So as far as %directives are concerned, I will struggle even more than
in the case of rules for which I would now agree provided a warning is
issued.


| It's certainly not a POSIX issue, and as far as I know no real
| grammars use this feature, so I won't insist strongly on this part of
| the change. 

Good :)


| > We also wants this because type checking (which is what happens there)
| > is better performed after parsing that during.  That's simpler, and
| > more modular.  It will also make it possible to support other syntaxes
| > for action code instead of something bound into the reader.
| 
| I agree with decoupling scanning from type checking, but I'm not sure
| I agree with scanning twice.  We should be able to design a system
| that needs to scan only once.  This is not primarily for efficiency
| reasons: it's because we need an easy-to-describe-to-users system
| where the scanner is independent of the levels of software above it.

I don't understand your point here.  I'm precisely saying that the
scanner does not depend on the higher levels, I'm claiming that
everything should be parsed the same way, then an AST of the grammar
should be built, and then, a traverse (very similar to type checking)
would handle the context dependent issues such as how a "token" is
handled (in the current case, how the $$ and other special markers in
the actions, are translated).


| >  Paul> Also, we'll have to explain the extra complexity to the user.
| > 
| > What do you mean?  How is the user concerned about this?
| 
| I am worried about the prospect of scanning the input twice, with
| different scanners that use different scanning algorithms, and which
| issue diagnostics in different ways.  In the end I think we'd have to
| confess this stuff to the user, just as the GCC documentation
| confesses to the user how many times GCC actually scans the input.

I don't see that.  Just as I never had to face the GCC documentation
you are referring to.  But I think we are both being typical of
ourselves here: I'm probably too biased towards the main cases, while
I fear you're being biased by nasty dark corners.

I agree that one always ends being hit by these dark corners.  But in
the current case, I fail to imagine some.