World: r3wp

22 to 33 milliseconds, depending on input.

it's a shame 'either has a so verbose form ;-)

This isn't C :)

nite Janko

it"s hard work to optimize such short mezzanine

but it's funny too

Indeed it is both, but well worth it :)

for my personnal use, i would have an option to modify the input 
serie instead of creating a new one

The R3 FOREACH is used for that.

Still, good idea :)

an /keep refinement on map ?

/no-copy

i want to see :)

i try...

I did some testing and found that, as a general practice, the /into 
option leads to code with less overhead than the /no-copy option.

The implementation tends to be smaller too, as change-in-place code 
looks very different than fill-something code.

hum, really ?

Using /into for your functions leads you towards reusable buffers 
and incremental building. The /no-copy option tends towards template 
copying. I mean, as the option is used generally.

do you mean by default map should do change ?

Let me show you MAP with /into.

oki

not so easy ? :)

map: func [
    [throw]

    "Evaluates a block for each value(s) in a series and returns them 
    as a block."

    'word [word! block!] "Word or block of words to set each time (local)"
    data [block!] "The series to traverse"
    body [block!] "Block to evaluate each time"
    /into "Collect into a given series, rather than a new block"
    output [series!] "The series to output to"
] [

    unless into [output: make block! either word? word [length? data] 
    [divide length? data length? word]]

    foreach :word data reduce [:insert :tail output to paren! body
    output
]

Sorry, forgot the ] after the foreach

Sorry again, wrong semantics.

hum, i see now, you don't update the input data.

The /into option is supposed to have INSERT semantics, not INSERT 
TAIL.

really ? i don't see what is the need

INSERT semantics are the most general. You can add the TAIL on call.

<-- cowering in the corner, but totally enjoying this demonstration 
:)

clap ... clap ... clap ...

I'm going to do a study of all of the REBOL functions that generate 
series (even natives) and determine which would benefit from the 
/into option, then get it added. It might be tricky to modify actions 
though. REDUCE and COMPOSE are getting the /into option.

This is one of my R3 tasks. We'll backport where possible.

BrianH, how many of you are there actually working on R3 code?

It varies, depending on the task. Right now many of us are taking 
a break and Carl is working on the development infrastructure. Other 
times there are a few in some cases, many in others. We'll be able 
to handle more after Carl's RebDev work.

Which is proceeding nicely :)

That's great to hear :)  I wish I could help, but I don't have the 
chops.  Maybe testing, promotion, things like that...

We need those chops too :)

just a thing Brian, insert (without tail) will revert the result 
and cause overhead by pushing previous added values in the loop...

missing something...

No, it's a different problem: You have to assign the result of the 
insert  to output as you go along. This leads us to another variable 
captre problem.

ok, i see now

but we should use change to do that job, not insert

No, it doesn't change in place, and the /into should be able to insert 
in the middle of a provided series if necessary.

change replace old values in output and expand the output serie if 
needed

Insert will also expand, and we don't want to replace any existing 
values if any.

If you want to replace, clear the series before providing it.

ok but i'm not convinced by the interest to be able to insert in 
the middle of a serie.

ok but i''m not convinced by the interest to be able to insert in 
the middle of a serie

This trick only works if it is pervasively implemented and consistent. 
It is a cross-cutting language design issue.