Am Dienstag, den 11.08.2020, 17:01 -0700 schrieb Richard Smith:
> On Tue, 11 Aug 2020, 16:07 Uecker, Martin, <
> Martin.Uecker_at_med.uni-goettingen.de> wrote:
>
> > Am Dienstag, den 11.08.2020, 15:35 -0700 schrieb Richard Smith:
> > > On Tue, 11 Aug 2020, 14:36 Uecker, Martin, <
> > > Martin.Uecker_at_[hidden]> wrote:

...
> > >
> > > I don't know (maybe Bjarne can tell us) but I doubt that was the reason.
> > > Rather, I suspect that when C++ started to allow declarations to appear
> > > anywhere in a compound-statement, modelling declarations as a kind of
> > > statement was the simplest way to get that effect. And it makes sense and
> > > simplifies the model to only have one kind of thing that can appear in a
> > > compound-statement.
> >
> > I can't see this. You just have the alternative declaration
> > vs. statement somewhere else in the parser/grammar. This
> > should have the same implementation complexity.
> >
>
> It's a question of the user-facing complexity, not the implementation
> complexity. It's simpler to say that an expression-statement, a
> declaration-statement, and an if-statement are siblings than to introduce
> hierarchy between them that makes no difference in practice.

I also don't see this. For a user, it gets much simpler because
you can place labels everywhere you need to without adding
null statements.

> > But this left open two corner cases:
> > > >
> > > > - The 'if (1) int i;' example, because declarations were now
> > > > also allowed where only statements make sense.
> > > >
> > >
> > > This seems like a natural consequence of uniform rules to me rather than
> >
> > a
> > > corner case.
> > > I suppose it depends whether you're more used to the C or C++
> > > rules, but I find the C behaviour for this example to be the corner case.
> > > *shrug*
> >
> > If you bought into the idea that declarations and statements
> > should be treated identically, I can see how you could come
> > to this conclusion.
> >
> > But to me this makes no sense and the corner case is just
> > one example.
> >
> > Here is another one: Should this be allowed?
> >
> > for (if (1) j = 3; j < n; j++)
> >
>
> In an expression-oriented language, yes. But the block structure of C and
> C++ isn't well-suited to such constructs. So we restrict to only some of
> the forms of statement.

> > - Placement of labels at the end of compound statements is
> > > > still not allowed. (which requires teaching people to add
> > > > pointless null statements)
> > > >
> > >
> > > This is indeed a consequence of only having one kind of thing that can
> > > appear in a compound-statement.
> >
> > I fail to see why this is important or desirable.
> >
> > > I wonder, do you have implementation experience for your new rule? For a
> >
> > I am never proposing anything I can not implement.
> >
> > I implemented it in the compiler I am in the progress of writing.
> > It is still far from finished but
> > has a fairly complete C
> > frontend and compiles many interesting examples. This was
> > very easy to
> > implement and caused no problems.
> >
>
> I would expect the problems to emerge when retrofitting this into an
> existing implementation based around the old rules :)

I don't expect problems. C never unified
declaration and statements as C++ did it. In a block-item
there were always separate cases and I would expect an
implementation to follow the old grammar.

Although the implementers present at the meeting agreed
to the change (or even helped shape it).

But as I am the one probably ending up adding it to GCC,
we will see.

> > recursive descent parser, I'd expect it to be quite awkward to recursively
> > > parse an unbounded sequence of labels as part of statement parsing only
> >
> > to
> > > find that you hit a close brace and aren't actually parsing a labelled
> > > statement at all.
> >
> > The proposed grammar prevents this:
> >
> > block-item = label | declaration | unlabeled-statement
> > labeled-statement = label unlabeled-statement

correction:

labeled-statement = label statement
statement = labeleled-statement | unlabeled-statement

> > So inside a compound statement you do not recurse into
> > labels when parsing statements.
> >
>
> And presumably you allow the substatement of an if/while/... to be either
> an unlabeled-statement or a labeled-statement?

Yes, a statement which then can be a labeled-statement
or unlabeled-statement.

> (Minor: that does not appear to allow two labels on the same statement
> except in a block. But maybe that's handled in part of the grammar you
> didn't show.)

See above. Sorry for the confusion.

> That's quite a departure from the classical rules, and the different
> treatment in blocks versus other contexts is a surprise. But OK.

For C, it is not really a difference to the old rules
as declarations and statement were always separate and
two different possible block-items.

> > In contrast, the new rule in C has neither problem and
> > > > is more logical: Labels are about control flow and make
> > > > sense everywhere where statements make sense.
> > > >
> > >
> > > Hm, would you allow a label after `if (` or `for (`? At least in C++,
> > > that's somewhere where (a restricted set of) statements can appear.
> >
> > Similar to my example above ;-)
> >
> > I did not know that C++ allowed statement other than
> > and declarations there.
> >
>
> Only declaration-statements, expression-statements, and empty statements.

I see. But no labels in front I guess. It
also seems inconsistent to sometimes allow
labes in front of statements and sometimes not.

Best,
Martin

> I would not allow statements or labels.
> >
> > Best,
> > Martin
> >
> >
> > > (In contrast, declarations are about introducing names
> > > > and should interact well with scoping rules, so really
> > > > should follow different rules.)
> > > >
> > > > Best,
> > > > Martin
> > > >
> > > >