World: r3wp

Looks like SORT uses this datatype map internally:


[unset! datatype! native! action! function! object! word! set-word! 
get-word! lit-word! refinement! none! logic! integer! decimal! money! 
time! date! char! pair! event! tuple! bitset! string! issue! binary! 
file! email! url! tag! image! block! paren! path! get-path! set-path! 
lit-path! hash! list!]

how do u know?

I made a block of all datatypes and sorted it. That was the outcome.

Nevertheless, it seems the method is going to be complicated and 
slow for /COMPARE as I don't know how it handles periferal cases 
like:

sort reduce [true false]
== [false true]

which cannot be compared outside SORT using:

lesser? true false
** Script Error: Cannot use lesser? on logic! value


and I don't know and should not need to know how many periferal cases 
there are.

the solution to me would be that comparison functions use the same 
logic as SORT.

Since you can sort a block of logic! values, then <, > etc. should 
work on them, so that's missing. Doing to-integer on logics first 
solve it. And you have to check all the other datatypes by hand first 
to find out, where possible problems are, I guess.

Sorting pairs. hmm...

>> sort [1x2 2x1]
== [2x1 1x2]

Doesn't make sense.

It shouldn't be possible to order pairs, like complex numbers. (Unless 
you define your own rules.) :)

But as pairs are used to make GUIs, it maybe makes sense to sort 
them in this case. Top of screen is before bottom.

SORT seems to sort anything that you throw at it and I think that 
makes sense, when making GUI lists. Right now I have a problem in 
that I can't control the input datatype and must sort anyway. The 
structure of the data is currently so that SORT/COMPARE is best to 
use, but LESSER? and GREATER? prevent this from being simple.

Today's Moment of REBOL Zen:

>> forever [prin now/time // 7 wait 1 loop 20 [prin bs]] 
0:00:00.000000002

Very cool John.

:)) i didn't know about bs until now...

forever [prin now/time // 7 wait 1 prin cr]

(remainder on time is funny)

Yeah, looks like a bug.

onetom:

>> ? char!
Found these words: 
   backslash       char!     #"\" 
   backspace       char!     #"^H" 
   bs              char!     #"^H" 
   cr              char!     #"^M" 
   escape          char!     #"^[" 
   lf              char!     #"^/" 
   newline         char!     #"^/" 
   newpage         char!     #"^L" 
   null            char!     #"^@" 
   slash           char!     #"/" 
   tab             char!     #"^-"

And then there is one string related to those, crlf.

The one that gets me is remembering that newline is a character and 
new-line is a function, rather than vice-versa.

me too.  I always mix them up... isn't this something that could 
be changed in R3?

Wait for R3

Exchanging newline and new-line, and I bet a lot of people will mix 
those up. :) Why do you feel, they should be the other way around?

newline could be called EOL?
http://en.wikipedia.org/wiki/Newline

I don't feel that they should be the other way around. The problem 
is that there is no obvious reason why it should be one way or another, 
so when trying to remember it I get it wrong about half the time. 
Using 'eol would be good, but wouldn't help the problem because we 
can't undefine 'newline in R2 because of the backwards-compatibility 
rules.

new-line could be called set-newline? :)

You can't get rid of the old name in R2, you can just add new names. 
You have to get rid of the old name to solve the problem.

Get rid of the bad old name and change the few scripts, that might 
use new-line. Problem solved!

If people don't want to change old scripts, then just make some script 
to be included (maybe by default using some option when calling REBOL), 
which define things like:

	new-line: :set-newline

The backwards compatibility rules of R2 prohibit getting rid of the 
old name (backwards compatibility is the reason for R2's continuing 
existence). That definition would need to be included by default.

If people don't want to change old scripts they use R2 instead of 
R3.

Maybe things like set-newline is for R3 then.

As for SORT, that's an interesting problem. LESSER? and GREATER? 
are supposed to be constrained to datatypes that are comparable, 
and that have some form of magnitude or ordering. For datatypes that 
don't really have magnitude or ordering they don't really work. When 
it comes down to it, true is not greater than false inherently (considering 
it to be so is more of a moral stand). And none is not greater or 
less than 'a, they just aren't comparable concepts.


SORT doesn't have that luxury though, because it is designed to not 
fail (or rather, not trigger errors because a comparison fails). 
So it has to define some extra comparisons that don't really make 
any sense, as a fallback in the cases where there is no comparison 
that does make sense. The datatype ordering trick is one of those, 
where they are ordered by their inner datatype number, and different 
data that isn't otherwise comparable is ordered by its datatype number 
too (words are greater than unset but less than none, for instance). 
R3 has a list of those datatypes in order in system/catalog/datatypes, 
but if there's a similar list in R2 I don't know where it is - Henrik's 
above is a subset, just the datatypes with externally referenced 
values. R2's and R3's datatypes are in a different order.


SORT/compare is supposed to allow you to provide your own ordering 
function if the standard ordering doesn't make sense. However, if 
you want to support all of the comparisons that the built-in ordering 
supports, you have to make a really complex comparator function with 
a lot of special cases, and in the case of R2 replicate a lot of 
internal data; that function would be pretty slow too. This is why 
SORT/compare is more often used for more restricted cases, like reversing 
the order, or comparing based on object keys.

Good points about SORT, Brian.


One small observation. SORT has a /reverse refinement, so /compare 
is not needed for simply reversing the order of a sort.

Agreed.

Geomol: crying from the gust (-; ? char! is beautiful

I would still like to see a dialected new-lines or line-markers func. 
I don't get the char and func names confused today.

Gregg, what do you mean by a dialected new-lines func?

Regarding the NEWLINE and NEW-LINE names. Consulting the function 
naming convention described in the documentation, it looks, that 
the NEW-LINE name is not adequate. (violates the function naming 
convention) That deficiency cannot be corrected by renaming NEWLINE. 
The SET-NEW-LINE name would be a preferable solution.

How many are using new-line anyway? Maybe I should do a search in 
the library at rebol.org.

LESSER? and GREATER? are supposed to be constrained to datatypes 
that are comparable

 - in fact, this is a kind of a circular reasoning (cf. "Comparable 
 values are values that are comparable")

In fact, the example of SORT proves, that comparability of all values 
is useful and desirable (we can sort). This situation is quite typical 
in mathematics. For example, is zero a number? The answer is quite 
trivial: yes, because it is useful. Not "philosophical reasoning" 
collecting reasons why not (we cannot divide by zero, zero does not 
express the number of elements of any nonempty set, etc.) matters.

Geomol: i was just using new-line recently for example to create 
a simple "json database". i was saving json-to-rebol object hierarchies 
into plain text files, but before that i converted each object into 
pure blocks, so it has less brackets... no #[object! ...] shit. but 
it destroyed the new-lines, so i had to but them back manually, so 
the text file is still human processable.

i think this new-line thing is a gem in rebol. one of those usability 
enhancements which are nicely hiding under the surface, not getting 
in the way, but does automagic if u want. out of the box... things 
like this makes rebol sexy. just like apple products... those lots 
of little things...

Ladislav, would you prefer, if lesser? and greater? worked on all 
combination of datatypes then? And then just let the sort rules deside 
the outcome.

would you prefer...

 - in this case, my preferences don't matter, as it looks, although 
 I think that I suggested what they are. Cf. also above " you have 
 to make a really complex comparator function" - I do not think this 
 is desirable.

I should have rather said, that I did not find that useful.

Is red greater than banana? Some comparisons are meaningless. The 
extra comparisons that SORT does are only useful as placeholders.

Exactly as I said: "meaningless" is not an argument

What is meaningful is the ability to sort

The errors triggered by LESSER? and such when presented with meaningless 
comparisons are useful, especially for debugging. I recognize that 
SORT benefits from these placeholders, but LESSER? and such benefit 
from their absence.

meaningless

 is meaningless, it is exactly the same argument as saying, "zero 
 as a number is meaningless". Whole nations Greeks, etc. maintained 
 that opinion, but their argument was proven meaningless.