Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Denver Mods 4/2/84) 6/24/83; site drutx.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!harpo!ihnp4!drutx!opus
From: opus@drutx.UUCP (ShanklandJA)
Newsgroups: net.lang.c
Subject: Re: return expr and if expr
Message-ID: <319@drutx.UUCP>
Date: Tue, 15-May-84 09:49:32 EDT
Article-I.D.: drutx.319
Posted: Tue May 15 09:49:32 1984
Date-Received: Wed, 16-May-84 07:09:38 EDT
References: <853@druxm.UUCP>, <162@gloria.UUCP> <2062@brl-vgr.ARPA>
Organization: AT&T Information Systems Laboratories, Denver
Lines: 36

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