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.