Path: utzoo!utgpu!watmath!att!bellcore!rutgers!usc!cs.utexas.edu!csd4.milw.wisc.edu!leah!rpi!batcomputer!lacey
From: lacey@batcomputer.tn.cornell.edu (John Lacey)
Newsgroups: comp.lang.c
Subject: RE: What I'd really like to see in an if-statement...
Message-ID: <8577@batcomputer.tn.cornell.edu>
Date: 8 Aug 89 17:43:36 GMT
Reply-To: lacey@tcgould.tn.cornell.edu (John Lacey)
Followup-To: comp.lang.misc
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 82

On Aug 8,  1:46am, Karl Heuer wrote:
} Subject: Re: What I'd really like to see in an if-statement...
} 
} In article <14521@bfmny0.UUCP> tneff@bfmny0.UUCP (Tom Neff) writes:
} >It would be fun to have such a thing, it would make expressing lots of
} >conditions more concise and everyone would use it.  However it would
} >break a lot of things in "C" (the expression above IS VALID C right now,
} >for instance, with a totally different meaning) and parsing would be a
} >nightmare.  I wouldn't hold my breath.
} 
} It would "break a lot of things in C"?  I admit that "x<y<z" is currently
} valid C, but I seriously doubt that it gets used heavily!  (Outside the
} Obfuscated C Contest, anyway.)  And 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.

} But still, it would be a new wart in a language that already has too many.  If
} it could be defined in such a way that the language became *simpler*, I'd like
} it a lot more.  (The ICON semantics come to mind.)

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.  

} Btw, one of my own pet ideas for "D" is the same notation in a loop construct:
} 	for (lo <= var < hi) ...
} which would mean the same thing as C's
} 	for (var = lo; var < hi; ++var) ...
} except that hi would be evaluated only once, and it would be illegal to change
} the value of var within the loop.  (I.e., it would be your standard for-loop
} as in BASIC/FORTRAN/PASCAL.)  All eight sensible combinations of relational
} operators would be allowed.  (The construct
} 	for (hi > var >= lo) ...
} would step through the same values via a decrementing loop.)

This is a nice idea.  Also, parsing is simplified here, because the var
need not be split into 2 tokens.

} The only other proposal I've seen for such a feature uses notation like
} 	for (var in [lo, hi)) ...
} but the syntax for the half-open interval is ugly.  (And "[lo, hi[" is worse.)

Well, _I_ don't think it's ugly.  And it could be made less so, by removing
the redundant parentheses.  Simply say

	for var in [a, b) ...

as the shell languages do.  The difficulty of this construct, or perhaps
the beauty, is that the syntax cries out for non-determinism.  That is, 
this construct should not be required to let var be a, a+1, ..., b-1
in that order, but should be free to bind var to every value in the 
interval in any order.  Hence, it would still be nice to keep your 
previous pet idea around, for times when sequence really matters.

} Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
} 
}-- End of excerpt from Karl Heuer

It seems that SETL may already have both of these constructs.

Sequential:           for var in {a..b-1} do <stmts> end for;

Non-deterministic:    for var in [a..b-1] do <stmts> end for;

where {...} is a set, and [...] is a tuple.


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.

Cheers,

-- 
John Lacey     lacey@tcgould.tn.cornell.edu    cornell!batcomputer!lacey

After August 16:  jjlacey@owucomcn.bitnet
If you have to, try  mdl@sppy00.UUCP or maybe {...}!osu-cis!sppy00!mdl