World: r3wp

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.

The /into option wasn't added to many applicable natives, just the 
two that generate the most data in REBOL: REDUCE and COMPOSE. That 
might be a "biggest bang for the buck" thing, or maybe we just haven't 
gotten around to it yet. Or it might be a big hassle to add /into 
to a native, so to get it done you need to justify it with use cases.

Time will tell. Like it or not, REBOL is primarily built around mutating 
functions, except for functions that work on immutable values like 
integers. Most of the non-mutating functions we have are either built 
on their mutating counterparts in mezzanine, or are options of those 
functions. In a language with mutable values, mutating functions 
are the base. Functional-language fans tend to not like this (and 
when we start really implementing task-safe code they can say "I 
told you so!"). However, mutability can have advantages too, mostly 
in memory usage and performance, so it's a tradeoff.

(((( I know you don't agree with me, but I want a VM level way to 
define pure functions (that are guaranteed they can't change anything 
outside itself). 

Big future deal in rebol to me is in runtime code generation to express 
things and *code mobility* and there can't be any real mobility if 
the code I get can "get over the wire" can do anything to my system 
))))

>> reducificate: func [value] [either series? :value [head remove/part 
reduce/into value value tail value] [reduce :value]]

Works for DEDUPLICATE also, no?

uh ????

Modifying REDUCE variant based on REDUCE/INTO, as a general pattern, 
just wondering what the data loss is that BrianH is referring to.

ah! reduce in place.
But what a pain (in the ...)

/INTO is kind of novel and catchy, in terms of some of the optimization 
scenarios it allows for.  Making variants like "/NO-COPY" winds up 
looking like Rebol is doing a bad job of conventions like REDUCE 
vs REDUCE! ... as opposed to playing a whole different game.

It comes to my mind that reduce/into should not behave like inserting 
data but changing them.

Changing data if it's it's at the end of the container will simply 
add them.

But if it's at the head of the container, it will remplace them intead.
Probably more usefull, than the current behavior.

so that 
>> reduce/into data data

would simply do the job we all expecting. To reuse the same block. 
A reduce in place (rest in a peace)

We could only add one behavior for the /into option, and the insert 
behavior was the most basic.

Fork, your method would add the additional series allocation to the 
series itself, temporarily doubling its size (at most). And then 
the reallocated series would stay that size in memory even after 
DEDUPLICATE returns. So overall, worse.

Didn't you say that  UNIQUE has to copy the series anyway?  What's 
the difference?

Would doing the /INTO at the end of the series make it easier for 
the memory allocator to reclaim the space after the remove?

(May have misunderstand what you meant about the algorithm needing 
the original array and a temporary buffer the size of the output, 
as well as the output.)

Oh well, I dunno.  It's too hot here right now to think at all.  
92 indoors in the shade.

{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.} - while this looks like a reasonable 
argument at the first sight, it actually isn't. The reason why is 
based on the way how UNIQUE is (and has to be) implemented. You cannot 
gain any speed worth that name by allowing an implementation doing 
the "UNIQUE job" in place.

Regarding the above, is there a way to reassign and take exisiting 
references with you?   Or, is this a lack of pointer manipulation?

I guess the argument about existing references then also applies 
to 'unique

Looks like the python FBP is http://www.kamaelia.org/Home.html

ooops ... wrong group

Ladislav/BrianH: so doesn't that imply that the UNIQUE/INTO variant 
would be more useful as a native than UNIQUE/NO-COPY?  (I'm not sure 
how a temporary state of a series of length 2N which has N discarded 
is worse than 2 series of size N in which one of those series is 
discarded.)

these reduce/into b b and unique/into b b make me wonder, whether 
the people suggesting it really find such crazy code useful?

(I never felt like using such things)

Rebol looks crazy to most people regardless.  To my midn, if  Rebol 
has so far avoided a convention like /NO-COPY on these other routines 
in favor of /INTO, then consistent and learnable novelty trumps some 
organic evolution of refinements and wording in the core.

I've never had a need for reduce/into or unique/into. The optimizer 
in my brain says reduce/info could be useful, but the rest of my 
brain thinks the lure of possible optimizations will create internal 
strife with said optimizer. :-) I do have an /into refinment on my 
COLLECT func, and the standard COLLECT does as well, but my goal 
there was for convenience is building up results, not optimization.

but the most crazy is not that reduce/into b b "looks crazy", but 
that it is unneeded, and *very* inefficient, unless implemented using 
copying

It doesn't make sense to reduce/into the same series, but that's 
not the intended purpose. Or am I missing something? Of course, people 
might still do it, thinking they're optimizing. :-\