In a message dated Tue, 11 Jul 2006, Aaron Sherman writes:
On Tue, 2006-07-11 at 09:53 -0700, Trey Harris wrote:
It sounds reasonable to me, but :stop reads badly.  Maybe C<:strictly>?
Maybe it's not a function of a flag to each, but a marking that certain
lists should be tapped non-exhaustively:

:stop wasn't a great choice, but :with is going to be complicated. I
don't THINK there's such a thing as a named slurpy, so:

   for each(=<>; :with(1..*)) -> ($line, $lineno)

would have to be:

for each(=<>, :with(1..*))

with the signature:

(Container :@with, Container [EMAIL PROTECTED])

I think....

But I don't think that will do, because it fails when you don't know
WHICH list would be the longest (or you have to specify them all
as :with, and that's rather counter-intuitive). Perhaps a stand-alone
adverb, :parity makes more sense.

I don't understand how the word "parity" is being used here... It's not in the mathematical sense of "even vs. odd", nor in the telecomm sense of bit-counting (since one would want to stop if one out of four iterators stopped generating, but also if two out of four did). In the colloquial sense of parity meaning "equality amongst peers", perhaps it makes more sense, but it's a rather overloaded an poorly-understood word, IMHO.

Unless there's an obvious problem with it, let's go with :parity for
now, and we can change it if its usage becomes confusing.

I think both are needed, somehow. The default behavior of each should be as before (returning undef as necessary). If the boolean switch (:stop, :parity, whatever) is set, then each should stop generating as soon as any argument stops generating. I'm not denying that need. But I'm saying that there is also a need for a mixed-case usage.

This is another one of those cases where you have to have at least three items to see a difference, at (0|1|2)-ary the semantic differences collapse.

One would like to be able to say all of "stop once this iterator runs out" (these adverb names are intentionally awful):

   for each(:stop_on_exhaustion(=<>), @line_id_cookies; 1..*)

"Stop when anything besides this iterator runs out":

   for each(=<>; @lines_to_merge; :attach_as_needed(1..*))

"Stop when any iterator runs out":

   for each(:stop, @subjects; @objects; @verbs) -> $s, $o, $v

This all makes me wonder if there's any problem with mixing and matching
these loop modifying subs:

   for each(roundrobin(@queue1; @queue2); :with(1..*)) -> $task, $job_num {
       say "Running task {$task.id}(#$job_no)";
       $task.run(:$job_num);
   }

I hope not.

This makes me re-think each a bit... it might have to return an
iterator:

our Iterator multi Container::each (Bool :$parity , Container [EMAIL PROTECTED] 
)

Given that, you could string eaches all you like, but otherwise it's not
terribly useful.

They need to chain and nest intelligently.

Trey

Reply via email to