transformers versus mtl

[Sittampalam, Ganesh]

Sittampalam, Ganesh wrote:
> Sittampalam, Ganesh wrote:
>> Ross Paterson wrote:
>>> On Sun, Mar 22, 2009 at 06:31:08AM -0000, Sittampalam, Ganesh wrote:
>>>> Essentially we have the choice of producing full compatibility by
>>>> keeping the separate type in mtl, in which case State from mtl is
>>>> not State from transformers, or partial compatibility by
>>>> re-exporting the transformers one.
>>> 
>>> Yes, we must choose between full compatibility with mtl and full
>>> compatibility with transformers.  A quick implementation of the
>>> former is 
>>> 
>>> http://code.haskell.org/~ross/mtl-compat/
>>> 
>>> The separate versions of State etc are present, but deprecated.
>> 
>> Cool. I've been been playing around with regression testing hackage
>> following Duncan's blog post on the subject - I've got a baseline
>> test running now and will try your mtl-compat out next,
> 
> I've tried this now. Various new failures, which I don't have time to
> investigate all of tonight, but the first one I looked at is in the
> 'cgi' package, and is because the Functor instances for ReaderT r m
> and WriterT w m now (correctly) depend on Functor m, whereas in mtl
> they depend on Monad m.    

Here's the list of failures - though it doesn't cover packages that
weren't
installable on my machine for some other reason like needing gtk2hs or
a C library.

blogination-0.5        Functor instances depending on Functor,
                       instance collision Applicative/Alternative ErrorT
category-extras-0.53.5 Functor instances depending on Functor
cgi-3001.1.7.1         Functor instances depending on Functor
encoding-0.5.1         instance collision: Monad Either
logict-0.2.3           instance collision: Applicative Identity
monad-param-0.0.2      Functor instances depending on Functor
mueval-0.7.1           Functor instances depending on Functor
xcb-types-0.5.1        instance collision: Applicative/Alternative
ReaderT
xmonad-contrib-0.8.1   instance collision: Error [a]

and also packages that depend on the above directly or indirectly:
bff, cflp,cgi-undecidable, fastcgi, gitit, kibro, xmonad-eval

and if we go one step further and remove State etc (so they become type
synonyms, repo here: http://urchin.earth.li/darcs/ganesh/mtl-compat ),
the following extra failures:

FileManip-0.3.2            Missing data constructor: State
HAppS-Server-0.9.3         Missing data constructor: Reader
HaLeX-1.1.1                Missing data constructor: State
LambdaHack-0.1.20080413    Missing data constructor: State
applicative-extras-0.1.4   instance Applicative (State a) which now
                           (a) needs TypeSynonymInstances and (b)
overlaps
derive-0.1.4               instance Applicative (Writer a) which now
                           (a) needs TypeSynonymInstances and (b)
overlaps
lambdabot-4.2.2.1          Missing data constructor: State
open-witness-0.1.1         Missing data constructor: State
random-fu-0.0.0.2          instance MonadRandom (State StdGen)
                           - needs TypeSynonymInstances or rewrite with
StateT
yhccore-0.9.1              instance UniqueIdM (State a)
                           - needs TypeSynonymInstances or rewrite with
StateT

and dependencies:
FermatsLastMargin, HappSHelpers, HSHHelpers, HStringTemplateHelpers,
bff,
firstify, formlets, happstack-helpers, hugs2yc, ycextra

So, thoughts on how to proceed? Personally I would be inclined to go the
whole
hog as there isn't that much breakage - the downside being that it'll be
hard
for any of these packages to be compatible with both old mtl and new mtl
simultaneously, with the exception of "Functor instances depending on
Functor"
which can be solved by having both Functor and Monad in the constraints.

I've started contacting the authors of the directly affected packages
and
asking them to add mtl<1.2 to their dependencies so that if we do go
ahead
with any change the disruption will be minimised.

Cheers,

Ganesh

=============================================================================== 
 Please access the attached hyperlink for an important electronic communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 ===============================================================================