Joel Neely wrote:
> 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...)
Sorry to hear of your losses. Hope everything is well with you. I have
simply been (and continue to be) very busy, trying to catch up with the
time I lost writing the book (time measured in terms of income that is).
I will try to take some time over the weekend to respond to your message.
Can't do it right now, because I have to run (hate mettings ....).
Take Care,
Elan
>
>
> [EMAIL PROTECTED] 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-
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
