## [REBOL] Re: Rebol interpreter bug with comparison of dates

### From: joel:neely:fedex at: 4-Dec-2002 14:57

Hi, Jan, Just to take the "road less travelled"... ;-) Jan Skibinski wrote:> But what does this mean: > >> safe-greater? 2x4 1x3 > == true > > This is a classical example of concept stretching and this > is what bites later on... >I'm actually sympathetic toward your skepticism re "concept stretching" and have raised questions about how much we can sweep under the rug of polymorphism . However, on the specific issue of comparing PAIR! values, we've had this debate on the list a while back, and my personal conclusion was that 2x4 > 1x3 should evaluate to TRUE (and, of course, reversing the values should return FALSE ;-) My basis for arguing that position was that REBOL already has "unified" a number of data types through the concept (though without official terminology) of ordered composite values. Specifically, there are many types for which FIRST , SECOND , and so on, are defined. For example, in addition to the series types, for which the ordinal selectors have the obvious meaning, REBOL applies the selectors to dates as follows:>> foo: now/date == 4-Dec-2002 >> first foo == 2002 >> second foo == 12 >> third foo == 4to times as:>> foo: now/time == 14:27:01 >> first foo == 14 >> second foo == 27 >> third foo == 1and so on. (And we have the shorthand of X/1 for FIRST X and so on.) Now, if we have a type which is a sequence of component types, where each component type posesses a set of ordering relations, it seems perfectly reasonable to define the ordering relations on the (top-level) type in terms of the lexicographic ordering across the collection. In pseudo-REBglish, a < b whenever any [ a/1 < b/1 all [a/1 = b/1 a/2 < b/2] all [a/1 = b/1 a/2 = b/2 a/3 < b/3] ... and so on ... ] This works exactly as expected for DATE! and TIME! values, but also works for heterogeneous series values! (See the postscript for an exhaustive/exhausting illustration. ;-) The same game can be played for tuple values, BTW. That said, even though I completely agree that there is no "natural" ordering for cartesian coordinates *as spatial coordinates* I believe that there *is* a natural ordering for ordered pairs of integers, namely the lexicographic order. The PAIR! type certainly has all of the symptoms of being an ordered pair of integers, and has FIRST and SECOND (or /1 and /2) defined. Allowing PAIR! values to be treated as ordered pairs (including the support for lexicographic ordering in support of such an interpretation) shouldn't break any code that simply uses them as e.g. pixel coordinates, but would extend their range of possible applicability. In short, things that otherwise behave as tuples (in the Mathematical sense of the word, not in the REBOL TUPLE! sense) should all be able to participate in meaningful tuple-like behavior, including the ability to be lexicographically ordered. I'm now climbing down off my soapbox... ;-) -jn- Here's a generated example showing how REBOL handles order inquiries over heterogeneous blocks. (This is output from a wad of nested loops that actually set up the values and printed the output; I assume it is too obvious to waste bandwidth on.) [1 "A" #"a"] < [1 "A" #"a"] = false [1 "A" #"a"] < [1 "A" #"b"] = true [1 "A" #"a"] < [1 "B" #"a"] = true [1 "A" #"a"] < [1 "B" #"b"] = true [1 "A" #"a"] < [2 "A" #"a"] = true [1 "A" #"a"] < [2 "A" #"b"] = true [1 "A" #"a"] < [2 "B" #"a"] = true [1 "A" #"a"] < [2 "B" #"b"] = true [1 "A" #"b"] < [1 "A" #"a"] = false [1 "A" #"b"] < [1 "A" #"b"] = false [1 "A" #"b"] < [1 "B" #"a"] = true [1 "A" #"b"] < [1 "B" #"b"] = true [1 "A" #"b"] < [2 "A" #"a"] = true [1 "A" #"b"] < [2 "A" #"b"] = true [1 "A" #"b"] < [2 "B" #"a"] = true [1 "A" #"b"] < [2 "B" #"b"] = true [1 "B" #"a"] < [1 "A" #"a"] = false [1 "B" #"a"] < [1 "A" #"b"] = false [1 "B" #"a"] < [1 "B" #"a"] = false [1 "B" #"a"] < [1 "B" #"b"] = true [1 "B" #"a"] < [2 "A" #"a"] = true [1 "B" #"a"] < [2 "A" #"b"] = true [1 "B" #"a"] < [2 "B" #"a"] = true [1 "B" #"a"] < [2 "B" #"b"] = true [1 "B" #"b"] < [1 "A" #"a"] = false [1 "B" #"b"] < [1 "A" #"b"] = false [1 "B" #"b"] < [1 "B" #"a"] = false [1 "B" #"b"] < [1 "B" #"b"] = false [1 "B" #"b"] < [2 "A" #"a"] = true [1 "B" #"b"] < [2 "A" #"b"] = true [1 "B" #"b"] < [2 "B" #"a"] = true [1 "B" #"b"] < [2 "B" #"b"] = true [2 "A" #"a"] < [1 "A" #"a"] = false [2 "A" #"a"] < [1 "A" #"b"] = false [2 "A" #"a"] < [1 "B" #"a"] = false [2 "A" #"a"] < [1 "B" #"b"] = false [2 "A" #"a"] < [2 "A" #"a"] = false [2 "A" #"a"] < [2 "A" #"b"] = true [2 "A" #"a"] < [2 "B" #"a"] = true [2 "A" #"a"] < [2 "B" #"b"] = true [2 "A" #"b"] < [1 "A" #"a"] = false [2 "A" #"b"] < [1 "A" #"b"] = false [2 "A" #"b"] < [1 "B" #"a"] = false [2 "A" #"b"] < [1 "B" #"b"] = false [2 "A" #"b"] < [2 "A" #"a"] = false [2 "A" #"b"] < [2 "A" #"b"] = false [2 "A" #"b"] < [2 "B" #"a"] = true [2 "A" #"b"] < [2 "B" #"b"] = true [2 "B" #"a"] < [1 "A" #"a"] = false [2 "B" #"a"] < [1 "A" #"b"] = false [2 "B" #"a"] < [1 "B" #"a"] = false [2 "B" #"a"] < [1 "B" #"b"] = false [2 "B" #"a"] < [2 "A" #"a"] = false [2 "B" #"a"] < [2 "A" #"b"] = false [2 "B" #"a"] < [2 "B" #"a"] = false [2 "B" #"a"] < [2 "B" #"b"] = true [2 "B" #"b"] < [1 "A" #"a"] = false [2 "B" #"b"] < [1 "A" #"b"] = false [2 "B" #"b"] < [1 "B" #"a"] = false [2 "B" #"b"] < [1 "B" #"b"] = false [2 "B" #"b"] < [2 "A" #"a"] = false [2 "B" #"b"] < [2 "A" #"b"] = false [2 "B" #"b"] < [2 "B" #"a"] = false [2 "B" #"b"] < [2 "B" #"b"] = false -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446