🚀 go-pugleaf

I've been following this, wondering if someone form the Icon group
would speak up. Since nobody has, and Karl came close to their
solution, I'll put an oar in...

In article <14278@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
<Okay, then, here's one way to parse such constructs.  A comparison operator
<like "a < b" returns an object of an internal type "cascadable boolean", whose
<value is either {FALSE} or {TRUE, b}.  If a cascadable boolean is used in any
<context other than the left operand of a compare, it immediately decays
<into a normal boolean.  If it is the left operand of a compare, then
<"{FALSE} < c" returns {FALSE} (but should probably still evaluate c for side
<effects), while "{TRUE, b} < c" returns the same object as "b < c" (another
<cascadable boolean).

The Icon group find a slightly cleaner way to do this. Instead of
expression evalutaing to booleans, they either produce a value, or
"fail". Any expressions including a failed expression also fail, except
for "not" (which is classed as a control structure). If the expression
fed to not fails, then it returns a null value; otherwise, it fails.

Control constructs treat failed expressions as false, and valued
expressions as true. Relops are handled roughly as above, except that
where they return the value of the right-hand operand or fail. So that

	if a < b < c < d then

Will work as you'd expect - succeeding only if all the comparisons are
true. Likewise for:

	if a < b <= c = d < e then

etc, etc, etc.

I found this feature quite nice, and easy to work with. The concept of
"failure" also has interesting implications elsewhere, and works well
with the rest of the language.

The reference is "The Icon Programming Language", by Griswold &
Griswold. You can get Icon by ftp from several sites on the internet.

	<mike
--
Tell me how d'you get to be				Mike Meyer
As beautiful as that?					mwm@berkeley.edu
How did you get your mind				ucbvax!mwm
To tilt like your hat?					mwm@ucbjade.BITNET