World: r3wp

Notice, that even MAKE was made strictly binary (i.e. not variadic 
as in R2) in R3

Ok, instead of usig an integer ..

if the first parameter of foreach is a block containing blocks, then 
consider it multiple data blocks

And now we always only have three parameters for foreach

Again that's backwards compatible

Graham, why don't you promote a new function instead ?

just find a good name

Thinking about it, it occurs to me might be, if we introduced a | 
keyword into the WORD "dialect" of Foreach as follows:

>> foreach [a b] [[1 2 3] [4 5 6]] [print [mold a mold b]]
[1 2 3] [4 5 6]

, while

foreach [a | b] [[1 2 3] [4 5 6]]
could print

1 4
2 5
3 6

Foreach is so widely used, that no one want it be slowed because 
of some polymorfism behavior.
In resume, your proposal will never be accepted

*polymorphism

Ladislav, I like that

there could be some other operators.
>> foreach [a & b] [[1 2 3] [4 5 6]]

1 4
1 5
1 6
2 4
2 5
2 6
3 4
3 5
3 6

Well, the dialect would certainly add some polymorphism, as it looks.

Neverthless, the meaning of "combined operators" like [a | b & c] 
may become unclear quickly

Especially when combined with the new treatment of setwords.

Steeve, Gab already has nforeach .. .I was just looking to reduce 
the number of functions exposed

We are doing that is other ways, mostly by paring down the number 
of included-by-default non-native functions to just what the system 
needs, and putting the rest into optional utility modules. (I assume 
you were proposing this for R3, since R2 is in maintenance mode.) 
We are also encouraging this kind of thing to go into community libraries. 
However, there is currently a missing feature in R3 that makes mezzanine 
loop functions rather difficult to write (no RETURN or EXIT passthrough), 
so any added loop functions are *definitely* not going into the system 
until that is resolved.

I was just asking for this just for language purity .... I don't 
care if we never see it or not.

maybe it can be done using some hof instead .. Ladislav's suggestion 
breaks current behaviour

breaks current behaviour
 - much less than any of yours, actually

the thing is... would you want the more generic foreach to automatically 
reduce the second argument? 90% of the time you need reduce there; 
but, then you have foreach reducing or not depending on the first 
argument... and so on. there are a lot of subtle problems; i think 
it's simpler to have a more generic function and keep the simpler 
foreach. (alternatively, but this breaks compatibility, make foreach 
generic and use repeat for the simpler case)

the only problems i have with my nforeach are: i don't like the name, 
and the implementation is more complicated than i'd like it to be 
(though, it should be better in R3).

forneach is better?  :)

foreachn ? lol

I could live with that ... it reads the best

forsome

foursome?

Graham, this group is web public :-)

I was just correcting your spelling!

It's a compound word. The FOR* group omits the hyphens, so FORSOME 
means FOR-SOME.

forevery ?

formulti ?

(as in "multiple", not "multiply")

forfor

forsome is really nice.  I like the pun it goes well with the language 
(and its community) not taking itself too seriously.

the name is actually quite appropriate, since the dialect defines 
what is run or not... which implies that only SOME of the data will 
be operated on.

mine is shorter, and is specialy suited to win further puzzles :-)

traverse [
    all blk-n
    each [a b] blk-a
    skip blk-x 2
    each e blk-e
][
    ;...
]

Hmmm, what if you had a body block for each item in the dialect, 
so the main body is the innermost loop. Interesting to think about 
anyway.

Gregg, the issue becomes, do you want all of them to advance at the 
same time, or nested, and if nested, in which order?

I'd say that nested cases are already well handled by what we have 
so they can be ignored.

So... I guess your idea is not bad at all.

I wonder if there is a way for 'if to not return a value?

I'm looking for a pass thru mode if 'if is false

eg. if I want to avoid the #[none]

>> print rejoin [ "hello " if false [ "world" ]]
hello none

>> print rejoin [ "hello " either true [ "world" ]["" ]]
hello world

>> print rejoin [ "hello " if/only false [ "world" ]]
hello

so something like that ...

This is the construct I saw which I don't like

either true [ tail s ][s ]

which I could  then replace with

 if/only true [ tail ] s

It's less verbose and possibly clearer than using the 'either construct

if/else false [][#[unset!]]

>> only: func [c b][if/else c b [#[unset!]]]
>> only true ["howdy"]
== "howdy"
>> only false ["howdy"]