Why not use rank 2 polymorphism for `callCC`

[SmartHypercube]

I think rank 2 polymorphism is a must-have for callCC, or this code will not compile:

f :: Int -> String
f x = (`runCont` id) $ callCC $ \exit -> do
    y <- case x of
        0 -> exit "error: x == 0"
        _ -> pure x
    yString <- case y of
        1 -> exit "error: y == 1"
        _ -> pure $ show y
    pure yString

When calling functions like error, throwIO, or exit, which will never produce "normal" outputs, I generally expect the return type to be forall a. a in order to fit in any hole. But the exit produced by callCC does not work as expected. I wonder is there any specific reason?

I tried searching for related discussions, but all I could find is this article. It seems nobody is bothered by this? I have to use absurd to make it work in my code (absurd <$> exit "error: x == 0"). I'm curious about how others deal with this lack of polymorphism.

[kozross]

I'm definitely keen on making this happen, but this requires a major version bump. Once we land 2.3.1, I'm sure @emilypi wouldn't object to this change.

[emilypi]

No objections here.

[int-index]

@SmartHypercube As you insightfully point out, it's possible to arrive at the desired type with the help of Void and absurd:

callCC' :: MonadCont m => ((forall b. a -> m b) -> m a) -> m a
callCC' f = callCC (\exit -> f (fmap absurd . exit))

It's then also possible to get back to the original type as follows:

callCC_ :: MonadCont m => ((a -> m b) -> m a) -> m a
callCC_ f = callCC' (\exit -> f exit)

So the types are isomorphic and it's mostly a matter of preference/convenience which one to go with. Correct?

With that in mind, I don't believe mtl should be setting the precedent. In transformers, we have

callCC :: ((a -> ContT r m b) -> ContT r m a) -> ContT r m a

and mtl generalizes this in a straightforward manner.

So this design issue should be resolved upstream.

[sjshuck]

Upstream ticket: https://hub.darcs.net/ross/transformers/issue/101

[sjshuck]

Per @RossPaterson,

The problem here is that I've tried to keep transformers to standard Haskell.

[ChrisPenner]

I'll drop an anecdote in support of this ticket; I ran into this problem today and spent a good 20 mins double-checking everything before I realized the problem. I can fix this by routing through Void for now, but if it's possible to make this change at some point it will likely save other end-users some time and confusion :)

[Bodigrim]

Per @RossPaterson,

The problem here is that I've tried to keep transformers to standard Haskell.

Realistically most likely any alternative implementation of Haskell will support RankNTypes. E. g., MicroHs supports it.

[sjshuck]

PolyKinds is okay though.

[Superstar64]

Let me share my perspective. I am currently in the process of writing my own Haskell compiler and I am unsure if I'm going to implement GHC style higher rank types or not. The thing about higher rank types is there any many ways to implement type checking for them. I'd recommend the related works section of FreezeML and Quick Look for an overview.

Not to mention that GHC recently changed the way it does type inference with higher ranks with the removal and re-addition of deep subsumption by default.

I would feel less bad about MTL getting the higher rank version of callCC because it always depends on extensions to Haskell 2010, but it would be quite nice of transformers stayed vanilla Haskell 2010. Not just for my compiler, but if anyone else tries to write their own Haskell compiler.

What I would like to suggest for fixing @ChrisPenner's issue is to rename b to void in callCCs type to suggest that Void is only thing you should instantiate that type variable with.

[sjshuck]

mtl changing without transformers changing would be a pain. We would have to starting exporting our own CallCC that has a forall b. in it, and our own liftCallCC's. This would establish the pattern of mtl fixing transformers' problems. I do not want to establish that pattern.

transformers should simply offer RankNTypes versions of callCC/CallCC protected by #if __GLASGOW_HASKELL__ >= 681, and mtl should continue to reexport.