Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > In how many ways should this fail?

Reply
Thread Tools

In how many ways should this fail?

 
 
Keith Thompson
Guest
Posts: n/a
 
      02-01-2012
"BartC" <(E-Mail Removed)> writes:
> "Ben Bacarisse" <(E-Mail Removed)> wrote in message
> news:0.d2a24acbe4d003562f6e.20120130214854GMT.8739 (E-Mail Removed)...
>> "BartC" <(E-Mail Removed)> writes:

>
>>> That doesn't make sense at all. The conditional-operator syntax is more
>>> like:
>>>
>>> expression1 ? expression2 : expression3

>>
>> That's not how syntax is expressed. You'd need productions for all of
>> expression1, expression2, and expression3. The C grammar correctly
>> encapsulates what is valid (syntactically) and what it not.

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

[...]

>> assignment-expression:
>> conditional-expression
>> unary-expression assignment-operator assignment-expression
>>
>> just says that an assignment expression can be a conditional expression
>> on its own.

>
> 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 (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-01-2012
"BartC" <(E-Mail Removed)> writes:
> "Ben Bacarisse" <(E-Mail Removed)> wrote in message
> news:0.d2a24acbe4d003562f6e.20120130214854GMT.8739 (E-Mail Removed)...

[...]
>> assignment-expression:
>> conditional-expression
>> unary-expression assignment-operator assignment-expression
>>
>> just says that an assignment expression can be a conditional expression
>> on its own.

>
> 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 (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-01-2012
"BartC" <(E-Mail Removed)> writes:
> "Ben Bacarisse" <(E-Mail Removed)> wrote in message
> news:0.e5f0e9b80e794db35f9e.20120131135739GMT.87fw (E-Mail Removed)...
>> "BartC" <(E-Mail Removed)> writes:

>
>>> (I would write the formal syntax as just:
>>>
>>> expr ? expr : expr

>
>> Your example says less. Until you say how you would convey all the
>> information conveyed by C's grammar, there is no fair comparison.

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

[...]

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      02-01-2012
Ben Bacarisse <(E-Mail Removed)> writes:

> gwowen <(E-Mail Removed)> writes:
>
>> On Jan 30, 3:32 pm, Anders Wegge Keller <(E-Mail Removed)> wrote:
>>
>>> 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. It has no valid parse under the standard
C grammar, any more than

a + b = c;

does.
 
Reply With Quote
 
Philip Lantz
Guest
Posts: n/a
 
      02-01-2012
Ben Bacarisse wrote:
>
> "BartC" writes:
> > You can evaluate the left and right sides of the assignment in any
> > order, but the assignment itself can only take place after both have
> > been evaluated.

>
> 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.)
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      02-01-2012


"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "BartC" <(E-Mail Removed)> writes:
>> "Ben Bacarisse" <(E-Mail Removed)> wrote in message
>> news:0.e5f0e9b80e794db35f9e.20120131135739GMT.87fw (E-Mail Removed)...
>>> "BartC" <(E-Mail Removed)> writes:

>>
>>>> (I would write the formal syntax as just:
>>>>
>>>> expr ? expr : expr

>>
>>> Your example says less. Until you say how you would convey all the
>>> information conveyed by C's grammar, there is no fair comparison.

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


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

 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      02-01-2012
"Tim Rentsch" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

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

--
Bartc

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-01-2012
Tim Rentsch <(E-Mail Removed)> writes:

> Ben Bacarisse <(E-Mail Removed)> writes:
>
>> gwowen <(E-Mail Removed)> writes:
>>
>>> On Jan 30, 3:32 pm, Anders Wegge Keller <(E-Mail Removed)> wrote:
>>>
>>>> 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.

--
Ben.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      02-01-2012
On 02/01/2012 07:14 AM, BartC wrote:
> "Tim Rentsch" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>> 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).


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
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      02-01-2012
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.
--
James Kuyper
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
How many ways we can call servlet from jsp? Garg Java 1 08-04-2006 05:59 AM
I need help in many ways (with Usenext) Nightcrawler2525 Computer Support 8 08-02-2006 11:19 PM
How many ways to watch Media Center recording on another TV? Lew DVD Video 0 07-03-2006 01:21 AM
how many ways to convert a integer to a string apple.davinci@gmail.com C Programming 12 03-10-2006 09:18 PM



Advertisments