r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Core] Discuss core issues

Ladislav
25-Jul-2010
[17641]
Why are you asking? You should rather provide a spec enhancement 
of Foreach, if you think it is possible
Graham
25-Jul-2010
[17642x2]
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.
Ladislav
25-Jul-2010
[17644]
aha, so you are suggesting a completely incompatible function spec
Graham
25-Jul-2010
[17645x2]
not at all ...
completely backwards compatible ..
Ladislav
25-Jul-2010
[17647]
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)
Graham
25-Jul-2010
[17648x3]
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
Ladislav
25-Jul-2010
[17651]
The main problem is, that except for DO we do not have (nor it is 
planned) any variadic function in R3
Graham
25-Jul-2010
[17652]
That's not a problem .. just different
Ladislav
25-Jul-2010
[17653x2]
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
Graham
25-Jul-2010
[17655x3]
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
Steeve
25-Jul-2010
[17658x2]
Graham, why don't you promote a new function instead ?
just find a good name
Ladislav
25-Jul-2010
[17660]
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
Steeve
25-Jul-2010
[17661x4]
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
Ladislav
25-Jul-2010
[17665x2]
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
BrianH
25-Jul-2010
[17667]
Especially when combined with the new treatment of setwords.
Graham
25-Jul-2010
[17668]
Steeve, Gab already has nforeach .. .I was just looking to reduce 
the number of functions exposed
BrianH
25-Jul-2010
[17669]
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.
Graham
25-Jul-2010
[17670x2]
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
Ladislav
25-Jul-2010
[17672]
breaks current behaviour
 - much less than any of yours, actually
Gabriele
26-Jul-2010
[17673x2]
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).
Graham
26-Jul-2010
[17675]
forneach is better?  :)
Gabriele
26-Jul-2010
[17676]
foreachn ? lol
Graham
26-Jul-2010
[17677]
I could live with that ... it reads the best
Henrik
26-Jul-2010
[17678]
forsome
Graham
26-Jul-2010
[17679]
foursome?
Henrik
26-Jul-2010
[17680]
Graham, this group is web public :-)
Graham
26-Jul-2010
[17681]
I was just correcting your spelling!
BrianH
26-Jul-2010
[17682]
It's a compound word. The FOR* group omits the hyphens, so FORSOME 
means FOR-SOME.
PeterWood
26-Jul-2010
[17683]
forevery ?
Izkata
26-Jul-2010
[17684x2]
formulti ?
(as in "multiple", not "multiply")
Steeve
26-Jul-2010
[17686]
forfor
Maxim
26-Jul-2010
[17687x2]
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.
Steeve
26-Jul-2010
[17689]
mine is shorter, and is specialy suited to win further puzzles :-)
Gregg
26-Jul-2010
[17690]
traverse [
    all blk-n
    each [a b] blk-a
    skip blk-x 2
    each e blk-e
][
    ;...
]