Hi, Brett,
Actually, you remind me of another point which I failed to raise...
Brett Handley wrote:
>
> ... result encourages one to use a form that has the least effect
> on the "parent/calling expression" - whether you evaluate the
> condition early eg:
> condition-result: dummy = 1
> or you evaluate it late using the function:
> condition-result: does [dummy = 1]
>
> Your "parent expression" eg.
> print condition-result
>
> Need not change (unless of course dummy does). A nice finding.
>
That also points out another drawback of the
any [expr]
and
all [expr]
versions; they do not preserve the type of (the evaluation of) EXPR
for FALSE values, but yield NONE instead! This can become an issue
in various ways, such as causing erroneous results when comparing
with LOGIC! values from other expressions (FALSE does not equal NONE)
or causing type errors when handing off to a mezzanine which expects
a LOGIC! argument.
While there are workarounds based on standard boolean identities:
true and all [expr]
or
false or all [expr]
they simply obscure what is being expressed, IMHO.
Per the extreme guys, "Do the simplest thing that could possible work!"
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
Enron Accountingg in a Nutshell: 1c=$0.01=($0.10)**2=(10c)**2=100c=$1
--
To unsubscribe from this list, just send an email to
[EMAIL PROTECTED] with unsubscribe as the subject.
