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
