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

native? :==

 [1/11] from: hallvard::ystad::helpinhand::com at: 4-Feb-2002 12:21


Why is this:
>> native? :==
== false ~H

 [2/11] from: koopmans:itr:ing:nl at: 4-Feb-2002 12:54


native? :find == false OTOH native? :now ==true

 [3/11] from: joel:neely:fedex at: 4-Feb-2002 0:44


Hi, Hallvard, Hallvard Ystad wrote:
> Why is this: > > >> native? :> == false >
Perhaps for the same reason as this existentialist error message:
>> pair? 1x1
== true
>> pair? 2x2
== true
>> 1x1 < 2x2
** Script Error: Expected one of: pair! - not: pair! ** Near: 1x1 < 2x2 If the puzzlement isn't clear, compare with the following
>> 1x1 < #"?"
** Script Error: Expected one of: pair! - not: char! ** Near: 1x1 < #"?"
>> 1x1 < #?
** Script Error: Expected one of: pair! - not: issue! ** Near: 1x1 < #? -jn- -- The first rule of intelligent tinkering is to save all the pieces. -- Aldo Leopold joel{FIX{PUNCTUATION{dot{neely{at{fedex{dot{com

 [4/11] from: holger:rebol at: 4-Feb-2002 7:11


On Mon, Feb 04, 2002 at 12:54:08PM +0100, Maarten wrote:
> native? :find > == false
find is an action!, not a native!. action!, op! and native! are three different variations of the same thing. -- Holger Kruse [holger--rebol--com]

 [5/11] from: holger:rebol at: 4-Feb-2002 7:10


On Mon, Feb 04, 2002 at 12:21:30PM +0100, Hallvard Ystad wrote:
> Why is this: > > >> native? :> == false
Because == is of type op!, not native!. -- Holger Kruse [holger--rebol--com]

 [6/11] from: holger:rebol at: 4-Feb-2002 7:15


On Mon, Feb 04, 2002 at 12:44:51AM -0600, Joel Neely wrote:
> Hi, Hallvard, > Hallvard Ystad wrote:
<<quoted lines omitted: 4>>
> > > Perhaps for the same reason as this existentialist error message:
No :).
> >> pair? 1x1 > == true
<<quoted lines omitted: 3>>
> ** 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 ?). If they were allowed by the language (as in early versions of View) that could lead to difficult to track down bugs in scripts. -- Holger Kruse [holger--rebol--com]

 [7/11] from: hallvard:ystad:helpinhand at: 4-Feb-2002 16:26


OK, sorry to bother the list about it. As I think about it, this has been discussed before. Guess I was just confused that
>> native? :==
== false but:
>> source ==
==: native [ {Returns TRUE if the values are equal and of the same datatype.} value1 value2 ] '== is op!:
>> op? :==
== true so that explains it. ~H Dixit [holger--rebol--com] (16.11 04.02.2002):

 [8/11] 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: > >
<<quoted lines omitted: 7>>
> > Perhaps for the same reason as this existentialist error > > message:
Not serious, of course! ;-)
> No :). > > >> pair? 1x1
<<quoted lines omitted: 9>>
> 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-

 [9/11] from: holger:rebol at: 4-Feb-2002 14:03


On Mon, Feb 04, 2002 at 11:12:41AM -0600, Joel Neely wrote:
> I must respectfully disagree (for a couple of reasons). One could > argue that tuple and series data are also "multi-dimensional" in
<<quoted lines omitted: 3>>
> compares multi-part entities part by part, using the natural > ordering of the parts.
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 ? Actually, early versions of View behaved that way. However it is our experience that in almost every case where one is tempted to use < to compare coordinates, the result ends up being wrong. We actually spotted a few bugs in our own code when we removed support for <.
> 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.
Yes, exactly. So far we have not found one for pairs (assuming pairs are actually used to represent coordinates, not something else). The definition that is probably most likely to be useful is to compare the distance to 0x0. The problem with that is that points which are not the same would compare to be equal (e.g. 3x4 and 4x3), which is extremely counter-intuitive and another potential source for bugs.
> 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.
So you are arguing to give x precedence over y ? In layout-oriented calculations y tends to be dominant though... IMHO the "first/second" argument you make is problematic, because pairs do not extend to more than two dimensions. Also, for string and block series the elements actually represent a sequence. For pairs the order of x and y is purely arbitrary, by convention, so lexicographical ordering seems equally arbitrary as a rule.
> 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.
If one existed then one would be available :-). -- Holger Kruse [holger--rebol--com]

 [10/11] from: joel:neely:fedex at: 4-Feb-2002 17:22


Hi, again, Holger, [holger--rebol--com] wrote:
> > Lexicographic ordering (sometimes called "dictionary ordering") > > compares multi-part entities part by part, using the natural > > ordering of the parts. > > Yes, but for string and block series there is a natural order > (left-to-right). For pairs there is not. >
It seems clear to me, both from the way literal pairs are written, and from the equivalence of /X to FIRST and /Y to SECOND that there *is* an order to the components of a pair.
> Do you want x or y to take precedence ? >
X (since REBOL equates that to FIRST).
> Actually, early versions of View behaved that way. However it is > our experience that in almost every case where one is tempted to > use < to compare coordinates, the result ends up being wrong. >
All I can say is that my experience differs.
> > 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. > > Yes, exactly. So far we have not found one for pairs (assuming > pairs are actually used to represent coordinates, not something > else). >
I guess my background prepares me to think that having two of something is just a special case of having N of something. While it is handy to have a data type that *can* be used to represent coordinates in a two-dimensional vector space, that's not the same as saying that the data type can *only* be used to represent such coordinates.
> The definition that is probably most likely to be useful is to > compare the distance to 0x0. The problem with that is that > points which are not the same would compare to be equal (e.g. > 3x4 and 4x3), which is extremely counter-intuitive and another > potential source for bugs. >
I'm having a hard time accepting the notion that something that is "probably most likely to be useful" is simultaneously "extremely counter-intuitive" and bug-breeding. If pairs are to be restricted to a geometric interpretation, it would obviously be silly to define an ordering which made distinct points appear to be equal. Clearly there are many geometric orderings, including (for complex numbers) using the norm (length) as the major comparison and using angle (from the real axis) as the tie-breaker. Under that ordering, 4x3 would precede 3x4. However, since I don't use REBOL for complex-valued calculations, I wouldn't think that would be very useful. The advantages of lexicographic order are that it is easy to understand, doesn't bias the data type to any specific use, and is consistent with other orderings. It also seems odd to me that < excludes pair data on the basis that there's no meaningful way to compare, when REBOL clearly *does* have the notion of ordering of pairs, as shown below:
>> foo: [1x1 1x2 2x1 2x2] while [not empty? foo] [
[ print first minimum-of foo [ remove minimum-of foo [ ] 1x1 2x1 1x2 2x2 == [] There obviously *is* an order as far as MINIMUM-OF and MAXIMUM-OF are concerned (even if it is right-to-left precedence). Accordingly, I think it makes sense that either: * < (and all other order tests) should be implemented consistently with MAXIMUM-OF and MININUM-OF, or * MAXIMUM-OF and MINIMUM-OF should refuse to operate on pairs as do the simple order tests (< and company). As was pointed out by someone else recently, exceptions and in- consistencies form a barrier to entry for newcomers to a language. I'd like newcomers to be able to learn REBOL (and oldcomers to be able to use it... ;-) as easily as possible! -jn-

 [11/11] from: holger:rebol at: 4-Feb-2002 18:31


On Mon, Feb 04, 2002 at 05:22:05PM -0600, Joel Neely wrote:
> I guess my background prepares me to think that having two of > something is just a special case of having N of something. While > it is handy to have a data type that *can* be used to represent > coordinates in a two-dimensional vector space, that's not the same > as saying that the data type can *only* be used to represent such > coordinates.
Pairs are rather specialized. They were added for /View, and should only be used in that context.
> It also seems odd to me that < excludes pair data on the basis that > there's no meaningful way to compare, when REBOL clearly *does* have > the notion of ordering of pairs, as shown below:
Internally REBOL needs to be able to compare any type to any other type, even, functions, natives etc., e.g. in order for 'sort to terminate. That does not mean that those comparisons are necessarily useful or part of the language.
> * < (and all other order tests) should be implemented consistently > with MAXIMUM-OF and MININUM-OF, or > * MAXIMUM-OF and MINIMUM-OF should refuse to operate on pairs as > do the simple order tests (< and company).
No. User-level comparisons have to be logical, easy to remember and useful. Internally any value has to be comparable to any other value though, which is what you see when you call a function that performs internal comparisons.
> As was pointed out by someone else recently, exceptions and in- > consistencies form a barrier to entry for newcomers to a language. > I'd like newcomers to be able to learn REBOL (and oldcomers to be > able to use it... ;-) as easily as possible!
Agreed. -- Holger Kruse [holger--rebol--com]

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted