World: r3wp

Anyreason why this can't be the default behaviour of 'foreach?

the one here might be newer (i don't remember and i didn't check 
:P): http://www.colellachiara.com/soft/libs/utility.r

they're both copyright 2003 and one is dated 2004, and the other 
more documented version is dated 2005  !

The most common case is iterating over a single block, so the current 
behavior makes sense. And while breaking compatibility is sometimes 
helpful in the long run, I hate to think how much code would break 
by changing FOREACH now. FOR, on the other hand, is not widely used 
IIRC, and I've said before I thought it would benefit from being 
a dialected func. Still, we can make our own under a new name and 
then campaign for it.

I guess my suggestion is that the current behaviour is for a single 
block, but it should be able to generalise *without* creating a new 
function.

In the same way 'for does ... where there is a skip counter from 
1 .. n

graham, i think you underestimate how hard it is to generalize FOREACH. 
:) the only thing i can think of is adding a /multi refinement or 
something like that, but then the way you pass arguments is not optimal.

But it's not impossible right?  :)

Why are you asking? You should rather provide a spec enhancement 
of Foreach, if you think it is possible

foreach opt [ integer! ]  [ word! block! ] [ block! ]  [ action block 
]


if the optional integer is missing, then assume it's just the one 
block of data you are working with
Otherwise the integer specifies how many data blocks

we could have that for 'for as well ... if the step integer is missing, 
assume one.

aha, so you are suggesting a completely incompatible function spec

not at all ...

completely backwards compatible ..

aha, it is compatible, since your proposed spec is variadic. OK, 
then it is a different problem: you are out of luck with variadic 
functions, not to mention that it is ugly (at least I do not like 
it)

in so much as I have to tell the interpreter how many parameters 
... yes

otherwise you have to use something which is different syntax

Anyway, I can't see that' it's any different from skip ... or other 
such

The main problem is, that except for DO we do not have (nor it is 
planned) any variadic function in R3

That's not a problem .. just different

Not a problem? For me it is a crucial problem.

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.