Excerpts from Edward Kmett's message of Tue Nov 17 05:03:01 +0100 2009:

On Mon, Nov 16, 2009 at 8:42 PM, Erik de Castro Lopo

...

wrote:

...

Valery V. Vorotyntsev wrote:

...

Thus, the question is: are there any transformers-specific features iteratee package needs, or can it just go with mtl?

I have successful build iteratee by replacing transformers with mtl in the .cabal file.

...

I suspect mtl to be more popular... And actual "popularity" can be measured.

Popularity is not the issue. The issue is that we are currently in a transition from using mtl to using transformers. See:

http://www.haskell.org/pipermail/libraries/2009-March/011415.html http://www.haskell.org/pipermail/haskell-cafe/2009-October/067744.html

Are we?

Let's make a poll then! transformers+1 -- Nicolas Pouillard http://nicolaspouillard.fr

Johan Tibell wrote:

I went back and reread the two linked threads and I'm no wiser as to why we should prefer transformers.

The key point of transformers is that mtl is approximately the same as the combination of transformers + monads-fd - where transformers is H98, and monads-fd has the functional dependency based type classes (MonadState etc). So making the split means that only code that actually needs those classes need depend on them. Since the future of fundeps is up in the air, this seems like a better position to be in. It also enables people to use monads-tf (i.e. type family based classes) without using an incompatible set of transformer types (which is what mtl-tf contains).

I'd like to see an argument describing the benefits of using transformers vs the drawbacks (including how much code would break).

Migration would be by releasing mtl-2.0 which re-exports transformers + monads-fd. There are a few changes in transformers compared to mtl which clean up the design but at the cost of breaking backwards compatibility - one prominent example is that Functor instances in the transformer types now depend on Functor instances in the base types, where as mtl has them depending on Monad instances. Another change (which isn't crucial to the migration) is to replace the currently separate State, Reader etc types with type synonyms to StateT Identity, ReaderT Identity etc. http://www.haskell.org/pipermail/libraries/2009-March/011471.html roughly summarises how much of hackage would break as of then (March 09). I haven't had time to rerun the experiment recently, which is one reason I haven't made a formal proposal yet. I also think that I didn't do anything to test packages that follow the PVP and thus wouldn't have picked up the newer mtl due to having an upper bound on their mtl dependency. Of course such well-behaved packages won't break immediately but will need code changes at some point to be brought up to date. None of the compilation problems are hard to fix, as far as I know. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

On Tue, Nov 17, 2009 at 10:19 AM, Nicolas Pouillard < nicolas.pouillard@gmail.com> wrote:

Excerpts from Edward Kmett's message of Tue Nov 17 05:03:01 +0100 2009:

...

On Mon, Nov 16, 2009 at 8:42 PM, Erik de Castro Lopo

...

wrote:

...

Valery V. Vorotyntsev wrote:

...

Thus, the question is: are there any transformers-specific features iteratee package needs, or can it just go with mtl?

I have successful build iteratee by replacing transformers with mtl in the .cabal file.

...

I suspect mtl to be more popular... And actual "popularity" can be measured.

Popularity is not the issue. The issue is that we are currently in a transition from using mtl to using transformers. See:

http://www.haskell.org/pipermail/libraries/2009-March/011415.html

http://www.haskell.org/pipermail/haskell-cafe/2009-October/067744.html

...

Are we?

Let's make a poll then!

transformers+1

FWIW, +1 transformers. I like being able to swap monads-fd and monads-tf. Michael

On Tue, Nov 17, 2009 at 09:09:07AM -0500, Edward Kmett wrote:

I like that transformers is Haskell 98 and presents a common core. I think that factoring it out is a laudable goal.

However, my very problem is that monads-fd and monads-tf are mutually incompatible. It fragments the community of monad combinator users even further.

If monads-fd sat in the existing location of mtl or was exported there by an mtl compatibility layer and monads-tf used a different namespace then you would have a clean solution in which both could be used in the same code, because both could be loaded.

The proposal is to make the next version of mtl a near-compatibility layer over monads-fd and transformers; it doesn't involve monads-tf directly. We could just rename all the modules in monads-tf (which aimed to mirror mtl-tf), or perhaps rename the modules in both monads-fd and monads-tf. Perhaps we should trim both packages to just the class modules (the others are re-exports mirroring mtl) and relocate those in the module hierarchy: Control.Monad.Cont.Class Control.Monad.Error.Class Control.Monad.RWS.Class Control.Monad.Reader.Class Control.Monad.State.Class Control.Monad.Writer.Class They both have the same Cont class; it need not be duplicated.

On Tue, Nov 17, 2009 at 07:33:05PM -0500, Edward Kmett wrote:

For symmetry I agree both should probably be renamed.

Naming suggestions are welcome. Also comments on the idea of dropping the non-class modules from monads-*.

What are the current breaking changes?

I gather from the discussion that State is no longer separate from StateT, along with Reader, Writer, RWS, Error, mutatis mutandis to obviate the need for both a base monad and transformer.

Right, so modules that declare instances of State, etc, or use their data constructors, will break. In the former case the instances will in most cases become superfluous. Some packages declare orphan Applicative or Alternative instances, which will also become superfluous. The Functor instances in transformers depend on Functor rather than monad. The breakage can be fixed by adding functor instances.

I guess the question is then, when should code start looking to changing their dependencies over to monads-tf and monads-fd?

A cleanly demarked cut over would be useful to get us out of this limbo state that helps nobody.

According to Ganesh's survey, 17 packages (and their dependents) on hackage would be broken by turning mtl into a compatibility layer over transformers+monads-fd. They would need to be updated, but need not switch to monads-tf or monads-fd. Or they could avoid breakage by adding a dependency mtl < 2. Individual packages could switch to the new packages at their leisure. I agree that the current situation is problematic -- I think we should press on and replace the mtl.

On Wed, Nov 18, 2009 at 06:04:24PM +0000, Duncan Coutts wrote:

Ross, if the plan is to have the new combined package be mtl-2.x then you might as well go ahead and modify the preferred-versions file to add:

mtl < 2

Then cabal-install will then use the old mtl for all the old packages that do not use an upper bound.

We should also add mtl to the list packages to check in Distribution/PackageDescription/Check.hs. At the moment it's hard-coded to be a list of 1 (base), so that'd need doing too. This would eventually be replaced by a generic way of opting into the regime.

Or, if you all think the amount of breakage is not that great, and it'd be simpler just to fix the packages affected, then do nothing :-)

I've just realized that it's not going to be as painless as we thought, and I'm not sure this is something preferred-versions can help with. (But I still think the transition is worth doing.) My original plan was to refactor mtl as transformers + monads-fd, so that together they'd offer a bunch of modules that were near-compatible with the modules of the same name in mtl. In only a tiny minority of cases would it be necessary to change code, but everyone would have to replace their dependencies on mtl with dependencies on transformers and monads-fd (though the latter wouldn't always be needed). Then Ganesh whipped up an mtl compatibility package, that re-exported modules from the two packages. Almost all the packages in hackage would compile unchanged if this package was mtl-2.0. But there's a problem: even if we rename the modules in monads-fd, we still have two modules in transformers that have the same names as modules in mtl, namely Control.Monad.Identity and Control.Monad.Trans. Renaming isn't an option: at least the first of those is the Right Name for the module concerned. People who build with cabal are fine: only the dependent packages are exposed, and all packages use the same type constructors, so the interfaces are compatible. But people who build with ghci or ghc --make will get the error message at the top of this thread: Could not find module `Control.Monad.Identity': it was found in multiple packages: mtl-2.0 transformers-0.1.4.0 So I think we're back at the original plan: a big bang replacement of dependencies on mtl with dependencies on transformers and monads-fd. (Unless we introduce virtual packages.) After that we could rename the FD-using modules slowly using the usual deprecation procedure. But we should rename the modules in monads-tf now -- all that needs is for someone to suggest good names.

If you are modifying the preferred-versions file, would you mind sticking in:

cabal-install < 0.8

done

On Tue, Nov 24, 2009 at 10:26:56AM -0000, Sittampalam, Ganesh wrote:

Ross Paterson wrote:

...

Could not find module `Control.Monad.Identity': it was found in multiple packages: mtl-2.0 transformers-0.1.4.0

This is annoying, but can be worked around with -hide-package. We could also deprecate mtl as part of the migration, encouraging people to move away from it as quickly as possible. After a bit it could be removed from the platform, which would mean that people would only end up with it on their systems if they install it or something that still depends on it.

So the proposal is that HP should contain mtl-2.0, monads-fd and transformers, but with mtl hidden. Could the HP do that?

...

(Unless we introduce virtual packages.)

What functionality would virtual packages have? Presumably in this instance they'd need to provide some mechanism for GHC to recognise that you get the same result by importing the modules from either source.

I was imagining something that would be implemented in Cabal, so you could say somewhere something like mtl >= 2 = transformers > 0.1.4.0, monads-fd >= 0.0.0.1 and Cabal would build packages with an unversioned dependency on mtl using the other two instead. That would still leave old versions of mtl needing hiding, though.

On Tuesday 17 November 2009 9:56:21 pm Antoine Latter wrote:

Every time this comes up I grow paranoid that there is some sort of general overhead to evaluating an expression of type "StateT s Identity a" vs "State s a".

So I finally benchmarked it using the example code listed in Control.Monad.State, and found no difference whatsoever.

Here's the source: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=12259#a12259

I guess parsec is the odd one out, where there is a difference. Or I was measuring something else back when I had parsec benchmarks set up.

At least in the State case, everything involved is a newtype, so: StateT s Identity a should be represented identically to: s -> Identity (a, s) = s -> (a, s) Which is exactly what State s a is. From there it's just up to the compiler to eliminate no-ops like: return :: a -> a -- return :: a -> Identity a return a = a which shouldn't be too arduous. Building up stacks of novel monads can introduce additional indirection over flattening them into a direct implementation (like StateT s (WriterT w ...) versus RWST r s w ...), but thankfully, Identity shouldn't introduce such overhead. -- Dan

On Wed, Nov 18, 2009 at 2:44 AM, Ganesh Sittampalam wrote:

On Tue, 17 Nov 2009, Edward Kmett wrote:

I guess the question is then, when should code start looking to changing

...

their dependencies over to monads-tf and monads-fd?

A cleanly demarked cut over would be useful to get us out of this limbo state that helps nobody.

Are you suggesting that we declare a date or on which people should make the switch? I think that might make some sense if we weren't already accidentally part way through it, but given that we are, I'd say the best option is to just do it asap once there is proper agreement.

Substantively, I agree -- assuming that the issues that keep monads-tf and monads-fd from being loaded into the same program are fixed, so that library writers don't have to go through all of this again almost immediately. -Edward Kmett

Ganesh

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Henning Thielemann wrote:

The question is, whether Iteratee needs functions of MTL that transformers does not provide? 'Transformers' is the more basic package, entirely Haskell 98, thus should be prefered. It is however sad, that Transformers cannot easily be used with GHCi in parallel with MTL installed. I was always against that ... Renaming Control.Monad.Trans and Control.Monad.Identity to something else would solve the conflict. I'm also not happy, that you have to choose between monads-fd and monads-tf. I think it would be better to be able to have both type class approaches.

Is there a way to tell GHCi ``Take Control.Monad.Trans from mtl package for this session'' or ``Use transformers this time'' without updating ghc-pkg config file (hide/expose)? If there is none, do you think inventing one would be a good idea? -- vvv

Valery V. Vorotyntsev wrote:

...

Is there a way to tell GHCi ``Take Control.Monad.Trans from mtl package for this session'' or ``Use transformers this time'' without updating ghc-pkg config file (hide/expose)?

Henning Thielemann wrote:

With 'ghc-pkg hide' and 'expose' you can set your general preference. With '-hide-package mtl' and '-package transformers' you can choose per invokation of GHCi.

``When you say import A.B.C, from what package does A.B.C come?'' I've found [*] a hackage wiki page devoted to this question: http://hackage.haskell.org/trac/ghc/wiki/GhcPackages#Theopenquestion [*] I just tried to add `-hide-package mtl' to OPTIONS_GHC pragma, with no success, and was googling for a clue. Prelude> :load "/home/vvv/job/cdr.mscp/Codec/Binary/MSCP.hs" /home/vvv/job/cdr.mscp/Codec/Binary/MSCP.hs:1:15-39: unknown flag in {-# OPTIONS #-} pragma: -hide-package /home/vvv/job/cdr.mscp/Codec/Binary/MSCP.hs:1:15-39: unknown flag in {-# OPTIONS #-} pragma: mtl > -- vvv

Jeremy Shaw wrote:

I don't think that works, but you can do: {-# LANGUAGE PackageImports #-} import "transformers" Control.Monad.Reader in GHC 6.10 and higher. I think you could even do:

{-# LANGUAGE PackageImports #-} import "transformers" Control.Monad.Reader import "mtl"                  Control.Monad.Writer

Yes, this works! Thanks, Jeremy. -- vvv