World: r3wp

(that's an unstable sort)

sort/compare/all/skip  -- will crash earlier versions of REBOL...One 
reason not to use blocks.
It should work with recent versions.  Is that your problem, Petr?

how do you remember that so quickly Sunanda ? (what's your indexing 
method?)

no, no Crashes, even with older version, but tested only with 3 records 
...

show us the simplest crashing example code

my "problem" was, I wante some kind of "tolerant" mode of sort, that 
it would not scream if some record would not contain field to test, 
so it would e.g. add those records to the end :-)

so not a crash, just a rebol error, then ?

yes, of course ...

it was me choosing incorrect word, sorry ...

I would say you have to write your own sort. I have done this... 
let's see.

I just wanted to load small text files (representing records) into 
block, then sort them. But as life goes on, your system evolves and 
I can imagine, that your e.g. Contact database will be extended by 
e.g. cell-phone2 record. But your previous records are already synced 
across tens of users. I wanted to sort and wondered, what to do about 
old records ...

I know it would be probably safer to rebuild all records, I just 
wondered if I could live without doing so ....

yeah, just pre-scan... if the cost is not too high. Is the record 
access slow ?

no, I think not .... I am waiting for RIF anyway ...

Anton -- I had to debug the problems with Sort/all/skip/compare  
-- code that worked on one platform, but failed on another. It got 
burned into the brain.

In Silesion group, late today I will post about what I have in plan 
and will "complain" a bit about IOS ... it is so primitive db vise, 
that it is not much usable ...

Petr, for fault tolerance, something like:

   sort/compare ...... func [a b] [ attempt [return a/x < b/x] return 
   false]

excelent - it does not return error, block is sorted, now I have 
to find out, what it did with record, which is missing field agains 
which I did compare ....

why is there "return false"?

hmm, that return false seems to change search results ...

Can you follow following test case, please?:

>>  blk: [[name "pekr" test [cz "bbb"]] [name "adriana" test [cz 
"aaa"]] [name "beatrice" test [cz ""]]]

== [[name "pekr" test [cz "bbb"]] [name "adriana" test [cz "aaa"]] 
[name "beatrice" test [cz ""]]]

>>  sort/compare blk func [a b][attempt [a/test/cz < b/test/cz] return 
false]

== [[name "adriana" test [cz "aaa"]] [name "beatrice" test [cz ""]] 
[name "pekr" test [cz "bbb"]]]
>> sort/compare blk func [a b][attempt [a/test/cz < b/test/cz]]

== [[name "beatrice" test [cz ""]] [name "adriana" test [cz "aaa"]] 
[name "pekr" test [cz "bbb"]]]
>>

Let's say I will pre-scan records and fill-in empty string in the 
case of missing field ....

you can see results of two sort calls, first one using return false, 
second one did not. The second one is sorted properly ... so I think 
that once attempt is called, it does something to sort ...

Why return false?

It was a very quick attempt to ensure that the sort always returns 
true or false.
But which (as you say) depends on whether a/x or b/x is missing.
Maybe better is
func [a b] [
    attempt [return a/x < b/x]   ;; both exist
    attempt [a/x return true]    ;; only a/x exists
    attempt [b/x return false]    ;; only b/x exists
    return false]                          ;; neither exist


It''d be a lot faster (I guess) if you refactor to remove the attempt 
blocks -- use value?

I just wonder what does it do to sort itself, once it finds record 
is missing the field? will it let the record untouched on the same 
position? Can't it affect following sort operations?

I think the sort/compare only does what you tell it to do in terms 
of the comparisons.

Pekr: As Sunanda mentioned return -1,0,1 for a stable sort. if you 
want to leave a record untouched when a key field is missing then 
return zero otherwise return 1, or -1

func [a b] [attempt [return a/x < b/x]   ;; both exist

 return 0 ;; nothing can be said because at least one does not exist 
 so they are equilivant
]

and -1 means what?

I would like it to behave as follows - in DB world, there are mostly 
string fields, and if you have "" (empty string = value is not set), 
you want to have it listed in the beginning of the grid-style ...

so, none, or nonexistant field should sort as if it is of lowes value 
....

a > b -> 1
a = b -> 0
a < b -> -1

so return false was not enough :-)

may I switch on logical values? switch true [true "print true"]  
... does not work ...

with only two states for logic 'either makes more sense

your above function will not work imo ...

there can be several states - non existant 'a, non existant 'b, both 
not existant, a < b, a = b, a > b :-)

in your case you seem to want null have a value that sorts before 
any known value which is fine for you. but in  general,  the three 
cases where a b or both are null are equalivanrt in that no comparison 
can be made and so are "vacuously true" because they cannot be proved 
false.

Pekr: switch true reduce [true "print true"] does work. 'true in 
your block is the word 'true, not the value true.

...or switch true [#[true] [print "true"]]

what version of Core will that work from? Will it work in IOS?

From at least View 1.2.5.3.1 it works. (not sure about Core)

#[true] works from /Core 2.5.1 (but not in 2.5.0)

It's easy to do case sensitive or case insensitive tests for equality:
     >> "abc" = "ABC"
     == true
     >> "abc" == "ABC"
     == false
(Or use equal? and strict-equal?)


Anyone know a  similar shorthand way to do the same for greater/less 
than comparisons?
     >> "abc" < "ABC"
     == false
     >> "abc" > "ABC"
     == false
Right now, I'm using to-binary to get the right result:
     >> (to-binary "abc") < (to-binary "ABC")
     == false
     >> (to-binary "abc") > (to-binary "ABC")
     == true

No, there doesn't seem to be a strict-greater? action, but you can 
make such a function to get more readable code:

strict-greater?: func [value1 value2] [(to-binary value1) > (to-binary 
value2)]


Which makes me remember, that it's not possible to make new in-fix 
actions in REBOL!?

Functions are pre-fix (name of function followed by arguments), actions 
are in-fix (argument1 action! argument2), and there are no post-fix 
words in REBOL. I'm not too familar with the language theory, REBOL 
is based on, but should it be possible to make new in-fix words? 
And what about post-fix? Or is that just too confusing?

(Well, arguments could be said to be post-fix words... hmm)

you can build your own parsing, and your own dialects as well...depending 
on your application

True. I also actually meant op! types (operators), not action! And 
the operators in REBOL are pretty basic, so no need for new ones, 
I guess.