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