Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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