Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!yale!leichter
From: leichter@CS.YALE.EDU (Jerry Leichter)
Newsgroups: comp.lang.c
Subject: Re: What I'd really like to see in an if-statement...
Message-ID: <68833@yale-celray.yale.UUCP>
Date: 6 Aug 89 16:10:19 GMT
Sender: root@yale.UUCP
Organization: Yale Computer Science Department, New Haven, Connecticut, USA
Lines: 73
X-from: leichter@CS.YALE.EDU (Jerry Leichter (LEICHTER-JERRY@CS.YALE.EDU))

In article <5024@alvin.mcnc.org>, spl@mcnc.org (Steve Lamont) writes...
>...Since I do a lot of programming that involves mathematical expressions of
>one sort of another I often find myself wishing for an if construct that
>looks like
> 
>	if ( foo < bar < baz )
>	  do_something();
>	else
>	  do_something_else();
> 
>...Is there any reason why such a construction is not practical?  If not, why
>has no language (that I am aware of or can program in) implemented such a
>construction?  Good idea or bad idea?

This construct exists, and has the meaning you would expect, in Icon.  Someone
else has pointed out that it is also allowed in COBOL.

The reason most languages don't allow such contructs is a side-effect of a
great unifying idea that sometimes ends up getting in the way:  The idea that
relational symbols are really binary operators with Boolean values.  Having
decided that "<" is a binary operator returning a Boolean, there is no possi-
ble parse of

		foo < bar < baz

which can give you the interpretation you want:  You need a context-sensitive
parse (perhaps not a context-sensitive grammer - let's keep the technicalities
out of this) that interprets the "<" symbols differently when they are adja-
cent.

COBOL avoids this problem because it was designed before the great unifica-
tion.  It has no Booleans - its relational operators are part of the syntax
of conditionals.  (My COBOL is almost non-existent, so this may not be an
accurate rendering.)

Icon avoids this problem by taking an entirely different approach.  There are
deep reasons for the alternative approach, which I will not try to justify
here; it was not taken to make expressions like this work right, that was a
nice side-effect.

In Icon, any expression can either produce a result, or fail to produce a
result.  In an if, the controlling expression is considered true if it
produces a result, false otherwise.  Expression evaluation has an explicitly
defined order (left to right, except inside parentheses outward first), and
"failing to produce a result" is "sticky":  Once any component of an
expression fails to produce a result, the entire expression immediately
terminates, having failed to produce a result.

The "<" operation in Icon is defined so that:

	a < b	is	if a is less then b, then produce the result b,
				else fail to produce a result.

Further, "<"'s associates to the left.  Hence:

	a < b < c

is evaluated as follows:

	1.  First, we evaluate a < b.
	2.  If a is greater than or equal to b, then a < b produces no result,
		so the whole expression produces no result (is false, in the
		context of an if).

		If a is less than b, then a < b produces b.
	3.  If a < b produced a result (b), we have reduced our expression to

			b < c

		which we proceed to evalutate.

VERY clever idea!
							-- Jerry