World: r3wp

by "crash" do you mean crashing the rebol interpreter ?

? dunno understand what you are talking about .... I tested it with 
few records and it worked ... I used example from rebol.com doc ...

do you have a simple example.

Logic! works fine if you have unique key values.  +1 0 -1 is for 
ensuring stable sorting when key values are not unique.

ah yes.. that's right. When you sort an already sorted list, some 
equal values would swap around sometimes.

(I should say keys, not values...)

(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)