# Re: Are coroutines still there?

```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.

Larry
```