World: r3wp

rebol IS NOT another language... that was my point.  thanks for pushing 
it   ;-)

but in any case, REBOL style usually uses the '* as a notation for 
"pointer" or "reference to",

uh ? in your dream i guess

(more lost messages and dropouts)

Steeve, REBOL gets its speed of programming by preferring unshifted 
characters to speed typing of code, and English-like naming to speed 
reading. The syntax and naming conventions of REBOL were carefully 
chosen for good reason.

Steeve, other languages that use the * convention use it differently 
from each other. C-like languages use it for pointers. REBOL uses 
it for keeping the original definition of redefined words, like COPY* 
(not for pointers or references, Maxim, because those are implicit). 
The only language in major use that uses * to mean do-many-or-all 
is Regular Expressions.

brianH to me, a reference in rebol is not the same as a reference 
in C.  semantically they are equivalent, even if technically they 
are implemented differently.

note the use of equivalent... over... "the same"

meaning, keeping a reference to some data.   which is why we never 
use a-word* to store scalar values for example, but we will sometimes 
use them for copies of series, and words.

All assigned non-immediate values are references in REBOL, implicitly 
:)

bbl

I know  ;-)

why is why reference, in REBOL, has a different meaning to me.  if 
all words are references in C terms, then that concept has its own 
meaning in REBOL terms... IMHO.

Brian, don't lecture me, I know those obvious things too (Bad habit)
I just think '* is as good as -EACH and shorter.
So '* is the winner.

'* doesn't mean anything.  so its pointles... 


so you'd rather have acronyms for cunction names... just make  it 
totally cryptic?  ' * '  isn't english for any thing.  rebol doesn't 
name things in CS terms, it uses readable english.

cunction = function

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.