[REBOL] Re: Antwort: Re: WYSIWYG programming
From: joel:neely:fedex at: 27-Oct-2000 8:25
Hi, Elan,
Nice to hear from you! I was beginning to worry for your health.
(I've had three deaths and one wedding in my family this summer,
and an emergency hospitalization myself, so my own attendance has
been spotty at times...)
[elan--loop--com] 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).
>
Yes, the *first* error above is due to precedence. I made a mistake
doing cut-and-paste from the REBOL console and grabbed the wrong
lines.
> You can demonstrate the same behavior a little simpler by using
> >> false < true
> which generates the same error.
>
I did just that, in the *second* error message quoted above.
> 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.
>
I'll agree that the HELP description and the actual behavior are
out of synch. Whether we call that a bug in the implementation or
an error in documentation depends on having an authoritative spec.
> 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.
Without knowing the original intent (i.e., having a published spec)
I cannot say with confidence whether the defect is in the HELP
text or in the behavior. Treating the entire product (REBOL) as
a black box, I can say with confidence that there *is* a defect.
However, this was only a minor side point. My main complaint was
the ordering issue, about which more follows.
> 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.
>
No! You're mixing apples and fruit here! There is an important
qualitative difference between = and <> on the one hand, and
< , <= , > , and >= on the other.
The first two operators check *identity* of their operands, while
the last four check the *order* of their operands. There are
*many* cases for which an identity test is highly useful but for
which no natural, intuitive, or universally meaningful order
relation applies.
For instance, I can ask whether two functions are equal or differ,
and it should be clear what that means. OTOH, what sense does it
make to ask whether one function is "less than" another? Of course,
we can invent all sorts of possible orderings for various purposes,
but I hope it is clear that evaluating
>> 4 < 6.7
== true
is inherently more universal and meaningful than evaluating
>> :print < :prin
** Script Error: Cannot use lesser? on native! value.
** Where: :print < :prin
We can certainly make up some arbitrary conventions to give that
expression meaning:
* lexical order of the code as binary strings,
* length of code,
* date/time on which most recently defined,
* a partial order based on the convention that :f1 < :f2 if
f1 contains a call to f2
but I hope its clear that those are all ad hoc and not nearly of
the same nature as a simple equality test.
> > 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.
>
Try as I may (and I have), I cannot find any basis for this statement.
If you can give me one, I'd be most grateful.
Perhaps we are using the word "bug" differently. To me it has only
one meaning: there is a bug exactly (and only) when code fails to
conform to the governing specification.
If there's no such specification, I am not entitled to label as a
bug any piece of behavior I find unpleasant. I can only point out
inconsistencies with the rest of the language as *potential evidence*
of a defect in design, implementation, documentation, or planning.
That was the whole purpose of the example.
> 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"?
>
I apologize if my example wasn't sufficiently clear, but I really
don't know how to make it much clearer.
>> foo: ["a" "b" "c" "d"] == ["a" "b" "c" "d"]
>> pick foo true == "a"
>> pick foo false == "b"
Is it not clear that the position of "a" precedes the position of
b
in Foo? Is it not clear that TRUE and FALSE were used to
obtain those values? My "-th" verbal abbreviation was an analogy
based on using
>> pick foo 1.5 == "a"
>> pick foo 2.3 == "b"
as the basis of saying that the 1.5-th position of Foo precedes the
2.3-th position of Foo.
-jn-
