Capturing the continuation of an effect invocation

[osa1]

I'm trying to implement a resumeable exception effect but I'm lost.

The idea is that throw will have a return value. The code catching an exception either handles it or resumes it. Handling is same as normal exception handling. Resumption is done by providing the return value of the throw.

For example, if I have a throw like this:

i :: Foo <- throw FooDecodingException

Then the code cathing the exception can resume the code:

catch x (\FooDecodingException -> pure (Resume ...))

or handle it:

value <- catch x (\FooDecodingException -> pure (Handled ...))

The problem is I'm not sure how to represent the continuation of throw ... calls in the effect type, and how to "capture" it when calling the effect function. So far I have this:

data Exception (resumeValue :: Type) (errorValue :: Type) m a where
    Throw :: errorValue -> Exception resumeValue errorValue m resumeValue
    Catch :: m a -> (errorValue -> m (Resume a resumeValue)) -> Exception resumeValue errorValue m a

type instance DispatchOf (Exception resumeValue errorValue) = Dynamic

data Resume handlerValue resumeValue = HandleError handlerValue | Resume resumeValue

throw :: Exception resumeValue errorValue :> es => errorValue -> Eff es resumeValue
throw = send . Throw

catch ::
    forall resumeValue errorValue es a .
    Exception resumeValue errorValue :> es =>
    Eff es a -> (errorValue -> Eff es (Resume a resumeValue)) -> Eff es a
catch action handler = send (Catch @(Eff es) @a @errorValue @resumeValue action handler)

I'm not sure how to capture the continuation in throw. Is this possible?

Thanks.

[arybczak]

I'm not sure how to capture the continuation in throw. Is this possible?

No.

You can't have access to continuations and MonadUnliftIO instance at the same time (because of functions like bracket or forkIO). See this post for more information.

Is there any particular reason for you trying to reimplement Error?

EDIT: I see your Exception is an amalgamation of Error and Coroutine. But you can't do Couroutine with effectful, so yeah, that won't work.

[osa1]

You can't have access to continuations and MonadUnliftIO instance at the same time (because of functions like bracket or forkIO). See this post for more information.

I checked that post but it just says fork and bracket deoesn't work with non-deterministic control flow, it doesn't explain why.

I also checked MonadUnliftIO documentation, which doesn't mention anything specific to fork and bracket, but says that only ReaderT-like monads can be made lawful instances of MonadUnliftIO.

Is the issue confusing semantics? I can see how capturing a continuation in code wrapped by bracket and entering it later won't run the code in the same bracket. I don't see why forkIO would be confusing though.

(I'm also not sure what "non-deterministic control flow" means exactly.. I think they mean "non-local" instead of "non-deterministic" maybe?)

Is there any particular reason for you trying to reimplement Error?

EDIT: I see your Exception is an amalgamation of Error and Coroutine. But you can't do Couroutine with effectful, so yeah, that won't work.

Some effect systems that implement handling as control flow moving back and forth between an effect handler and the code invoking the effect allow this kind of thing.

For example: https://doc.flix.dev/effects-and-handlers.html

In this language, all effects work like resumable exceptions. An effect invocation is like throwing an exception, and the effect handler can resume the throwing code. The example in the first section of this page shows how to handle an effect (without resuming), and the second section resumes the code invoking the effect.

Since all monadic code in Haskell is in continuation passing style (<effectful code> >>= <continuation>) I was assuming the the continuation is already captured and may be passed around and called later, but it looks like that's not the case in this library, so this kind of things can't be done.