[Haskell-cafe] StateT and ContT

Edward Kmett ekmett at gmail.com
Tue Jan 20 12:09:24 UTC 2015


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 at 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 at gmail.com
> http://IvanMiljenovic.wordpress.com
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20150120/962bf31e/attachment.html>


More information about the Haskell-Cafe mailing list