Path: utzoo!attcan!uunet!cs.utexas.edu!csd4.csd.uwm.edu!bionet!ig!arizona!gudeman
From: gudeman@arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: What I'd really like to see in an if-statement...
Message-ID: <13359@megaron.arizona.edu>
Date: 20 Aug 89 16:56:14 GMT
Organization: U of Arizona CS Dept, Tucson
Lines: 32

In article  <8620@batcomputer.tn.cornell.edu> lacey@batcomputer.tn.cornell.edu (John Lacey) writes:
>In talking about _Real Conditionals_ :), 
>...  Then we moved to simply getting full blown conditionals, like
>those in mathematics.  If (x < f() < y) ever has side effects problems in
>math., I should change majors or something, 'cause it's time to get out. :-)
>
>So far, Lisp, Icon, and BCPL have all tried and failed to meet the challenge
>(Icon came PDClose). Any more takers?

Urr.  I thought both Lisp and Icon succeeded.  They both evaluate each
argument exactly once and produce a conditional result that is true
exactly when the corresponding value in math is true.

Are you complaining about the fact that those languages don't use
boolean values?  (Lisp uses NIL/non-NIL and Icon uses
failure/success).  If so, I should point out that math doesn't use
boolean values as the result of (in)equalities either.  In math the
(in)equality is just an assertion that tells something about the
variables in the equation, but in functional/procedural programming
languages, (in)equalities are only used as controls for conditional
structures, and they work fine in both Lisp and Icon.

To be _really_ math-like the expression (i < j < k) should create a
condition on i, j, and k such the relation holds.  If this is
impossible due to other constraints, then the program should say that
there is a contradiction.  Icon actually comes closer to this than a
language with boolean results would.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@arizona.edu
Tucson, AZ 85721                 {allegra,cmcl2,ihnp4,noao}!arizona!gudeman