Front page | perl.perl6.language |
Postings from May 2003
Re: Coroutine calling convention
Thread Previous
|
Thread Next
From:
Anton Berezin
Date:
May 5, 2003 03:58
Subject:
Re: Coroutine calling convention
Message ID:
20030505092400.GC46256@heechee.tobez.org
Luke,
On Fri, May 02, 2003 at 09:39:26AM -0600, Luke Palmer wrote:
> > On Fri, May 02, 2003 at 07:09:02AM -0600, Luke Palmer wrote:
> >
> > > [whatsit about an iterator interface to coroutines]
>
> > I don't like this. Iterators can be implemented in terms of
> > continuations which can be implemented in terms of coroutines.
> > (Actually, what Dan has described in his blog entry is a
> > continuation in my book; I'd be glad if someone show me that I am
> > wrong)
> You probably have your terms switched around, then. The general way
> it's thought of (when the thinkers invloved keep their heads by the
> end :) is that coroutines are implemented in terms of continuations.
> But if you were sufficiently clever, I suppose you could do it the
> other way around, too.
> A continuation is an object that closes over the entire stack and the
> execution point (see Dan's other blog entry on continuations). A
> coroutine is a convenience feature that allows you to temporarily
> suspend the execution of a function to return a value, and then pick
> up where you left off when told to do so (usually returning more
> values in a similar manner).
:-) There really seems to be a lot of confusion over terminology on
this list. I'll admit that my only source was what perl5 Coro module
does, and there coroutines and continuations are indeed switched around,
comparing to what you describe.
Anyway, that's beyond the point.
> > So what you suggest is essentially a needless limitation. Even
> > perl5 coroutines (Coro and Coro::*) can do more at this point!
>
> I don't quite understand. What is limited about it? Can you give an
> example?
And the point being...
What you suggest looks nice, and there is very little which can be
misunderstood in this approach. But! You essentially limit the
semantics to Dan's case 1, with a possibility to explicitly achieve case
2 behavior (by making two `iterators'). It is not possible to implement
case 3 at all.
On the other hand, if the coroutine semantics were to correspond to case
3, then case 1 is trivially implemented (by copying), but there is no
way to achieve case 2 behavior.
In my opinion, the ability to implement/to choose from all three cases
would be neat, neat, neat. How? Dunno.
Another thing which I don't like about your proposal is that it is too
explicit, and involves a preparation/initialization step.
$Anton.
--
Our marketing people are so good they can solve technical problems.
Thread Previous
|
Thread Next