You pinged me on it while I was in the middle of a trip, and when I went to dig into the issue, the rabbit hole went a lot deeper than I could devote at the time. 

Excuses aside, it does appear that the primary reason for the current behavior is to match existing prior behavior.

That said, I'm not sure there is a good way to offer an upgrade path to change the behavior, as it is the sort of thing that would just silently break very large chunks of code in very subtle ways with the user having no reason to suspect that a change in the underlying semantics of the mtl was to blame, so I'm rather reticent about just diving in and "fixing" it as basically every existing user of the instance is pretty much guaranteed to have breakage.

-Edward


On Sun, Jan 18, 2015 at 5:56 AM, Ivan Lazar Miljenovic <ivan.miljenovic@gmail.com> wrote:
In the transformers library, there are two implementations for callCC
for use with StateT (both lazy and strict) [1,2], the second of which
is documented to not satisfy the laws of a monad transformer.

[1]: http://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad-Trans-State-Lazy.html#v:liftCallCC
[2]: http://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad-Trans-State-Lazy.html#v:liftCallCC-39-

However, in mtl the MonadCont class [3] uses the second definition for
the StateT instance.  Is there a good reason for this, or just to
match the behaviour of pre-transformers mtl [4] ?

[3]: http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Cont-Class.html
[4]: http://hackage.haskell.org/package/mtl-1.1.1.1/docs/src/Control-Monad-State-Lazy.html

(I did raise an issue for this on mtl's Github issue tracker, but it
hasn't had any responses for two months.)

--
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
http://IvanMiljenovic.wordpress.com
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe