On 20 January 2015 at 23:09, Edward Kmett wrote:

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.

Apologies if I sounded harsh about the "no response" in my previous email; it certainly wasn't my intent.

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.

This is what I thought: I just wanted to make sure that I wasn't missing something (especially since there's no real documentation that I could find as to _how_ liftCallCC' fails to satisfy the laws of a monad transformer).

-Edward

On Sun, Jan 18, 2015 at 5:56 AM, Ivan Lazar Miljenovic 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-T... [2]: http://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad-T...

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.h... [4]: http://hackage.haskell.org/package/mtl-1.1.1.1/docs/src/Control-Monad-State-...

(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

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Do people actually *use* the MonadCont class? And those who do... do they really use it in a way that would manifest this breakage? basically every existing user of the instance is pretty much guaranteed to

have breakage.

It seems the answer to these questions is "yes" and "yes." I'm curious to hear more. -- Dan Burton On Tue, Jan 20, 2015 at 10:02 AM, Ross Paterson wrote:

On Wed, Jan 21, 2015 at 12:09:13AM +1100, Ivan Lazar Miljenovic wrote:

...

This is what I thought: I just wanted to make sure that I wasn't missing something (especially since there's no real documentation that I could find as to _how_ liftCallCC' fails to satisfy the laws of a monad transformer).

Any lifting of callCC should satisfy

lift (f k) = f' (lift . k) => lift (callCC f) = liftCallCC callCC f'

and liftCallCC' doesn't. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe