On 5/4/05, Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> Ok - this isn't what I was expecting at all. That doesn't make it a
> bad thing. Given something that looks a lot more like a typical
> coroutine:
>
> sub example is coroutine {
> yield 1;
> yield 2;
> yield 3;
> }
>
> I would expect
> for 1 .. 5 { say example() } to print "1\n2\n3\n1\n\2"
Ding! You just hit the disagreement point. You're on Damian's side.
(But don't take the argument below to be "against" you; I'm just
stating it for the list, assuming I haven't already (which may be a
poor assumption)).
Here's a short form of my side, then: once you start a coroutine,
you've given it state. Subroutines, according to most modern
programming practices, shouldn't have state (well, they can manipulate
globals and such, but "static" variables in subroutines is looked down
upon... it's one of those shuns that I actually agree with). So, in
my proposal, when you call a coroutine, it returns an iterator (and
doesn't call anything):
my $example = example();
=$example; # 1
=$example; # 2
The thing this buys over the traditional (which I refer to as the
"stupid") way, is that you can do this:
my $example = example();
my $example2 = example();
=$example; # 1
=$example; # 2
=$example2; # 1
=$example; # 3
There is _no way_ to do that using the stupid way.
Sorry for my language... it's just that if I were dropped into a
project that invented that abstraction for something it was doing, it
would be one of the first things I'd change. Totally unscalable
design.
> If I got fancy and added a parameter
>
> sub example ( $num ) is coroutine {
> yield $num;
> yield $num + 1;
> yield $num - 2;
> }
>
> I would expect
> for 1 .. 5 { say example( 7 ) } to print "7\n8\n6\n7\n8";
And here is where it gets trickier:
say example(7); # 7
say example(7); # 8
say example(8); # 8? 6?
Luke
