World: r3wp

English doesn't mean anything to me :)

guys, chill out :-) How often will you use map-each so that it will 
irritate you? Well, I do care for naming conventions too, but I have 
my reservations for where imo architecture goes wrong, like using 
read-text, load-plugin and similar stuff ....

Steeve :-)

quoi?   ;-)

speak for yourself ...  I will use it many times :)

I prefer just "map", but if there's going to be a name change, I 
think "map-each" is best - not only is it consistent with foreach, 
remove-each, etc, it's shorter than "map-every" or other alternatives, 
and feels like more natural English to me.

And I use my map all over the place

if nothing else, at least keep "map" in the name.  Part of the reason 
I dislike "accumulate" for fold - it's harder to find, coming from 
another language

Yes, map is useful.
Maxim, map this "baillon" on your mouth :-)

Izkata: it is not consistent with foreach, it would have to be for-each 
then :-)

my vote now: map-each , filter-each (isn't remove-each reverse in 
meaning) , fold-each (accumulate - I never know how to type this 
word) ... and something like find-each would also be very nice to 
have

Wow, what hemorrhage...
Why don't you add -EACH everywhere we deal with series then ?

Steeve .. do you say this to me because of find-each :) .. I mean 
a fing that uses block of code to determine what to find .. like: 
find-each x numbers [ x > 3 ]    ... in same manner as map/fold/filter 
work

I also wanted change-each :-)

i propose a new fork for rebol.
REBOL-EACH

hehe :)

fact is that find with a codeblock as criterium would be very usefull 
.. maybe it already exists under some other name? I remember someone 
proposing it not a long ago too

Pekr, the FOR* functions have their own naming convention, and for 
historical reasons "-" isn't included.

I use map reduce and seek  at jsgoo and I can do a lot of stuff with 
those (an appy inject for dictionaries) .. let's say you want to 
check if users with username and password exists in a block of users:

find-each U users [ all [ equal? U/user user equal? U/pwd pwd ] ] 
... much cleaner and more error prone than with foreach IMHO ( and 
these functions show intent of why you are looping through block 
of users )

(seek is similar to  what here would  be find-each for example)

Steeve, the *EACH functions have a really specific calling convention 
and all have the same bind/copy overhead for the code block. The 
other series functions have neither of thoise characteristics.

Janko, I agree on one point, i dislike the name remove-each (too 
long).

Why don't we use the short name "filter" which is not used anywhere 
else (so we don't need -each prefix to decipher it from other uses).

(error proff  not error prone ) :))

Janko, REMOVE-EACH is not reverse in meaning - elements are removed 
if they meet a particular criteria. The REBOL version is modifying, 
though.

Steeve, is the filter function modifying or does it return a new 
series?

Brian: but don't you usually want to whitelist not blacklist stuff, 
(what should stay not what should be lost) ? I don't use something 
like filter much so I don't know what is more used

I use REMOVE-EACH a lot in R2, but mostly because of how fast it 
is. It is easy to make your condition return false or none.

ok

Pekr, MAP-EACH (using the new name) is used in LOAD to implement 
LOAD [%s1.r %s2.r ...]. I don't know how it is used in the rest of 
the mezzanines. I mostly use it in my own code, but the version I 
backported to R2 as a mezzanine.

can I just express humble request that if you will have something 
like map in "core" please also have accumulate .. they are cousins 
if you use one you will also the other .. (like map-reduce) :)

I tried, but it won't go in the core - it has been moved to R3/Plus.

to bad... I gues some people won't use neither map-each or accumulate 
, but those that will use map-each will also use accumulate, as they 
together give you the most usages of foreach and other primitive 
loops

Other functions that are in the core now will also be moved to R3/Plus. 
We don't know which will make the cut, just that the cuts are coming. 
The core will be tight, bt the functions will still be available 
if you need them.

ok.. no problem I will survive .. I am happy that they will be there 
core or plus

Janko, map and fold are only efficient in functional languages that 
are compiled and optimized. In hand-optimized, interpreted languages 
iteration is *much* more efficient.

You could use map and fold to implement foreach, but FOREACH is much 
faster that that implementation.

that that -> than that

if I would care only for efficient I wouldn't be using compiled languages 
anyway .. sometimes it doesn't matter that much .. I like map/fold 
because they cleanly express what you want to do , you don't have 
to setup and update temp variables and they are expressions ( they 
return result)

wouldnt = would

Pekr, LOAD-PLUGIN is an internal function. We reserve the most awkward 
names for the internal functions :)

And READ-TEXT doesn't exist and won't - it will probably be READ/text 
instead.

I don't know about the name "fold" - it has ambigous meaning in English, 
with the primary meaning being something else.

I don't care about the exact name much ... I usually call it reduce 
but reduce has a very important and basic meaning in rebol already

Yeah, and a different meaning too...

I am OK with MAP -> MAP-EACH.

BrianH: one question - what is the motive to have R3/plus? Is there 
really a need to move few funcs out from main R3 module? Isn't it 
a bit preliminary?

ah, BrianH, if you think that I will not mind have read/text, then 
you are unlucky here - man, it really sucks :-)

This is exactly the case, where something is under-engineered, and 
influences REBOL's design. There would be no need for such an exception, 
if Codecs would be able to work the streamed way, not just upon the 
data in memory ....

Above reminds me - does our parse enhancement proposal contain request 
to continuous (streamed) parsing? I can imagine parse being fast 
enough to have REBOL level codecs. But surely I don't want to read/part 
manually, nor do I want to read 1GB of video into RAM, just to find 
out, what the codec is :-)

parse on ports definitely is possible, but would have limitations. 
 because of the rollback aspect of rules.

if bytes aren't available anymore, we can't rollback, obviously...

could be solved by buffering, but the quesiton is, how much to buffer 
anyway, so it really might not work :-)