On 4 Jul 2002 [EMAIL PROTECTED] wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > At 8:32 AM +0100 7/3/02, [EMAIL PROTECTED] wrote:
> > >
> > >For true scariness, consider:
> > >
> > > $sub.current_continuation($new_continuation);
> > >
> > Some days you really, really scare me Piers...
>
> Heh. Scary can be good.
>
> > This would be an interesting thing to do, though. I don't see why it
> > couldn't be done.
>
> You know, the more I think about it, I'm not sure it *is* a good
> idea. Once you have continuations in play you could have multiple
> 'live' continuations associated with a single sub, so how would you
> decide *which* continuation was the important one.
All of them! I don't see how the getter/setter mentioned above would
automatically lead down this path to madness, but it's madness I kind of
like. If I'm not confused, the insane version lets you do threading:
$current_block.push_continuation($some_continuation)
or quantum shenanigans:
$current_block.push_continuation(any(*@some_ccs))
And the sane one allows dynamically-joined blocks:
$block1 = { ... }
$block2 = { ... }
$block1.continuation($block2.as_continuation);
$block1($something); # evaluate block1 then block2, then keep going
Sick. Anyways, I think it seems like a more natural way to do things than
traditional call/cc. "$block.continuation" reads as "where do I go after
$block?"; "$block.continuation($foo)" as "after executing $block, proceed
on to $foo"; "(call/cc func)" as "call func with a single argument being
the 'rest of the current computation'". This last definition makes Scheme
and Lisp people happy, but (at least for me) the first two are much easier
to grasp, as they refer to what's going on more concretely.
/s
