Path: utzoo!attcan!uunet!cs.utexas.edu!csd4.milw.wisc.edu!mailrus!ncar!ico!ism780c!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.misc
Subject: Re: What I'd really like to see in an if-statement...
Message-ID: <14251@haddock.ima.isc.com>
Date: 10 Aug 89 15:33:47 GMT
References: <8577@batcomputer.tn.cornell.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 44

In article <8577@batcomputer.tn.cornell.edu> lacey@tcgould.tn.cornell.edu (John Lacey) writes:
>As I think we have all agreed that C is not the place for these extended
>constructs, I have directed follow-ups to comp.lang.misc.

I agree; sorry I didn't redirect it myself.  (c.l.m readers: the topic is the
hypothetical change to C to make "x < y < z" mean what a mathematician would
expect, rather than the useless interpretation that C currently attaches to
it, viz. "x<y && 1<z  ||  x>=y && 0<z".)

>I agree that it doesn't belong in C.  However, I also happen to think that
>Icon's semantics are horrible.  The idea that (a < b) either fails to produce
>a result or evaluates to b is completely unintuitive.

Well, the only time you care that it happens to evaluate to b is when you're
writing "a < b < c"; otherwise, you just use it in a boolean context, where
the only important part is whether it's true or false (i.e. does or doesn't
return a value).  The actual value doesn't matter.  I don't see that this is
any more of a problem than the fact that most implementations of isalpha()
return a random nonzero value (not necessarily 1) for success.

>[karl@haddock.ima.isc.com (Karl Heuer) writes:]
>>I doubt that the parse is any more difficult than the dangling-else problem.
>
>The parse would be more difficult.  The problems aren't analogous.  The 
>dangling-else problem is one of ambiguity.  Parsing a general relational
>expression is difficult because the same string will be used for multiple
>tokens.  For example, in (a < x < b), x has to be associated separately
>to its left and right.

I don't see what you're getting at.  You simply add a new production rule
which parses "a < x < b" as a ternary operator, and produce code equivalent to
	evaluate x into temp
	compare a with temp
	jump-if-ge FALSE-BRANCH
	compare temp with b
	jump-if-ge FALSE-BRANCH
Generating the temporary is trivial for a compiler; it's not as if this had to
be parsed by a macro preprocessor.

The lookahead to distinguish the constructs "E < E < E" and "E < E" is, I
believe, no worse than the problem of distinguishing "if (E) S;" and
"if (E) S; else S;".

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint