[REBOL] Re: Pair comparison (was: native? :==)
From: joel:neely:fedex at: 5-Feb-2002 6:42
Thanks, Allen, for an example that helps me focus on the key
issue I've been thus far unable to make clear!
Allen Kamp wrote:
> From: "Hallvard Ystad" <[hallvard--ystad--helpinhand--com]>
>
> > Dixit [holger--rebol--com] (23.03 04.02.2002):
> > >Yes, but for string and block series there is a natural order
> > >(left-to-right). For pairs there is not. Do you want x or y to
> > >take precedence ?
> >
> > Precedence or not, when presenting X/Y coordinates, I have yet
> > to meet with someone who places the Y before the X (ever heard
> > about Y/X coordinates?).
> >
>
> Pairs also represent size. If you only compare X then this falls
> apart when dealing with size. Which is greater 5x1 or 3x2 ??
>
An ordered-pair data type could be used to represent many things.
Some of those things have an intuitive total ordering and others
do not. Some have multiple plausible total orderings, depending
on what's being done with them.
For example, to take Allen's illustration further, which is "larger",
a 6x1x1 package or a 3x2x1 package? Although they are both 6 cubic
units in volume, the 6x1x1 configuration is more "extreme" in terms
of being able to pack it neatly in a cargo container, aircraft, etc.,
and so may be considered "more" for some purposes.
However, we're talking about a data type in a programming language,
which is different than talking about all of the things I might be
able to represent with it (with all of their varying "intuitive"
baggage). Let's not confuse the capabilities of the data type
AS A PRIMITIVE DATA TYPE with all of the range of possible uses
that could be made of the type in applications.
For example, in the US, wire is commonly specified by "AWG gauge",
based on inches. 38-guage wire is .004 inch in diameter, 10-guage
wire is just over 1/10-inch (.1019), etc. (The relationship is
essentially a geometric series with ratio ~1.123, for the maths
geeks among us.) The British SWG system is similar, with slightly
different numbers.
What's my point? Simply that -- for wire gauge -- a larger number
means finer wire, so that a comparison function that interpreted
numbers as gauge and told which *wire* was larger would have the
result that
larger-as-AWG? 10 36
would be true. However, I would NEVER use this as an argument to
claim that numbers can't be compared. When comparing numbers
*as*numbers* it should be obvious that 10 > 36 is false.
REBOL already observes this data-type-versus-usage distinction in
other ways. Consider the string comparison:
>> "237 Washington Street" < "1150 Washington Street"
== false
Every human being knows that 237 Washington Street is closer to the
middle of town than 1150 Washington Street, and therefore this
answer is clearly wrong! But is it? No! The built-in LESSER?
test on strings is doing its work based only on the (well-defined)
properties of strings as ordered collections of characters. The
STRING! value "237 Washington Street" follows the STRING! value
1150 Washington Street
based on those properties, regardless of
where the strings came from or what meaning I may attach to them
in my application.
If I want to have a function that imposes an "intuitive" ordering
on the application-level concept of "street address", then I'm free
to define and implement one in my own code (and bear the total
responsibility for its correspondence to my users' expectations!)
If I choose to represent street addresses as strings, I'll have
an interesting time writing that function! ;-)
I've clearly thwacked this moribund equine quadruped sufficiently.
My much-belabored point is simply that data types per se (as
component concepts of a programming language) are different from
all of the possible things they might represent. The data types
themselves should have simple, uniform treatment by the language.
Whenever there are sufficiently common interpretations of those
data types, it is nice to have features that support those
meanings. (And, of course, any modern programming language should
allow the programmer an easy means of representing application-
level concepts in terms of the built-in data types.)
However, the absence of such intuitive guidance should not deprive
the data type (again, per se) from having a consistent set of
capabilities such as are common to other data types, else they
give up their first-class citizenship in the community!
-jn-
--
; sub REBOL {}; sub head ($) {@_[0]}
REBOL []
# despam: func [e] [replace replace/all e ":" "." "#" "@"]
; sub despam {my ($e) = @_; $e =~ tr/:#/.@/; return "\n$e"}
print head reverse despam "moc:xedef#yleen:leoj" ;
