World: r3wp

I think change/part is as fast as Rebol's change/part native, and 
hence usable, unless Ladislav proves such pov being somehow fundamentally 
wrong :-)

my take on "speed" is as follows - ppl sometimes object, that you 
use "interpreter". And my answer is - why should I care? The thing 
is either fast enough for me, or it is not fast enough for me. If 
you will try to edit video using REBOL level pixel manipulation, 
you surely will not be happy. But - if your app behaves real-time 
or generally time results are acceptable for you - why to worry at 
all?

Unless Ladislav proves...

 - I did too many times to not feel repeating myself. Read the above 
 reference, please.

Petr, it may be more than fast enough for small cases, or where you 
don't need maximum performance (which is most of the time). The inefficiency 
comes from REBOL having to move things around when you insert things 
into a series (list! being a possible exception).

try this way, with one replace  change may be more efficent , with 
2 replaces bith would need to be in the sccond half of the file , 
with three in the last third ,with 4 the last quarter ...so although 
there may exist pathological cases where it is more efficent it is 
best not to cater to them.  there  may also be an argument  for not 
allocating twice as much memory but iby the time your file is that 
large you are already running into problems (in r2 at least)

I updated the above mentioned Rebol wikibook section - the speed 
discussion subsection added. So, read, it, please (the latest, i.e. 
yet unsighted version!) and see also the CureCode ticket #1570, which 
is related to this issue.

the unsighted version of the article can be found here: http://en.wikibooks.org/w/index.php?title=REBOL_Programming/Language_Features/Parse&stable=0

Please, if somebody finds a good refinement name, let us know.

BTW, re #1570 - I would like to know, what BrianH thinks about the 
necessity to keep the backward compatibility in this case?

Not being a native speaker I think you "change somthing in something", 
so that gives >> CHANGE/TO "ABC" "123" == 123

(sorry, I've hit <RETURN> too early)

The above should've read 

>> head change/to "abc" "123" 2
== "12c"
>> head change/part/to "abc" "123" 1 2
== "12bc"

But it doesn't communicate very well the idea of changing to only 
a part of the second argument.

Probably better:

>> head change/take "abc" "123" 2
== "12c"
>> head change/part/take "abc" "123" 1 2
== "12bc"

Of course that has other semantics than

>> head change/part "abc" take/part "123" 2 1
== "12bc"

and may lead to new confusion.

thanks, your suggestions look sensible, although I am not sure about 
the /take one

i think, it might make more sense to actually implement the often 
talked about series-range! type. Or, have copy-on-write semantics 
for the results of COPY. (the latter would also help multithreading 
IMHO)

/take is a new very usefull function in R3, it's a good idea to use 
it as a refinement to... IMHO

Gab  YESSS!!!


it would also be nice if we could actually just set a soft-range 
to ANY series, removing the need for a specific datatype.

Re the series-range! type: did Carl already say he would like to 
have it?

No

Ranges only interest those who  need highly optimized scripts (avoiding 
any memory overhead)

In that case, the CHANGE refinement may be the only viable way for 
Carl

there are several implementation choices in Rebol where we can say: 
Carl does not bother with the memory issue

and extra speed consideration of having to allocate/copy/destroy 
a series

I like your #1570 proposal, Ladislav, but not the name. Perhaps /span 
might be better, or /range.

/length

it's true, 'change/part does not behave correctly by default.

insert/part et append/part do the right thing we want now for change

That's said too much; I think it's more that CHANGE/PART behaves 
as advertised and the /PART refinement just happens to have a different 
meaning for INSERT or APPEND. 

Neither one of /WITH, /TO, /SPAN and /RANGE communicate very well 
that they refer to the second argument though, and /TAKE has the 
drawback of suggesting that it's taking away from the second argument 
like TAKE instead of leaving the second argument untouched. 

CHANGE/FROM, however, seems to work:

>> head change/from #abcdef #123456 3
== #123def
>> head change/part/from #abcdef #12345 1 3
== #123bcdef 


All that under the assumption that for compatibility, /PART in it's 
current meaning will stay as it is.

It's funny, I always thought INSERT/part was the weird one, and CHANGE/part 
the normal one. Didn't stop me from adding /part to APPEND though, 
in the INSERT style.

I agree with Christian, except that /from doesn't convay the proper 
meaning... another refinement name might be better...

something like 

change/part/only to from  3 4
change/part/amount to from  3 4

?

except that /only is already used... but I'm just suggesting in the 
lexical sense... something closer to the meaning of the refinement.

That's why I suggested /span or /range :)

i suggest  /?

it's short

/?  !?!!??!! 

and meaningless  ;-)

meaningall

change/interval ?  (spelled corectly if necessary)

Comment added: http://curecode.org/rebol3/ticket.rsp?id=1570&cursor=5#comments

Gregg, I used to use append/part to avoid the memory overhead of 
copy/part in many case.
Instead of doing like in the Ladislav's example. 
>> change/part something copy/part something-else range part.
I used  to do.

>> change/part something append/part clear #{} something-else range 
part.
It's not faster, but saves memory.


So, I don't know if it's a good idea to discard this use case from 
append and insert.

Esp in R3

(It saves memory, if the same code is called many times, indeed)

Re "it saves memory" - it is not expected to save memory (the GC 
should handle such code "smoothly")

Sometimes, I can't let the GC acts by himself because it's too late 
and tens of MB would be allocated for nothing.

But I agree it's rare cases, with intensive computations. Rare, but 
it exists.

It does not matter that it is rare: if you can find any unexpected 
of the GC, you should put it to CureCode as a major bug

unexpected behaviour of the GC

It's not a bug to my mind, the GC never acted smoothly.

maybe I just misunderstood, then. If it is not a bug, then you are 
actually saying, that the GC collects everything as expected? If 
that is the case, then why the trouble to "save memory"?