<div dir="ltr">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. <div><br></div><div>Excuses aside, it does appear that the primary reason for the current behavior is to match existing prior behavior.<div><br></div><div>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.</div><div><br></div><div>-Edward</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 18, 2015 at 5:56 AM, Ivan Lazar Miljenovic <span dir="ltr"><<a href="mailto:ivan.miljenovic@gmail.com" target="_blank">ivan.miljenovic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the transformers library, there are two implementations for callCC<br>
for use with StateT (both lazy and strict) [1,2], the second of which<br>
is documented to not satisfy the laws of a monad transformer.<br>
<br>
[1]: <a href="http://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad-Trans-State-Lazy.html#v:liftCallCC" target="_blank">http://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad-Trans-State-Lazy.html#v:liftCallCC</a><br>
[2]: <a href="http://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad-Trans-State-Lazy.html#v:liftCallCC-39-" target="_blank">http://hackage.haskell.org/package/transformers-0.4.2.0/docs/Control-Monad-Trans-State-Lazy.html#v:liftCallCC-39-</a><br>
<br>
However, in mtl the MonadCont class [3] uses the second definition for<br>
the StateT instance.  Is there a good reason for this, or just to<br>
match the behaviour of pre-transformers mtl [4] ?<br>
<br>
[3]: <a href="http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Cont-Class.html" target="_blank">http://hackage.haskell.org/package/mtl-2.2.1/docs/Control-Monad-Cont-Class.html</a><br>
[4]: <a href="http://hackage.haskell.org/package/mtl-1.1.1.1/docs/src/Control-Monad-State-Lazy.html" target="_blank">http://hackage.haskell.org/package/mtl-1.1.1.1/docs/src/Control-Monad-State-Lazy.html</a><br>
<br>
(I did raise an issue for this on mtl's Github issue tracker, but it<br>
hasn't had any responses for two months.)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Ivan Lazar Miljenovic<br>
<a href="mailto:Ivan.Miljenovic@gmail.com">Ivan.Miljenovic@gmail.com</a><br>
<a href="http://IvanMiljenovic.wordpress.com" target="_blank">http://IvanMiljenovic.wordpress.com</a><br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</font></span></blockquote></div><br></div>