different flavours of Monad Transformer Library (fwd)

[Mauro J. Jaskelioff]

Hi, sorry for the late reply,

I have no problem with your proposal (mtl-data).
I'd prefer to have all the liftings in the same package, though
(and not just separate the ones with FD). I also like Ross' idea of
monads being synonyms for transformers at Id.
It removes lots of repeated code.

Wrt portability, I'm working an another experimental monad transformer
library
(http://www.cs.nott.ac.uk/~mjj/monatron ) which, unlike mmtl, does not
try to be backwards compatible with mtl.
It contains a core with full functionality (except operation
overloading) which should work in Haskell 98+Rank2Functors.
Lack of operation overloading means you have to be explicit about the
liftings. (for example, declare you want the operation 'catch' lifted
through 2 monad transformers)
With other extensions (FD, multiparameter classes, etc.) you also get
operation overloading.

All the best,

- Mauro


Henning Thielemann wrote:
>
> I don't know whether you are on the libraries at haskell.org list ...
>
> ---------- Forwarded message ----------
> Date: Sun, 4 Jan 2009 23:50:28 +0000
> From: Ross Paterson <ross at soi.city.ac.uk>
> To: libraries at haskell.org
> Subject: Re: different flavours of Monad Template Library
>
> On Sun, Jan 04, 2009 at 11:22:15PM +0100, Henning Thielemann wrote:
>> I see now at least three MTL libraries at hackage, namely
>>   mtl
>>   mmtl
>>   mtl-tf
>>
>>  They all define both the example data types and according type classes
>> in modules with the same name. This way you can only use one of these
>> packages in all packages you import. However the data types are defined
>> the same way in the packages, only the classes differ.
>>
>>  I wished, there would be one package defining only the datatypes, say
>> "mtl-data", and three ones with the names "mtl", "mmtl", "mtl-tf" that
>> define their classes with corresponding instances. These classes should
>> be in different modules, so you can use different class frameworks in
>> the
>> same project. The data type package would be useful on its own and could
>> be run on the simplest Haskell compilers, since no functional
>> dependencies are required.
>
> I agree.  I had a go at such a restructuring of mtl a while ago:
>
>     http://darcs.haskell.org/packages/transformers/
>     http://darcs.haskell.org/packages/mtl-split/
>
> The first is a Haskell 98 package that defines the monad transformers,
> operations and liftings, like the mtl-data suggestion.  The second adds
> the FD-based classes.  It's close to complete compatibility with mtl,
> except that State is a synonym for StateT Identity etc.  The main
> problem was haddock's limitations with inter-package re-exports.
>
>>  However there is the compatibility problem: Currently
>> Control.Monad.State exports also the MonadState class, which would no
>> longer work. Maybe we can reserve Control.Monad.State for mtl, which
>> exports Control.Monad.State.Data.Lazy from mtl-data and
>> Control.Monad.State.Class from mtl.
>
> I used Control.Monad.Trans.State.Lazy for the transformer.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.