[net.lang.c] return expr and if expr

colonel@gloria.UUCP (George Sicherman) (05/13/84)

[if (lineeater) delete();]

"if expr" is impractical.
"return expr" is unambiguous, but how would you parse

	if x ++ y;

?
-- 
Col. G. L. Sicherman
...seismo!rochester!rocksvax!sunybcs!gloria!colonel

gwyn@brl-vgr.ARPA (Doug Gwyn ) (05/15/84)

If one is serious about changing if & when syntax to remove ( ),
then something else must also be changed to indicate grouping.
The usual solution is something like
	if cond then stmt fi
where if, then, & fi are keywords.

Better yet is
	if cond then expr fi
so we can get rid of the ternary operator ? : .
Keep going, and you end up with a language that looks a lot like
Algol-68.

opus@drutx.UUCP (ShanklandJA) (05/15/84)

Doug Gwyn says:

    If one is serious about changing if & when syntax to remove ( ),
    then something else must also be changed to indicate grouping.
    The usual solution is something like
	    if cond then stmt fi
    where if, then, & fi are keywords.

Far be it from me to intrude on the original discussion about whether
"return(expr)" is better than "return expr" or vice versa (though my
stomach just rumbled something that sounded suspiciously like
"who cares?").

But Doug's statement above sure looks wrong to me.
Looks to me as though the 'if' and 'then' keywords already bracket
the condition, and the presence or absence of a 'fi' in the language
has nothing to do with whether or not the language requires the
condition to be parenthesized.  Keywords like 'fi' end up in languages
to get rid of the "which if does this else belong to" confusion, as in:

/* BEFORE: */
if a then
    if b then
	c
else d     /* indentation is misleading, "else d" goes with "if b" */

/* AFTER: */
if a then
    if b then
	c
    fi
else d
fi         /*  fee, fi, fo, fawn, ambiguity is gone! */

Jim Shankland
..!ihnp4!druxy!opus

jim@ism780.UUCP (05/16/84)

#R:gloria:-16200:ism780:12500007:000:455
ism780!jim    May 14 19:36:00 1984

> "if expr" is impractical.
> "return expr" is unambiguous, but how would you parse
>
>         if x ++ y;

How would you parse if (x) if (y); else z; ?
The general rule is that shift takes precedence over reduce,
so      if x ++ y;  ==>  if (x ++) y;

I am not saying allowing "if expr" is good language design (is the concept
relevant in a discussion about C?), just what I would expect if it were
allowed.

-- Jim Balter, INTERACTIVE Systems (ima!jim)

adm@cbneb.UUCP (05/16/84)

#R:gloria:-16200:cbnap:16200001:000:268
cbnap!whp    May 16 10:07:00 1984

In the C language reference manual, under the section of Unary Operators,
it says:
Expressions with unary operators group right to left.

Does anyone know what this means?  It might mean that "if x ++ y;",
if legal, would be parsed as "if (x) ++y;", but I'm not sure.