World: r3wp

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.

The errors triggered are useful *for those functions*, as they help 
the developer track down places where their code doesn't make sense, 
usually because they are missing a guard or conversion somewhere. 
For SORT they aren't as useful, hence the placeholders and fallbacks.

Everything can be easily transformed to the zero case. The argument 
of "zero is meaningless" promoters was, that it helps the computers 
(people, at those times) to "track down the places where their calculations 
do not make sense"

Sorry, but I don't agree with the zero case, and I do agree with 
5 not being greater or less than yellow. So that argument falls down.

I just wanted to demonstrate the isomorphism of the two cases, so 
that everybody could see it.

NEW-LINE is magically delicious to me. I do quite a bit of code and 
data generation, so I use it a lot.

By dialected, I mean the arg to the func is a dialect. When discussed 
before, one question was whether to make the block a separate arg.

a: [a b c d e]
b: [1 2 3 4 5]
new-lines [
    all on in a
    on in b every other item
]


Ladislav is right on naming, that it violates the verb-first convention.

I called my dialected version NEW-LINES, to match the standard func, 
then tried LINE-MARKERS. I don't have a problem with adding SET- 
to the head though.

Ok, thanks Gregg. Cool with such dialect to make newlines in blocks.

Tonight's Moment of REBOL Zen:

>> s: [1 2 3]
== [1 2 3]
>> t: tail s
== []
>> remove/part s 2
== [3]
>> back t
== ** Script Error: Out of range or past end
>> index? back t
== 2
>> index? back back t
== 2
>> index? back back back t
== 1

Zen in this case just being R2's bad behavior with out-of-bounds 
references. You forgot this:
>> index? t
== 4
This is the only part of the behavior of INDEX? that makes sense.

>> s: [1 2 3]
== [1 2 3]
>> t: tail s
== []
>> index? t
== 4
>> remove/part s 2
== [3]
>> index? t
== 2

Never mind, INDEX? just sucks in R2 with out-of-bounds refs. That 
is part of what we tried to fix in R3.

Regarding the "comparison is meaningless", or "SORT doesn't have 
that luxury though, because it is designed to not fail" philosophical 
arguments. They, in fact, are not valid at all. The facts are different.


* For large lists which are frequently searched it *is* useful to 
have them sorted. 

** The reason is, that it is much easier to perform searches in a 
sorted list, than in an unsorted list.

** The "meaning" of the sort order is to facilitate searches, no 
other meaning is needed. (it is like the zero case, the meaning of 
zero is to facilitate the positional representations of numbers, 
no other "meaning" is needed)

* The whole "sorted list business" needs comparison functions (for 
searching, etc.)


The above "meaning" is one meaning comparisons do have. It suffices 
to prove, that comparisons are not "meaningless". (for that it would 
be absolutely necessary, that we can find no meaning at all)

It shouldn't be possible to order pairs, like complex numbers.

 - the set theory uses the axiom, that can be formulated so, that 
 it should be possible to sort any set so, that it becomes well ordered. 
 Of course, it is useful to have even partial order, like the one 
 you mentioned, but nobody said it was the only ordering possible.

The only thing not possible is to sort the complex numbers so, that 
the ordering is in some useful way "compatible" with arithmetic operators.

The problem of SORT, which I am not sure we are able to address, 
is the Unicode-aware sort ...

Individual nations have individual collating sequences - norms prescribing 
how strings shall be ordered. Thus, "Unicode-aware sort" is something 
like a unicorn.

It definitely makes sense to me to expose SORT's basic grouping or 
sorting mechanism, so you can build your own sorter around its logic. 
I'm not sure I care about what datatypes come first or which order 
the "meaningless values" come in, just as long as it's consistent 
with SORT.

You can just use SORT to access SORT's sorting mechanism, no?

(Obvious performance implications left aside.)

Ladislav, you are arguing that those comparisons have *use*, not 
*meaning*. They definitely have *use* in SORT, mostly as placeholders 
and fallbacks, so that SORT can be used as you describe above on 
heterogeneous data. But that doesn't mean that those comparisons 
have meaning.

SORT needs there to be an ordering between pieces of data in order 
to sort them. Whether or not that ordering has meaning, SORT needs 
it to exist because it need to use it. So in the cases where there 
is no ordering that has meaning, SORT uses ordering methods that 
don't have meaning. They are useful, but not meaningful.

SORT itself is useful for the reasons you give above.

They definitely have *use* in SORT

- as far as I am concerned, I find it "meaningful" to implement a 
feature of the language that is "useful" (but that may be just me)

But there are much more important issues:


* the users shall be able to use their own sorting functions applying 
useful comparison operators (SORT has known issues)

* the users shall be able to utilize the advantages of having the 
data sorted, which, again, is possible if the compatible comparison 
functions are available