osd@hou2d.UUCP (Orlando Sotomayor-Diaz) (07/01/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Mon, 1 Jul 85 Volume 8 : Issue 2
Today's Topics:
Section C.3.15 Conditional operator (2 msgs)
----------------------------------------------------------------------
Date: Thu, 20 Jun 85 20:58 EDT
From: ihnp4!trwrb!trwspp!spp2!jhull
Subject: Section C.3.15 Conditional operator
To: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
>Syntax
> conditional-expression:
> logical-OR-expression
> logical-OR-expression ? logical-OR-expression : conditional-expression
This allows a?b:c?d:e but not a?b?c:d:e, which seems strange, especially
as I prefer the second. (The first could be read as (a?b:c)?d:e, but
the second is unambiguous). I suggest changing the last line to
logical-OR-expression ? conditional-expression : conditional-expression
Mark,
I think you have missed the point. There is (I think) no
sequence of productions which could result in the interpretation you
show in parentheses above. While a person reading the unparenthesized
version might not know how the compiler would interpret it, the
compiler would always produce the same result. This is analogous to
establishing precedence among arithmetic operators.
Furthermore, if your productions were adopted, ambiguity
*would* result. Let me abbreviate logical-OR-expression by l-e and
conditional expression by c-e. Let me call the first production above
1 & your recommended production 2. Let me use a number in parentheses
to designate which one of several identical non-terminal symbols on a
line is to be replaced by that production. Then,
2 c-e ->
2(1) l-e ? c-e : c-e
2(2) l-e ? c-e : l-e ? c-e : c-e
1(1,2,3) l-e ? l-e : l-e ? l-e : l-e
a ? b : c ? d : e
is clearly legal even though you don't like it. But now we can see
the ambiguity. How do you parse that? Do you reduce a?b:c before you
reduce c?d:e or vice-versa? Ambiguity in a grammar refers to the
parser not being able to decide which production to apply to which
token. It does not refer to whether or not the programmer understands
what the compiler is doing.
------------------------------
Date: Sat, 29 Jun 85 17:35 EDT
From: Mark Purtill <ucbvax!Purtill@MIT-MULTICS.ARPA>
Subject: Section C.3.15 Conditional operator
To: Jeff Hull <trwrb!trwspp!spp2!jhull@BERKELEY>
First off, I know that the compiler will not misinterpert a?b:c?d:e as
(a?b:c)?d:e. But the PROGRAMMER might. To argue that this is no
problem since the compiler will know what's going on is to miss the
whole point. (I seem to recall that there was once a language in which
"ELSE" meant "then in any case, do the following." This was not usually
what the writter of the program meant; the fact that the compiler "knew"
what it was doing didn't prevent all the errors that naturally cropped
when the programmer thought "ELSE" meant "else", and eventually it had
to be changed. (Incidentally, does anyone else remember this or is it a
figment of my imagination.))
Second, a?b:c?d:e *is* unambiguous, since my production is
cond-ex := *log-ex* ? cond-ex : cond-ex.
The compiler may not reduce a?b:c first, since it's not a logical
expression, which is required for the thing before the '?'. So you must
do c?d:e => cond-ex, then a?b:cond-ex => cond-ex. If it does a?b:c =>
cond-ex, its left with cond-ex?c:d, and loses. Now, I see that it might
be hard for the compiler to deduce this fact, but that didn't seem to be
your point.
Now, personally, I'd be happy with
cond-ex := log-ex ? cond-ex : log-ex.
This forbids a?b:c?d:e, which is fine by me, and allows a?b?c:d:e. One
could even make a case for
cond-ex := cond-ex ? log-ex : log-ex,
which has the virtue that the compiler is allowed to reduce as soon as
it can. (a?b:c => cond-ex, now read ?d:e and reduce again.) But in the
interests of clarity, perhaps the production should be
cond-ex := log-ex ? log-ex : log-ex.
This forces you to replace a?b:c:d:e with a?(b?c:d):e and a?b:c?d:e with
a?b:(c?d:e). In other words, it forces parens to be used, which is
what you ought to be doing in the first place.
Basically, my complaint is that the existing production encourages code
that could be misread (and there doesn't seem to be any good reason for
this) while not allowing the still unpleasant but somewhat nicer form
that I prefer.
Mark
^.-.^ Purtill at MIT-MULTICS.ARPA **Insert favorite disclaimer here**
((")) 2-032 MIT Cambridge MA 02139
------------------------------
End of mod.std.c Digest - Mon, 1 Jul 85 09:57:50 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.