In how many ways should this fail?

[Keith Thompson]

OK, so the C standard uses a far more pedantic and unwieldy way of
expressing syntax than I would, if it has to enforce each of the 17
precedence levels in the grammar!

(I would write the formal syntax as just:

expr ? expr : expr

worrying about any restrictions on each expr later, while the production of
'expr' doesn't itself worry about precedence (which would just be an
attribute of a binary operator).

I've implemented such a conditional operator for real, using this informal
approach, and it works fine. Although I do insist in enclosing the thing in
parentheses.)

If you "insist on enclosing the thing in parentheses", then you're
describing a different grammar than the one the C standard describes.

Enforcing the 17 precedence levels by defining them in the grammar makes
some things easier; you don't need another level of logic to resolve
operator precedence.

And I would think that defining every kind of expression as "expr" would
create a lot of cases where an expression can't be parsed unambiguously.

Perhaps your approach is valid, but the one used by the standard is
certainly valid as well. (Personally I like the standard's approach
better, but that's a matter of opinion.)

[...]

You have to look further into the Standard to discover that
'assignment-expression' just means 'any expression'.

So look further into the Standard.

Whatever the merits of
defining the grammar in this way, it's not very intuitive; the above
suggests that any conditional expression is a form of assignment!

As I said in my other response, the names are a little unintuitive
*unless you understand what they really mean*. Other than radically
changing the way the grammar is defined (would you advocate doing
that?), I can't think of a better way of naming the various productions.

 

[Keith Thompson]

You have to look further into the Standard to discover that
assignment-expression' just means 'any expression'. Whatever the
merits of defining the grammar in this way, it's not very intuitive;
the above suggests that any conditional expression is a form of
assignment!

Sorry, I overlooked your error here. An assignment expression is *not*
just "any expression". For example, the expression

x, y

is not an assignment-expression.

 

[Keith Thompson]

If it had to exactly model the way C does it, that might be true.

And that's exactly what the C standard has to do.

But I
think C has too many restrictions. Also it's not really that readable unless
accompanied by explanatory notes. In that case you might as well express it
less formally.

Are you talking about C, or about some hypothetical other language with
a grammar more to your liking? If the former, you're mistaken. If the
latter, why are you discussing it here?

Can you at least make it clear what you're talking about?

[...]

 

[Tim Rentsch]

<talking about:>

a > b ? a : b = 42;

What should one expect?

(a>b) ? a : (b=42);

In C (given that [foo() ? a : b] isn't an lvalue), that seems a
perfectly sensible parse to me.

It might be sensible, but it's no what C's syntax mandates. A
conforming compiler must parse it as

((a > b) ? a : b) = 42;

I've seen this assertion (or a similar one) made in several
posts in this thread. I will make a different assertion.
The program fragment (written as an expression statement)

a > b ? a : b = 42;

is a syntax error. It has no valid parse under the standard
C grammar, any more than

a + b = c;

does.

 

[Philip Lantz]

That's not strictly true (take x = y++; for example).

No, it's true there, too--if you recognize that completion of side-
effects are separate from evaluation.

(By the way, I agree with all the rest of your post that I snipped,
Ben.)

 

[BartC]

And that's exactly what the C standard has to do.


Are you talking about C, or about some hypothetical other language with
a grammar more to your liking? If the former, you're mistaken. If the
latter, why are you discussing it here?

Can you at least make it clear what you're talking about?

I'm talking about C. But also about the fact that, for a supposedly simple
language, it's grammar is complex (13 or 14 levels to define an expression
for example). And far from making things unambiguous, sometimes has the
opposite effect! (See the posts about ?: followed by an assignment).

To put it another way, if I was writing a C-syntax parser, I wouldn't bother
trying to use the grammar. But I would probably have to spend considerable
time 'hobbling' the syntax if I wanted it to be 100% compatible with
standard C. (Not allowing ?: constructs as lvalues for example.)

BTW any C compilers with extensions, probably cannot use the grammar as
given anyway.

 

[BartC]

The program fragment (written as an expression statement)

a > b ? a : b = 42;

is a syntax error. It has no valid parse under the standard
C grammar, any more than

a + b = c;

But is it actually reported as a syntax error?

I would suggest this would be a type error rather than syntax (for example
you can't apply address-of & to the result of a+b).

 

[Ben Bacarisse]

According to him, he have found three different compilers with three
different ways of handling this. One did nothing, one always assigned
to b, and the last one did what one should expect, were it legal.

<talking about:>

a > b ? a : b = 42;

What should one expect?

(a>b) ? a : (b=42);

In C (given that [foo() ? a : b] isn't an lvalue), that seems a
perfectly sensible parse to me.

It might be sensible, but it's no what C's syntax mandates. A
conforming compiler must parse it as

((a > b) ? a : b) = 42;

I've seen this assertion (or a similar one) made in several
posts in this thread. I will make a different assertion.
The program fragment (written as an expression statement)

a > b ? a : b = 42;

is a syntax error.

And you would be right to make that assertion! The grammar is indeed
different between C and C++ but in C there is no valid parse for the
above.

 

[James Kuyper]

But is it actually reported as a syntax error?

I would suggest this would be a type error rather than syntax (for example
you can't apply address-of & to the result of a+b).

As the C standard is currently written, both of these are constraint
violations, but the relevant constraint is not type-based. "An
assignment operator shall have a modifiable lvalue as its left operand."
(6.5.16p1). A modifiable lvalue which had exactly the same type as a+b
would be perfectly acceptable for the left operand.

 

[James Kuyper]

On 02/01/2012 06:57 AM, BartC wrote:
....

I'm talking about C. But also about the fact that, for a supposedly simple
language, it's grammar is complex (13 or 14 levels to define an expression
for example). And far from making things unambiguous, sometimes has the
opposite effect! (See the posts about ?: followed by an assignment).

There is no ambiguity in the C standard about how "a ? b : c = d" should
be parseed. There was some confusion about what the standard actually
says about this, (confusion to which I initially contributed), but no
one has suggested that there's two or more different ways to interpret
what it does say.

To put it another way, if I was writing a C-syntax parser, I wouldn't bother
trying to use the grammar.

One of the strengths of C, IMO, is that there's a great many ways in
which things you really shouldn't be doing are detected as such because
they are syntax errors. There's plenty of room for improvement in that
area, but your approach would be a move in the wrong direction.

....

BTW any C compilers with extensions, probably cannot use the grammar as
given anyway.

Most certainly do, as a starting point and foundation upon which the
extensions are built.

 

[Ben Bacarisse]

But is it actually reported as a syntax error?

No, not by either gcc or clang. This is one reason I missed the fact
that it's a syntax error (the other being I did not read the grammar!).

But that's OK. Errors ("constraint violations") need to be reported,
but there's no requirement on exactly how this is done.

I would suggest this would be a type error rather than syntax (for
example you can't apply address-of & to the result of a+b).

That's how both clang and gcc decide to do it. They alter the grammar
and later report a missing lvalue on the left of the assignment. This
is a risky strategy, since you have to be sure that everything that
you've let though will get caught later.

A little experimenting suggests that both alter the grammar to be:

assignment-expression:
conditional-expression
conditional-expression assignment-operator assignment-expression

rather than

assignment-expression:
conditional-expression
unary-expression assignment-operator assignment-expression

The change permits, on the left of an assignment, expressions with
operators whose "precedence" is between that of the unary operators and
the conditional operator. I think this is safe because none of these
extra expression forms can be an lvalue, so all of the newly accepted
syntax will be reported later.

 

[James Kuyper]

And you would be right to make that assertion! The grammar is indeed
different between C and C++ but in C there is no valid parse for the
above.

Yes there is: ((a>b) ? a : b) = 42. That parse is a constraint
violation, but not a syntax error.

 

[Ben Bacarisse]

Yes there is: ((a>b) ? a : b) = 42. That parse is a constraint
violation, but not a syntax error.

assignment-expression:
conditional-expression
unary-expression assignment-operator assignment-expression

If 'a > b ? a : b = 42' is to be parsed as an assignment expression,
what precedes the '=' must be produced by unary-expression. There's no
sequence of productions from unary-expression that can produce
'a > b ? a : b'.

 

[James Kuyper]

assignment-expression:
conditional-expression
unary-expression assignment-operator assignment-expression

You're right. Sorry - I'm not sure how I reached that conclusion.

You know, there are people who've accused me of thinking I'm infallible.
I can't imagine how they reached that conclusion - I make mistakes like
this constantly.

 

[Tim Rentsch]

You're right. Sorry - I'm not sure how I reached that conclusion.

You know, there are people who've accused me of thinking I'm infallible.
I can't imagine how they reached that conclusion - I make mistakes like
this constantly.

Could it be because, despite continuing to make them, there is a
tendendency to tune out contrary suggestions rather than further
discussion and re-examination?

(Yes, I'm aware of the irony in my comment.)