[REBOL] Re: native? :==
From: joel:neely:fedex at: 4-Feb-2002 11:12
Hi, Holger,
[holger--rebol--com] wrote:
> On Mon, Feb 04, 2002 at 12:44:51AM -0600, Joel Neely wrote:
> >
> > Hallvard Ystad wrote:
> > >
> > > Why is this:
> > >
> > > >> native? :> > > == false
> > >
> >
> > Perhaps for the same reason as this existentialist error
> > message:
>
Not serious, of course! ;-)
> No :).
>
> > >> pair? 1x1
> > == true
> > >> pair? 2x2
> > == true
> > >> 1x1 < 2x2
> > ** Script Error: Expected one of: pair! - not: pair!
> > ** Near: 1x1 < 2x2
>
> Yes, the error message is less than informative :).
>
>
> The reason for it is sound though. Multi-dimensional entities
> such as pairs do not have a useful total ordering, i.e. less
> than/greater than comparisons are not always possible
> (e.g. what is 1x2 < 2x1 supposed to return ?).
>
I must respectfully disagree (for a couple of reasons). One could
argue that tuple and series data are also "multi-dimensional" in
many ways, yet there IS a total ordering that is common to all of
them (and widely regarded as useful for many purposes).
Lexicographic ordering (sometimes called "dictionary ordering")
compares multi-part entities part by part, using the natural
ordering of the parts. In pseudo-REBOL (limited by the small
number of ordinal actions...) one could define
less-than?: func [
a [multi-part-thing!] b [multi-part-thing!]
][
if first a < first b [return true]
if first a > first b [return false]
; firsts were equal; try seconds
if second a < second b [return true]
if second a > second b [return false]
; firsts and seconds were equal; try thirds
... etc.
]
(Obviously this is oversimplified; it ignores length testing. But
that isn't the main point.)
This concept is exactly how string, block, and tuple comparisons
work:
>> "12" < "21" == true
>> [1 2] < [2 1] == true
>> .1.2 < .2.1 == true
>> 1.2. < 2.1. == true
In addition, REBOL often seems to take the position that, when there
are multiple things that *could* be done, it picks one that has some
likelihood of being useful. For example, the difference in the
result values of APPEND and INSERT allow one to "chain" consecutive
applications of the same operations in a nice way. The meanings of
append append append fee fie foe fum
and
insert insert insert fee fie foe fum
are such that the contents of FIE, FOE, and FUM appear in the result
in the same order as the words in the source code. (And, again, if
I want a different result than that, I'm free to define my own
functions to produce the alternative I wish to produce.)
Since "first" and "second" are just as defined for pair data as for
tuple and string, it seem that (in the absence of a compelling
alternative meaning for comparing pairs) maintaining consistency
with comparison of other data types would be A Good Thing.
> If they were allowed by the language (as in early versions of
> View) that could lead to difficult to track down bugs in scripts.
>
I honestly don't get this one. If I am using blocks to represent
data in my program, and if that representation is such that the
built-in meaning of < for blocks isn't helpful to me, then I can
define my own comparison (if I need one). If I fail to understand
how < works on blocks, and misuse it, then it's my fault for not
using the language properly (and the source of my error shouldn't
be hard to track down).
IMHO this should apply equally well to comparison of pair data.
Of course I'm assuming that the meaning of < would be documented.
In my own experience the absence of documentation is MUCH more of
a problem than the fact that a few features may not be universally
applicable. If a complete explanation of how language features are
defined were available, then the burden would be on the programmer
to use them properly.
-jn-
