Re: ending ;

[Paul Eggert]

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.

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

> I'm concerned with additional code, and the problems it will cause
> when willing to introduce new features.

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.  :-)

> 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.

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.  However, I think it's better to be consistent between
in-grammar declarations and grammar rules.  That is, if one requires
trailing ';' then the other should too.  Since POSIX says grammar
rules can omit the trailing ';', then it's mildly preferable if
in-grammar declarations can omit the trailing ';' as well.

>  Paul> The previous scanner was simpler, but the previous parser was
>  Paul> more complicated and had some undocumented dependencies on the
>  Paul> LALR(1) reduction order.  So it's not obvious that the older
>  Paul> Bison was simpler and clearer overall.
> 
> I don't see what you are referring to here.

It's basically the same thing as the first few paragraphs of
<http://mail.gnu.org/archive/html/bison-patches/2003-01/msg00061.html>

>  And Bison is quite allowed to rely on itself.

Sure, but it's a fragile dependency here.

>  Paul> The old Bison code did not always check this properly, and
>  Paul> sometimes dumped core.  The new code checks this properly,
>  Paul> and is a bit more complicated because of this extra checking.
> 
> I believe it dumped core because of your code, not because of the one
> there was before, and certainly not because of ;.

But Bison 1.75c predates the trailing-semicolon-etc changes of
2002-12-06, and it dumps core on this example:

        %union{
          int $$;
        }

        %type <int> program;
        %token <int> STR

        %%

        program : STR { $$ = $1; };

The same is true for Bison 1.75.

> 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.

>  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.