World: r3wp

Ok, I am going to ask my question too.   I have to run a report where 
I collect data from a number of different functions.  Each of the 
functions runs asynchronously.  So, one might return data before 
another.  Not that the order matters.  But the user can select from 
1 to say 6 data functions/sources.

Now since these functions are async, I have to use callbacks to deal 
with the data once it arrives.
What would be the best way of programming this?  

At the end of this, I then need to do something with the collected 
data  .... ie. generate a graph.

Brian, your last function is 2 time slower (on big series) just to 
avoid the collision with the 'result var and because you don't want 
2 distinct foreach blocks (one for /into, one for default).

You also forget to pre-insert void spaces when using the /into option, 
so that your implementation is incoherent with your initial statement 
of the need to avoid memory overhead

Actually, It's your choices (not the best ones to my mind) so i don't 
follow you. 

Finally, i don't see the interest to have not the fastest implementation 
of map in R2 just to have a strict retrocompatibilty with R3.

Each of those functions I am referring to has their own parameter 
list.

I could construct a block of functions, a block of parameters, and 
a data variable . and feed them to the first function, gradually 
removing them from the blocks and passing them in the callbacks?

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.