From: ptkwt@...1.aracnet.com (Phil Tomson)
Date: 2002-10-27T10:07:31+09:00
Subject: Re: How come true, false don't support <=> (comparison) operator?

In article <Pine.LNX.4.44.0210261701170.16157-100000@candle.superlink.net>,
 <dblack@candle.superlink.net> wrote:
>Hi --
>
>On Sun, 27 Oct 2002, Simon Cozens wrote:
>
>> dblack@candle.superlink.net writes:
>> > 1. Why couldn't one swap 'true' and 'false' in your square-bracket
>> > comments in the above?
>>
>> You mean like in Unix, where 0 means success and non-zero means failure?
>
>Sort of, but more abstractly.  I was trying to suggest that if the
>equivalence 1:true, 0:false was what made true > false, and if that
>equivalence was purely conventional (and could be flipped without any
>loss of logical integrity), 

Well, no.  Don't think of 1 and 0 here as inegers where we know that 1>0 
is a true statement for the integers.  Look at it in terms of the 
operators and (&&) and or (||):

given an x which can take on either the value true or false, the identity 
property must hold:

x && true = x         x || false = x

This implies some ordering.  

Here's a lattice:

                    {a,b}= true   set union (or) (join, or least upper bound)
                     / \
                    /   \
                  {a}   {b}
                    \   /
                     \ /
                     { } = false  set intersection (and) 
                              (meet, or greatest lower bound)
where { } means empty set

if a = true it doesn't matter what b's value is:  a + b = true
if a = false it doesn't matter what b's value is: a && b = false

There is a defined order between true and false (true > false) because of 
the way we define how the operators are to work on those values.

>then it perhaps didn't make sense for it
>to govern the behavior of Ruby true/false.  

Well, maybe the easier way to look at it is:

The set of the positive integers is: [1,2,3..... infinity]

The set of possible boolean values is: [false,true]

(now switching sides in the debate :)
In Ruby there is some type relationship between 1 and 2 (they're both 
members of the FixNum class).  But in Ruby there is no type relationship 
between false and true (false is the one and only instance of the 
FalseClass and true is the one and only instance of the TrueClass.  So, 
perhaps one could make the case that we don't need true > false since they 
are members (representatives) of two totally unrelated classes.  

(switching back :)
But that argument might rely too heavily on trying to make the OO 
structure the model for reality instead of vice-versa.
Anyway, I guess I'm in the camp that would like to see some kind of 
hierarchy like:

class Boolean
....
end

class TrueClass < Boolean
....
end

class FalseClass < Boolean
....
end

Then there would be some kind of type relationship between TrueClass and 
FalseClass.  That would just seem to make more sense to me, but I do see 
the potential pitfalls with that approach too.

Phil