From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Tue, 31 Jan 2006 14:01:42 +0100
Bob Rogers wrote:
> From: "Leopold Toetsch via RT" <[EMAIL PROTECTED]>
> Yep. At least as long we don't have better support for creating
> limited continuations that are able to return some results.
>
> I'm afraid I don't follow. What would you consider better?
Limiting the callframe range, where the continuation can go. Currently
creating a continuation is rather expensive, as all RetContinuations up
the call chain are converted into full continuations. This is necessary
because there is no further information about the usage of the
continuation. It could be passed to 'main' and then 'jump' back. Thus
all the intermediate frames have to be kept alive, because normal
function return goes through these frames.
Hmm. In this particular case, that doesn't actually make much
difference. In order to implement certain classes of nonlocal exits,
I'm creating a continuation and stuffing it into a lexical variable, and
I notice that C<newclosure> also promotes the RetContinuation to a
Continuation (though only for that frame).
Worse, the closed-over frame is leaked entirely. (Is this what the
"obviously leaks memory" comment in src/register.c is talking about, or
are there other cases of leakage?) But I think I have a handle on
what's causing this, and hope to propose a fix shortly.
> But, FWIW, I am coming around to the view that continuations
> shouldn't ever be invoked like this . . .
I don't think that we can enforce this. Have a look at
t/library/streams.t. I don't think that a compiler has the knowledge
that it's compiling the invocation of a continuation instead of a plain
subroutine.
Well, mine does, but that doesn't mean much. ;-} Point taken.
The tailcall syntax works, because it's just ignored by the continuation.
leo
Yep; and it also avoids making a useless return continuation, which is
nice.
-- Bob
