Hi Joel,
let me correct a little mistake in your examples
Joel Neely wrote:
> Now, notice that we aren't allowed to compare logic! values????
>
> >> to-logic 0 < to-logic 1
> ** Script Error: Expected one of: integer! - not: logic!.
> ** Where: to-logic 0 < to-logic 1
> >> false < true
> ** Script Error: Cannot use lesser? on logic! value.
> ** Where: false < true
The error you report has to do with precedence. REBOL is attempting to
compare the integer 0 to the logic value true (resulting from to-logic
1). Compare to the parentheses you use further down, when comparing
to-integer false to to-integer true. The parentheses are needed here as
well.
> >> (to-integer false) < (to-integer true) == true
>
The correct notation would be
>> (to-logic 0) < (to-logic 1)
which generates a different error, namely
** Script Error: Cannot use lesser? on logic! value.
** Where: (to-logic 0) < (to-logic 1)
You can demonstrate the same behavior a little simpler by using
>> false < true
which generates the same error.
If you look at the correct error message, I think you will agree with me
that without a doubt this is a bug, since help lesser? reports that
lesser? accepts any datatype. Since logic! is a datatype, lesser? should
accept true and false as arguments. As a bug it does not really qualify
as a design issue. Note that we can compare
>> true = false
== false
and
>> true <> false
== true
So comparisons are defined for logic values, and the comparison fails in
this case, because it is not implemented correctly.
> On the other hand:
>
> >> pick foo true == "a"
> >> pick foo false == "b"
> >> fum: true == true
> >> foo/:fum == "a"
> >> fum: false == false
> >> foo/:fum == "b"
>
> So, we can't compare logic! values, apparently due only to some
> type-checking rule in the comparison operators.
The same applies to this observation. It is not a type-checking rule,
just plain old buggy implementation.
> But if we could,
> the way they inter-convert with integer! values would lead us to
> conclude that FALSE precedes TRUE. But that is inconsistent with
> the fact that the TRUE-th position of a block precedes the FALSE-th
> position of the block!
I don't agree with this observation. What makes you think that "TRUE-th
position of a block precedes the FALSE-th position of the block"?
Hope this sheds a little light,
Elan
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
