On Thu, Mar 25, 2010 at 08:13:37AM +1100, Erik de Castro Lopo wrote:

Ross Paterson wrote:

...

I propose to rename some of the modules in the transformers package so that it no longer conflicts with the mtl package:

I thought the plan was to replace mtl with transformers.

If that was the plan wouldn't it be better to actually kill off mtl so it doesn't hang around for years to come?

The aim is still to split the concrete monad transformers from the multi-parameter classes with functional dependencies. Last year we proposed replacing mtl with two packages representing the split (transformers and monads-fd) in a big bang, but there was concern about the degree of change. This proposal allows transformers to co-exist with mtl, but also makes monads-fd (depending on transformers) closer to being a plugin replacement for mtl (but still not completely one). I hope to propose such a replacement in the future.

On Thu, Mar 25, 2010 at 11:04 AM, Ross Paterson wrote:

On Thu, Mar 25, 2010 at 10:46:25AM +0100, Bas van Dijk wrote:

...

BTW is there a plan and roadmap documented somewhere on the future of mtl?

No, but my plan is to allow transformers to spread and later propose the revised monads-fd as version 2.0 of mtl.

Maybe we can push the spreading of transformers a bit by putting the following note in the mtl description: "We advise you to use the transformers package if you only need to use the concrete monad transformers (types) and don't need to use the monad transformer classes." ...or something similar. And releasing this as mtl-1.1.0.3. regards, Bas

Ross Paterson wrote:

On Thu, Mar 25, 2010 at 08:58:05AM -0400, Mario Blažević wrote:

...

Ross Paterson wrote:

...

I propose to rename some of the modules in the transformers package so that it no longer conflicts with the mtl package:

Control.Monad.Identity renamed as Data.Functor.Identity Control.Monad.Trans split between Control.Monad.Trans.Class and Control.IO.Trans.Class I assume that Data.Functor.Identity would still export a Monad instance of Identity? Or would that be moved to monad-fd?

Yes, the instance will stay with the data definition in Data.Functor.Identity, and the whole module will be re-exported by Control.Monad.Identity in monads-fd.

+1 in that case

On Fri, Mar 26, 2010 at 05:24:18AM -0700, Nicolas Pouillard wrote:

Could we have functors products, sums, fixpoints as well? It would really avoid to redefine them each time.

Do you mean data Product f g a = Product (f a) (g a) with Functor, Foldable, Traversable and Applicative instances? Not sure if the other two count as transformers.

On Sat, Mar 27, 2010 at 01:05:45AM -0400, wren ng thornton wrote:

Why wouldn't

data Coproduct f g a = FLeft (f a) | FRight (g a)

with appropriate instances count as a transformer?

It would, but the instances would just be Functor, Foldable and Traversable.

While I personally prefer the (:*:) and (:+:) notation, both require an additional extension, TypeOperators, and to Ross's point (:+:) fails to be an Applicative/Monad transformers, so the scope of the package starts to stretch there. That said, there are always ideal monad coproducts, but then you need the notion of ideal monads. ;) data Ideal m a = Return a | Ideal (m a) data Mutual m n a = Mutual (m (Mutual n m a)) data (m :+: n) a = Coproduct { runCoproduct :: Either (m a) (n a) } type IdealCoproduct m n = Ideal (Mutual m n :+: Mutual n m) given a definition for class MonadIdeal m where idealize :: m (Ideal m a) -> m a which describes a monad, that has a separate return. You can define instance MonadIdeal m => Monad (Ideal m) and then you can define an 'ideal monad coproduct' of any two ideal monads from there. This covers, Maybe, Either, Identity, and a bunch of others. wherever the 'Return' constructor can be cleanly separated from the rest of the monad. However, this drifts out of library/platform territory and into esoterica. -Edward Kmett On Mon, Mar 29, 2010 at 5:42 AM, Nicolas Pouillard < nicolas.pouillard@gmail.com> wrote:

On Fri, 26 Mar 2010 19:28:18 +0000, Ross Paterson wrote:

...

On Fri, Mar 26, 2010 at 05:24:18AM -0700, Nicolas Pouillard wrote:

...

Could we have functors products, sums, fixpoints as well? It would really avoid to redefine them each time.

Do you mean

data Product f g a = Product (f a) (g a)

Yes, I was thinking of using :*: instead of Product:

data (:*:) f g a = (:*:) (f a) (g a)

...

with Functor, Foldable, Traversable and Applicative instances?

Yes.

...

Not sure if the other two count as transformers.

Why not:

data (:+:) f g a = Inl (f a) | Inr (g a)

And sure, no applicative nor monad instance for this one.

And Fix like in category-extras:

http://hackage.haskell.org/packages/archive/category-extras/0.53.5/doc/html/...

Best regards,

-- Nicolas Pouillard http://nicolaspouillard.fr _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

On Mon, Mar 29, 2010 at 09:15:09AM -0400, Mario Blažević wrote:

I'd expect the appropriate functor product rather be something like

data NestedProduct f g a = NestedProduct (f (g a))

That's already present as Compose.