On Fri, Apr 18, 2008 at 07:22:35PM +0200, TSa wrote:
> HaloO,
> I just wonder what has become of the coroutine feature.
> Was that dropped from the spec? And when yes, why?

Coroutines have never been in the official spec, except in the
form of gather/take.  Pugs implements coro, and the draft I/O spec
mentions them.  But I think coroutines are actually less powerful than
gather/take, insofar as you're limited to returning from the current
coroutine, whereas you can use gather/take over any dynamic scope.

And coroutines are a klunky way to represent lazy lists.  We have
lazy lists already, so forcing the function interface to support them is
not strictly necessary.

> The trick is to design the yield statement nicely.
> And also to define a syntax that allows to get a fresh
> instance from a coro quasi-class.

That's just returning a new lazy list in P6-think.

>   sub foo () { my $x = 0; yield $x++; }

    sub foo () { 0..* }

>   &f = &foo.new; # or also foo.new?

    @f = foo();

>   say f(); # 0
>   say f(); # 1
>   say f(); # 2

    say @f.shift; # 0
    say @f.shift; # 1
    say @f.shift; # 2

or alternately

    $f = foo();
    say =$f;
    say =$f;
    say =$f;

Probably [EMAIL PROTECTED] also works as a shorthand for shift.

Another argument against coro is that you can't analyze it as a
function without side effects, so it becomes rather harder to
parallelize things, much like the difference between

    loop ($i = 0; $i < 10; $i++) {...}
    for 0..^10 -> $i {...}

That is, coro and loop tend to violate single-assignment semantics, and
single-assignment semantics are easier to map into functional semantics.

So if we do allow coro in Perl 6, it'll probably be a second-class
citizen like loop and goto and die (and anything else considered
harmful but useful).  But I don't see much use for it offhand.


Reply via email to