develooper Front page | perl.perl6.language | Postings from July 2006

Re: Containers

Thread Previous | Thread Next
Aaron Sherman
July 11, 2006 12:21
Re: Containers
Message ID:
On Tue, 2006-07-11 at 09:53 -0700, Trey Harris wrote:
> In a message dated Tue, 11 Jul 2006, Aaron Sherman writes:
> > But would it be reasonable to also provide a named-only parameter to
> > each for that purpose?

> 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 *@containers)

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.

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.

> 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 {$}(#$job_no)";
>        $$job_num);
>    }
> I hope not.

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

 our Iterator multi Container::each (Bool :$parity , Container *@containers )

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

Aaron Sherman <>
Senior Systems Engineer and Toolsmith
"We had some good machines, but they don't work no more." -Shriekback

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About