## [REBOL] Re: Antwort: Re: WYSIWYG programming

### From: rebol:techscribe at: 27-Oct-2000 1:29

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