Re: different flavours of Monad Transformer Library (fwd)

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@haskell.org list ...
---------- Forwarded message ---------- Date: Sun, 4 Jan 2009 23:50:28 +0000 From: Ross Paterson
To: libraries@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@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.

On Wed, Jan 7, 2009 at 11:23 AM, Mauro J. Jaskelioff
Hi, sorry for the late reply,
I also like Ross' idea of monads being synonyms for transformers at Id. It removes lots of repeated code.
There's a cost to that technique. Parsec3 introduced parsec as a monad transformer, and the parsec base monad is implemented as the transformer wrapped around the identity monad. There's a significant speed regression to doing so - I have a branch of Parsec3 which re-introduces a proper base monad and shares (some) code via typeclasses. This puts us back at Parsec2 numbers. I don't have any hard data on hand at the moment, it's been a while. -Antoine

Hello,
While people are discussing different monad libraries---there is also
monadLib that I and some of my colleagues use. It is fairly small and
it works pretty well, I think.
-Iavor
On Wed, Jan 7, 2009 at 12:28 PM, Antoine Latter
On Wed, Jan 7, 2009 at 11:23 AM, Mauro J. Jaskelioff
wrote: Hi, sorry for the late reply,
I also like Ross' idea of monads being synonyms for transformers at Id. It removes lots of repeated code.
There's a cost to that technique.
Parsec3 introduced parsec as a monad transformer, and the parsec base monad is implemented as the transformer wrapped around the identity monad.
There's a significant speed regression to doing so - I have a branch of Parsec3 which re-introduces a proper base monad and shares (some) code via typeclasses. This puts us back at Parsec2 numbers.
I don't have any hard data on hand at the moment, it's been a while.
-Antoine _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Am Mittwoch, 7. Januar 2009 21:28 schrieb Antoine Latter:
On Wed, Jan 7, 2009 at 11:23 AM, Mauro J. Jaskelioff
wrote: Hi, sorry for the late reply,
I also like Ross' idea of monads being synonyms for transformers at Id. It removes lots of repeated code.
There's a cost to that technique.
Parsec3 introduced parsec as a monad transformer, and the parsec base monad is implemented as the transformer wrapped around the identity monad.
There's a significant speed regression to doing so - I have a branch of Parsec3 which re-introduces a proper base monad and shares (some) code via typeclasses. This puts us back at Parsec2 numbers.
I don't have any hard data on hand at the moment, it's been a while.
-Antoine
Isn’t it possible to make GHC more clever to remove this speed penalty? Best wishes, Wolfgang
participants (4)
-
Antoine Latter
-
Iavor Diatchki
-
Mauro J. Jaskelioff
-
Wolfgang Jeltsch