On 5 Jul 2002 [EMAIL PROTECTED] wrote:
> dan <[EMAIL PROTECTED]> writes:
>
> > At 8:29 AM -0700 7/4/02, Sean O'Rourke wrote:
> > >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.
> >
> > If you want really sick, consider that we are *not* limited to the
> > standard call/cc functionality. Continuations can reasonably be taken
> > at any statement boundary. (They don't work well if taken from within
> > an expression. Or, if they do, it hurts my brain enough that I'd
> > rather you didn't...) You also should be able to invoke them anywhere,
> > including within expressions.
> >
> >
> > You're not obligated to pass the continuation for the call/cc into
> > call/cc (you could pass another one in if you chose), nor, I suppose,
> > are you obligated to not keep it around for later use.
>
> Okay, how about the following as a suggested syntax for getting
> at/using continuations.
>
> 1. You can get the current continuation by doing
>
> caller.continuation;
Does "caller" with no args mean "current execution context", with
caller(1) referring to our caller? We also want to be able to take a
continuation right ahead of the current execution point within our current
function (kind of like a delayed fork), not just at the point where we
return to our caller. I had originally written "caller(-1).continuation"
for this in a previous mail, but deleted it because it seemed only a
matter of time before some asked what caller(-2) would do ;).
> 2. I don't think being able to do C<$block.continuation> is useful
> because continuations are runtime things.
If you can set a block's continuation at runtime, I think you should be
able to get it as well. Then you can splice a function into a dynamically
defined control sequence like this:
my $readfile is private = -> $x { process_data $x, ... };
sub add_post_handler (CODE $block2) { # is public
$block2.continuation($readfile.continuation);
$readfile.continuation($block2.as_continuation);
}
sub read_file($data) { $readfile.($data) }
# ...
add_post_handler -> $x { uncompress $x };
my $sum = "blahblah";
add_post_handler -> $x { die unless $sum eq md5sum $x; $x };
read_file $foo;
One good thing about this is that none of the blocks has to be aware of
continuations itself, and the continuation-handling ugliness can be
separated from the useful-work-doing ugliness.
> 3. C<$block.continuation($a_continuation)> can be thought of as a kind
> of curry. It sets up a 'version' of a block which will return to
> C<$a_continuation>. This would mean you can then do:
>
> $block.continuation($a_continuation).(*@arglist);
>
> which calls C<$block> with @arglist, but the block then returns to
> the continuation.
By "a version, do you mean that $block.continuation($x) returns a copy of
$block with its new continuation? I was thinking it would be useful to
modify $block's continuation, so every caller of $block would get the new
continuation. You could always make a copy of $block (not sure of the
syntax) if you wanted to set up your own personalized version.
> [Unsatisfactory attempt to explain what a continuation is deleted
> because *my* head started to hurt as I tried to explain it...]
I thought your examples (elided) did a fine job...
/s
