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

[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-