[DOC] Call/CC Re: [Q][Goodie] continuations (was: RE:
Tail Call)
Rob Withers
rwithers12 at mediaone.net
Sun Feb 3 14:27:06 UTC 2002
At 09:27 PM 2/2/2002, Scott A Crosby wrote:
>On Sat, 2 Feb 2002, Rob Withers wrote:
>
> > Hi Scott,
> >
> > It took me a little time to figure some of this out, and none of it was due
> > to that aweful link you posted! ;-) When I search the web for this
> > topic, most of what I get back is headache food.
> >
>
>Heh... That was just a teaser of some of the really fucked up stuff that's
>done with continuations.
Yes, well they seem to be very aggressive little beasties, at least to my
mind. Is it just me who is confused about how to use them and apply them
effectively? Somehow, I don't think so. :) I read a description of
how to convert a function to CPS, and that sorta made sense, but I am not
sure how that matches an OO style. OO being stateful and mutable, puts a
damper on using this mechanism at the application level, for normal
messaging.
It must be the functional style that is confusing me. I wasn't trying to
reimplement the Processor with it, although it looks quite
interesting. With the Future, I am attempting to create a point of
synchronization for the arrival of a reply from an asynchronous message
send, or a notification, and it's handler. This synchronization is between
several processes (at least two), and can be repeatedly
activated. Sometimes I want to be able to specify on which process the
handler is executed, while other times I want it to run on a different
process. Upon reflection, this is probably not the best place to use
continuations. I am not unrolling a loop or rescheduling and context
switching processes. Do continuations get used as a semaphore? This is
what a Future models.
> > The trick with doing callCC in Squeak, is that we don't have callCC:, like
> > your foo example. Instead we create a continuation around a block and not
> > part of a #callCC: expression. Below is a fixed version of your foo/bar:
> > example.
>
>Someone else mentioned this to me. I'm still learning 'the smalltalk way'. :)
Sure, me too.:) I thought callCC would be doable (Continuation
returningTo: thisContext sender sender), but that broke my Squeak!
> The key to getting thi sto work was you example of error handling of
> > objects. With this example, you bail the first time through the setup
> > method (#errorIn:handle:), when the continuation returns nil, as it does
> > the first time. Here was that code:
> >
>
>In both cases, I do return upwards.. There's no way to avoid it. The UI
What does this term, return upwards, mean?
>process never 'goes away'... An infinite loop can happen, but thats the
>exact same as:
> `[true] whileTrue.'
>
>
> >
> > Here is a bare-bones SimpleContinuationFuture, that is inthe attached
> > changeset.
>
>
>Ewww! :)
Please. Realize that this is an object which really explicitly creates and
invokes the continuation. The full ContinuationFuture, is closer to what
I want, and is even worse!
>What you want to do here is to use the fork/exit/yield methods I supplied.
>Handle the continuations as pseudoprocesses yourself, that way you don't
>have to put any trust in race-conditions on the processor scheduling.
>
>Also, I'm unsure why you're using continuations at all.. Why not just
>stuff the aBlock into an instvar 'savedBlock', and do 'savedBlock value'
>in #value:?
Exactly right. It was an exploration into continuations that doesn't seem
to offer offer any advantage. I will continue using DispatchQueues and blocks.
Cheers,
Rob
More information about the Squeak-dev
mailing list
|