World: r3wp

Graham, your functions could append their results in a global result 
block, so that you just need to loop and wait into that one ?

What happens if the functions fail?  I could end up waiting for a 
while ....

Ordinarily if I had a couple such functions, I would just call one 
in the callback of the other.

Just that here I don't know how many functions I need to call in 
advance.

OTOH, I have done what you have suggested before .. which is basically 
turning an async function into a synchronous one by waiting till 
it finishes by use of a flag of some type.

Steeve, the function was not added for the /innto option, it was 
added for unset! skipping, which needs to be done all the time.

the result stack could receive some messages too, to know the current 
status (your flag), you could throw errors in the result stack too

Good idea about preallocating for the /into option though.,

Brian, is the R3 map function dealing with unset! values too ?

Yes.

ok

It's not retrocompatibility with R3: R3 is the future, so it's forward 
compatibility. If it's not forward compatible with R3, it won't get 
added as a mezzanine to R2. That is a major difference between writing 
mezzanines and just writing fuunctions.

I really do want to make it fast though, because slow functions don't 
get used in optimal code. This is why most of the loop functions 
from R2 have been converted to natives: The non-native loop functions 
were getting optimized out of R2 code.

so you could use 2 differrent foreach blocks

How would that help?

faster when using default map

The foreach block isn't affected by the /into option, so the code 
would be the same.

not the same implementation than with /into

How so?

you don't need to use a result var by default, remember

IIRC, insert tail [], is faster than result: insert result

No, you use tail instead, which is slower. The increase in overhead 
comes from the if value? stuff.

There is not that much difference between insert tail and res: insert 
res (ignoring caching issues, tail is faster). The if value? stuff 
is the big hit though.

hum...

That is not optional though. You might find it interesting that I 
did break compatibility by not backporting a bug :)

The divide-by-zero error is better than the infinite loop :(

The problem with preinserting with the /into option is break handling. 
If you break in the middle of the process, you end up with a bunch 
of nones in the middle of your series. I am interested in solutions 
to this.

something i don't uderstand with your unset! test.
>>head insert [] do []
== []

so, unset! values cause no problem with insert ??? why do you need 
to test that ?
have you an example ?

>> head insert [] ()
== [unset]

about the preinserting, perhaps you should insert in a second block, 
and then add the second into the result at the end of the process

What version of REBOL are you testing with?

R2

Be more specific.

In 2.7.6:
>> head insert [] do []
== [unset]

lol, SYSTEM/VERSION is a tuple of value: 1.3.2.3.1

I wondering if there was a regression in INSERT at some point in 
the last few years.

shit

about the preinserting when /into.
1/use a new result block! (like for default)

2/when exiting the foreach loop, insert the result into the input 
result

The problem is that the whole point of the /into option is to reduce 
the number of intermediate blocks.,

will work with break but not with return.

or you do a remove/part at the end (need of 2 pointers)

or you do nothing...

and it stay slow

It's a quandry. I already had to add a local function to get around 
the limits of FOREACH, because the alternatives were slower. Do you 
have a solution that handles both breaks and returns?

Keep in mind that returns are supposed to be passed through, but 
you can't detect them.

local function again.

the into option begins th have a huge cost....

Only in one case: Inserting into the middle of a series, which is 
usually slow. We could just special case that one situation, or accept 
that it is as slow as it is in the rest of REBOL.

Graham, how about making a jog processor context. The callback func 
is in there, along with a block to collect the data, so it knows 
what results it should get. Have each function call it back with 
its chunk of data. The callback collects the results, and checks 
to see when a "batch" is complete. Then you just need a timeout element 
(store the start time), and something to ping it. If you store the 
original calls, the processor can retry failed calls.

(about the unset! drawback) it was core 2.6.3.
i wondering if it's not a bug of 2.7.6