Re: call/cc and recursive vm invocations

[Neil Jerram]

Andy Wingo <address@hidden> writes:

> Hey folks,
>
> One of the last missing features / regressions on my list for 2.0 is to
> fix make-stack and start-stack to work with the VM.

Yes, I'd noticed that.

> The solution is to implement start-stack for the VM. Prompts provide an
> ideal set of primitives.

Really?  I'm anticipating some of what you've written below, here, but
isn't using prompts and continuations, and maybe completely changing how
continuations can be used, a bit of a sledgehammer, when all we want to
do is tell `backtrace' to limit the set of frames that it prints out?

>   (define (make-stack tag . narrowing)
>     (let ((prompt-tag (assq-ref (fluid-ref stacks) tag)))
>       (unless prompt-tag
>         (error "prompt tag not found quoi"))
>       (narrow-stack
>        (continuation->stack
>         (call/cc
>          (lambda (k) k)
>           prompt-tag))
>        narrowing)))
>   
> And this assumes that we factor out stack narrowing to its own
> procedure, and that continuation->stack exists (it does now, inside
> scm_make_stack)...
>
> ...and, that we have a call/cc that takes two arguments.

But, instead of requiring call/cc to change, couldn't we also write a
new primitive equivalent to the combination:

    (continuation->stack (call/cc identity prompt-tag))

(Actually this sounds pretty similar to the current scm_make_stack, with
an added search for prompt-tag.)

> Now, currently "full" continuations integrate just fine with delimited
> continuations. (Recall that full continuations copy the whole stack,
> both on the C and Scheme level.)

Do you mean in theory, or in current Guile?  I'm afraid I'm not up to
speed with where things have reached.

<pause to check code...>

OK, so it looks like we now have abort and prompt as primitives, and
catch, throw etc. implemented in terms of them, but that continuations
are thus far unchanged from their old form.  Is that correct?

I think this means that the idea of composable continuations, as
discussed in your blog, is still pending.  Also, if I'm understanding
correctly, it seems to me that that idea is the same as having a 2 arg
call/cc.

If so, I think your email isn't proposing any new concepts beyond what
you raised before, but rather highlighting an implication of
implementing those concepts.

Is that all correct?

> In fact this actually adds more power to call/cc, by allowing the user
> to delimit the scope of the continuations that it captures (via
> prompts).

Agreed - but this is just repeating what you've said before, isn't it?

> Finally, delimiting call/cc makes it more expressive when invoked from a
> callback API. Imagine you have some inversion-of-control library that
> calls your code every so often -- currently in Guile you can't capture
> the continuation in one callback, then invoke it in the next, because it
> means your first callback would return twice. Well, truth is you can,
> but often callback-style APIs are implemented in C or such, and often
> such code can't handle multiple returns.

Yes, I've hit this issue.  It can be solved though, with Guile 1.8.x.

> Relatedly, delimiting the continuations makes it easier to think about
> shipping them across the network.

Interesting.

>                               *  *  *
>
> So, that's the upside. The downside of delimiting "full" continuations
> is that you can't capture the C stack.

Why?  Also I'm not sure what "full" means here.

>                               *  *  *
>
> Practically speaking... I think I can delimit call/cc with not much work
> (perhaps tomorrow). But it is a visible change (if you're looking), so I
> wanted to put this mail out there to get comments.

Well, I hope that some of mine are useful.

I'm afraid I don't yet understand well enough (despite all of the
explanation above) what the impact of this visible change would be;
perhaps some more concrete examples would help.  But it seems a very big
change, if it's only to produce delimited backtraces.

> I had thought this
> was a 2.2 feature, but given the make-stack implications, I'm thinking
> it's a 1.9.9 feature. Reactions?

My feeling is to do something smaller to get make-stack working for 2.0,
and look at the wider change for 2.2.  But I'm far from sure about that.

Also, is there any possibility of keeping both old- and new-style
continuations side by side?

> Happy hacking,
>
> Andy

Regards,
      Neil