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

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