But I think that misses the point. It's not an issue of a *variable*
having a value that may be true and may be false, but of a *value*
being neither true nor false.
Incidedntally, another way of looking at this whole issue is that what
MUMPS attempts to do is define operators in such a way that they are
total functions. For example, in most languages
"hello" + 3
would be syntax error, but in MUMPS, "hello"+3 *does* have a value
(it's 3). IEEE 754 takes this a step further, introducing a new value
NaN ("Not a Number") to floating point arithmetic, attempting to make
operators such as division total. But these solutions involve an
implicit type system, because (in the MUMPS example) "+" becomes
polymorphic.
Another (IMO, more problematic) issue is this: If we take 0 to mean
false and non-zerto to mean true, then if x = 1 and y = 2, then we have
x is false
y is false
x - 1 is true
y - 1 is false (!)
so the normal arithmetic operators are not even well-defined over
Boolean values.
--- James Gray <[EMAIL PROTECTED]> wrote:
> Yes! That might be kind of normal for something to sometimes be true
> and
> sometimes false. Couldn't the following code be useful someplace?
>
> S IEN="@"
> F S IEN=$O(^DATA(IEN),-1) Q:(IEN-1) D
> .some more code
>
> Jim Gray
>
===
Gregory Woodhouse <[EMAIL PROTECTED]>
"Perfection is achieved, not when there is nothing more
to add, but when there is nothing left to take away."
-- Antoine de Saint-Exupery
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
