World: r3wp

well, we don't have the source code to 'sort to know whether the 
sort creates a new copy or whether it sorts in situ ... so no idea 
whether there is a penalty or not

BTW, the term set function is confusing .. perhaps use the term sets 
function

Hence the quotes.

This isn't a serious question.  Devil's advocacy, or what you might 
call it.  But given Rebol's insistence that "/only" is a somewhat 
opaque modifier speaking about whether the routine in question does 
its "extra" thing or not... wouldn't "unique/only" be a way of saying 
"sort the array in place only, don't do the make copy step"?

series: unique series

Carl says it has to make a new series anyway

I prefer the symmetry 

series: sort series

instead of one doing one , and not the other

If one could turn back time, I wonder if {!} for types would be better 
served by some other symbol like {^} , and Rebol could have UNIQUE! 
(modifying) vs. UNIQUE (make a copy) in the style of Ruby and company. 
 "Verbs modify" isn't consistent, since REDUCE or COMPOSE don't modify 
while SORT and REVERSE do.

(In my currently-still-very-limited Ruby tinkering, I have liked 
this convention--and in fact, sort of wished there were some way 
of it being more than just a convention, but reflected in a contract 
which generated both the modifying and non-modifying variant of an 
operation.)

The learnability of consistency vs. the beauty of making the common 
cases and idioms look elegant.   But are those looks deceiving?  
English sure is a mess... but people find it effective.

Why not follow your INTO convention?  Couldn't you make UNIQUE/INTO?

consistency leads to a lower cognitive load for the programmer

the argument that sort modifies because you can always copy first 
is met by the retort that you can always assign afterwards

I think that Rebol already has the "i before e but not after q and 
sometimes z" philosophy, in that there are forces driving it that 
are something of the nature of what drives natural language design. 
 Purely consistent  languages which have no special adaptations to 
the "messy" world don't really need to be designed, they exist mathematically 
already.  They are more discovered than made.

Hence the catch-phrase "Inspired by theory, driven by practice." 
 Of course, then the question comes up of "whose practice?" when 
releases are being timed to Amiga announcements etc.

So, tell me .. sort in place is more expensive than not, so another 
series is already created somewhere ...

so, modifying the original series is likely to be a convention and 
not an optimization

Whether sort in place is more expensive or not depends on the fundamental 
operations upon which sort is built.  (This makes interview questions 
fun when people "know" the answers, because you say "oh.  well let's 
say you're on an architecture where a memory allocation costs 1000 
times more than a swap"... :P)

Anyway, the issue is about the program expressing the intent of the 
programmer and letting the system do the smartest thing under the 
hood given the understanding of what the programmer wanted, for the 
common cases.

Some thought process in Rebol design didn't make "ARITHMETICATE" 
or some variant of REDUCE which is modifying on its value target. 
 Instead, it was decided that REDUCE/INTO would be more interesting. 
 I'm just wondering what optimization logic makes DEDUPLICATE more 
interesting than UNIQUE/INTO... ?

perhaps it's a feeling that refinements should be used for passing 
new arguments than modifying behaviour?

Does anyone else have trouble calling a file that has parentheses 
in it?

eg. ?

call %/d/something with (parentheses).mp3

and what happens for you?

returns zero

but doesn't call it

actually the parentheses should be %28 and %29

here's one %/d/music/Astor Piazzolla/Astor Piazzolla - Adios nonino %28live%29.mp3

to get around it I use this function    call2: func [file][call quotate 
quotate to-local-file file]

quotate: func [str][rejoin [{"} str {"}]]

I don't agree to copy on sort.

Perhaps you want 'run and not 'call ?

Except 'run was only implemented in IOS

** Script Error: Feature not available in this REBOL

I'll just use call2 then.

Does anyone know how to redefine words?

e.g.  call: func [file] [system/words/call quotate quotate to-local-file 
file]

this doesn't work obviously. but do you get my meaning?

This works, but I can't get it into a redefine function.

old: context [call: get in system/words 'call]
call: func [file] [old/call quotate quotate to-local-file file]

use [ n ][ n: :now set 'now func [][ n + 1]]

call: func [file] compose [(:call) quotate quotate to-local-file 
file]

wow

magic :)

I also would love more internal consistency between mutating and 
non-mutating versions (and I'd personally like to have non-mutating 
versions be the default for all functions). But realistically, this 
kind of simplification will never be really an option for future 
REBOL development, I fear.

I don't think the Ruby ! sigil is particularly meaningful, so I wouldn't 
vote for that.


While having complete consistency might make for a more pure and 
mathematically beautiful language, I don't think that is REBOL's 
goal. REBOL's design has elements that exist to make things simpler 
and more obvious. You could argue that complete consistency would 
do that, but if you look at history, that's not the case. 


the argument that sort modifies because you can always copy first 
is met by the retort that you can always assign afterwards

 - You can always assign, but if you have other references to that 
 series, they wouldn't see the change. This can also cause unintended 
 side effects of course, which is the risk of modifying, but that's 
 part of REBOL too. :-\


We'll never please everyone. I'm OK with the current SORT and set-operation 
behavior.

There is absolutly no gain to copy by default. As Gregg stated: "you 
can easily COPY if you want, but it's hard to go the other way".

I'd say more: Default copies induces overheads you can't discard 
most of the time.

See UNIQUE. This function is not widely used in my apps, just because 
of that. Useless, because when we deals with huge series, we don't 
want to pay the COPY cost.

UNIQUE/into, good idea. DEDUPLICATE would use UNIQUE/into internally, 
but I can't think of any other use case. I'm sure others could.

No, that probably wouldn't work because you need the intermediate 
series so you don't have data loss. So, no use case so far.