World: r3wp

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.

There's no way as fas a as I know of making new in-fix words.  There 
should be -- the currrent ones work both ways, so the mechanism must 
be there somewhere:
>> 6 < 5
== false
>> < 6 5
== false

Thanks for the strict-greater? idea.  I was hoping there was a built-in 
ability somewhere.

One tiny tweak to the function -- you need to restrict the two values 
to series or you can get strange results:
     >> strict-greater? make object! [1] make object! [0]
     == false
     >> greater? make object! [1] make object! [0]
     ** Script Error: Cannot use greater? on object! value
So:

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

Infix words are "hard-wired" from the Rebol programmer POV currently

postfix operators aren't reasonable to have, the prefix versus infix 
issues are complicated enough

The infix operators in REBOL can be seen with:
>> ? op!

It's a special corner of REBOL, as I see it. And I don't feel a big 
need to be able to make my own infix operators. There is a funny 
thing with the and, or and xor operators. They have twin and~, or~ 
and xor~ actions. The actions is used like: <action> <value1> <value2>, 
but operators can be used the same way, so the action counterparts 
seem to be irrelevant. Examples:
>> 3 and 9
>> and 3 9
>> and~ 3 9

Why do we have and~, or~ and xor~ made?

I suspect that originally, the infix operators weren't also able 
to be used prefix.

One can overload 'and~ 'xor~ 'or~ but should not overload 'and 'xor 
'or.

With form~ we know they are only used in <action> <value1> <value2>, 
and are safe to change.

I think, that it is an *unsafe* and confusing practice to use infix 
operators as prefix

I have one little thing to ask for my personal knowledge and I hope 
for people to thinks together on a good way to exploit it in REBOL 
to enhance it's capability to interface with DLL or exploit files 
containing memory struct dump:

the thing is how to load or convert a C structure like this and use 
it in REBOL in a approachant way of C (I hope we could find even 
a better way to do it with rebol than in C)