Continuation typing about links HOT 12 CLOSED

I believe this is due to a foolish design that we played around with years ago, but which still persists. The source language supports the escape control operator, whereas the IR uses call/cc. The mismatch makes it difficult to properly support polymorphism. We might hope that the captured continuation y be polymorphic, but it isn't.

An obvious fix is to synchronise the source language with the IR.

Ultimately, we might dispense with these control operators in favour of effect handlers.

from links.

Ultimately, we might dispense with these control operators in favour of effect handlers.

Is likely to happen anytime soon? escape is still used in sendSuspend and freshResource which are used to deal with login flow; can this be implemented using effects/handlers now?

from links.

I think we should dispense of escape in the source language now. As far as I can tell, we do not have a single example that makes use of escape.

from links.

It is still used in the prelude, as mentioned above, and the sendSuspend or freshResource functions are used in loginFlow.links and wine.links.

from links.

Is there a particular reason not to just expose the IR's call/cc in the source language and use that instead?

from links.

Is there a particular reason not to just expose the IR's call/cc in the source language and use that instead?

Well, call/cc is not a modular abstraction. It is widely accepted that delimited continuations are superior to call/cc. See for example Oleg's an argument against call/cc.

from links.

Is there a reason to have call/cc in the IR instead of delimited continuations then?

from links.

Certainly if we have call/cc in the IR then we should have call/cc in the frontend as well. Alternatively we could have escape in both.

If we can implement the sendSuspend and freshResource functionality using handlers then we can consider removing call/cc. I suspect we probably can, by inserting some kind of outer handler, but we should do this before scrapping escape / call/cc.

from links.

f we can implement the sendSuspend and freshResource functionality using handlers then we can consider removing call/cc.

I believe too we can achieve this by a similar idea to the one you outlined. An undelimited continuation is in some sense a delimited continuation whose delimiter is the top-level.

from links.

Is there a reason to have call/cc in the IR instead of delimited continuations then?

I don't think so, and we do already have a structured form of delimited continuations in terms of handlers.

from links.

This example:

{ escape y in { ("" == y(1), true == y(1)); 2 } }

should never have typechecked, because we should infer a single common return type for y. If I had to guess, my guess would be that it was typechecking due to an idiosyncrasy of pre-FreezeML treatment of polymorphism type inference. It doesn't typecheck now.

<stdin>:1: Type error: The infix operator
    `=='
has type
    `(Bool, Bool) -a-> Bool'
while the arguments passed to it have types
    `Bool'
and
    `String'
and the currently allowed effects are
    `wild'
In expression: true == y(1).

Fixing it to something that avoids this problem:

{ escape y in { ("" == y(1), "asdf" == y(1)); 2 } }

yields this, indicating that Links's treatment of semicolon expressions has also gotten stricter over time,

<stdin>:1: Type error: Side-effect expressions must have type `()', but the expression
    `("" == y(1), "asdf" == y(1))'
has type
    `(Bool, Bool)'
In expression: ("" == y(1), "asdf" == y(1));.

If we fix this by adding a var _ binding, then it typechecks and runs correctly.

links> { escape y in { var _ = ("" == y(1), "asdf" == y(1)); 2 } };
1 : Int

I don't immediately see a way of replicating the original problem, and am not sure that the original problem was anything directly to do with escape or its differences with call/cc, though I do think it is worthwhile to iron out this wrinkle. I will add/adjust the above test cases and close this.

from links.

I take the final remark about the original problem being nothing to do with the mismatch between escape/call/cc back: it seems from comments in typeSugar:

that the original issue was due to generalizing the type of the escape continuation to "forall a. t -> a" (or, alternatively, "t -> forall a. a") which in the earlier approach to typechecking quantified types would allow the original program. We could still do this, but as the comment also observes, this would lead to a mismatch with call/cc later anyway, so I think the current approach is appropriate until we decide on a rational design (such as implementing both escape and call/cc, or their use cases, using handlers).

from links.