Hi, What are the relative status of transformers and mtl? Are we trying to deprecate mtl use in favour of transformers (+ appropriate dependencies like monads-fd)? I see that the initial version of the Haskell Platform is planning to use mtl because of its status in extralibs - but if transformers is the way forward, then perhaps this should be changed? Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
On Sun, 15 Mar 2009, Sittampalam, Ganesh wrote:
Hi,
What are the relative status of transformers and mtl? Are we trying to deprecate mtl use in favour of transformers (+ appropriate dependencies like monads-fd)?
I have actually done this step in all of my packages.
I see that the initial version of the Haskell Platform is planning to use mtl because of its status in extralibs - but if transformers is the way forward, then perhaps this should be changed?
I prefer transformers + monad-fd + monad-tf or whatever as the standard implementation over mtl.
Henning Thielemann wrote:
On Sun, 15 Mar 2009, Sittampalam, Ganesh wrote:
I see that the initial version of the Haskell Platform is planning to use mtl because of its status in extralibs - but if transformers is the way forward, then perhaps this should be changed?
I prefer transformers + monad-fd + monad-tf or whatever as the standard implementation over mtl.
Yes, so do I.
What are the relative status of transformers and mtl? Are we trying to deprecate mtl use in favour of transformers (+ appropriate dependencies like monads-fd)?
I have actually done this step in all of my packages.
I think this makes perfect sense where the monad transformer types are not externally visible. I'm just concerned about what to do with packages where the types are part of the interface - it would be best to coordinate this to some extent to avoid incompatibilities. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
Excerpts from Sittampalam, Ganesh's message of Mon Mar 16 08:48:34 UTC 2009:
Henning Thielemann wrote:
On Sun, 15 Mar 2009, Sittampalam, Ganesh wrote:
I see that the initial version of the Haskell Platform is planning to use mtl because of its status in extralibs - but if transformers is the way forward, then perhaps this should be changed?
I prefer transformers + monad-fd + monad-tf or whatever as the standard implementation over mtl.
Yes, so do I.
+1 too -- Nicolas Pouillard
2009/3/16 Nicolas Pouillard
Excerpts from Sittampalam, Ganesh's message of Mon Mar 16 08:48:34 UTC 2009:
Henning Thielemann wrote:
On Sun, 15 Mar 2009, Sittampalam, Ganesh wrote:
I see that the initial version of the Haskell Platform is planning to use mtl because of its status in extralibs - but if transformers is the way forward, then perhaps this should be changed?
I prefer transformers + monad-fd + monad-tf or whatever as the standard implementation over mtl.
Yes, so do I.
+1 too
Hi, What's the reason to prefer transformers over mtl ? Thanks, Thu
On Mon, Mar 16, 2009 at 08:48:34AM -0000, Sittampalam, Ganesh wrote:
I think this makes perfect sense where the monad transformer types are not externally visible. I'm just concerned about what to do with packages where the types are part of the interface - it would be best to coordinate this to some extent to avoid incompatibilities.
Hmm, there seem to be over a hundred such packages. The monads-fd and monads-tf packages use the same module names, which will create incompatibilities if both appear in interfaces. I'm not sure what to do there. transformers+monads-fd tries to mirror mtl, so maybe monads-tf has to move.
Ross Paterson wrote:
On Mon, Mar 16, 2009 at 08:48:34AM -0000, Sittampalam, Ganesh wrote:
I think this makes perfect sense where the monad transformer types are not externally visible. I'm just concerned about what to do with packages where the types are part of the interface - it would be best to coordinate this to some extent to avoid incompatibilities.
Hmm, there seem to be over a hundred such packages.
The monads-fd and monads-tf packages use the same module names, which will create incompatibilities if both appear in interfaces. I'm not sure what to do there. transformers+monads-fd tries to mirror mtl, so maybe monads-tf has to move.
That's an issue for the design of transformers that clearly needs to be fixed, but I was actually asking about if any focused mtl -> transformers transition is planned and how it will be managed, in terms of dealing with the non-interoperability between the types in each. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
On Mon, Mar 16, 2009 at 02:29:05PM -0000, Sittampalam, Ganesh wrote:
I was actually asking about if any focused mtl -> transformers transition is planned and how it will be managed, in terms of dealing with the non-interoperability between the types in each.
There is no transition plan; transformers is a recent arrival. I think it's an improvement, but we haven't had the discussion yet.
Ross Paterson wrote:
On Mon, Mar 16, 2009 at 02:29:05PM -0000, Sittampalam, Ganesh wrote:
I was actually asking about if any focused mtl -> transformers transition is planned and how it will be managed, in terms of dealing with the non-interoperability between the types in each.
There is no transition plan; transformers is a recent arrival. I think it's an improvement, but we haven't had the discussion yet.
From my point of view, I'm trying to decide what I should be exposing in interfaces right now (in particular for the rmonad package on hackage). It seems like the answer is mtl, but if there will be a transition to
Would now be a good time to start it, or do we need more experience of transformers? transformers in the relatively near future, it would be easier to be a front-runner, since I don't think the package is very widely used. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
Hello,
I would like to point out that another option is monadLib, which has
been around for a while. It was never marketed very much so it never
become particularly popular but it works pretty well (my colleagues
and I use it on a number of projects).
-Iavor
On Thu, Mar 19, 2009 at 10:14 AM, Sittampalam, Ganesh
Ross Paterson wrote:
On Mon, Mar 16, 2009 at 02:29:05PM -0000, Sittampalam, Ganesh wrote:
I was actually asking about if any focused mtl -> transformers transition is planned and how it will be managed, in terms of dealing with the non-interoperability between the types in each.
There is no transition plan; transformers is a recent arrival. I think it's an improvement, but we haven't had the discussion yet.
Would now be a good time to start it, or do we need more experience of transformers?
From my point of view, I'm trying to decide what I should be exposing in interfaces right now (in particular for the rmonad package on hackage). It seems like the answer is mtl, but if there will be a transition to transformers in the relatively near future, it would be easier to be a front-runner, since I don't think the package is very widely used.
Ganesh
=============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On Thu, 2009-03-19 at 16:39 -0700, Iavor Diatchki wrote:
Hello,
I would like to point out that another option is monadLib, which has been around for a while. It was never marketed very much so it never become particularly popular but it works pretty well (my colleagues and I use it on a number of projects).
Can you market it a bit more please :-). Tell us what the advantages of it are over mtl. I know you've told me in person but I'm sure I've forgotten the details :-). Duncan
Duncan Coutts wrote:
On Thu, 2009-03-19 at 16:39 -0700, Iavor Diatchki wrote:
Hello,
I would like to point out that another option is monadLib, which has been around for a while. It was never marketed very much so it never become particularly popular but it works pretty well (my colleagues and I use it on a number of projects).
Can you market it a bit more please :-). Tell us what the advantages of it are over mtl.
Also, is there any scope for eliminating duplication by depending on transformers for the common datatypes etc? I'm sure monadLib has its own distinctive features but for those parts that are the same I feel we really should be trying to avoid incompatibilities. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
Hello,
There are a number of reasons why I prefer monadLib over mtl. None of
them are huge issues, which is why I never bothered to "spread the
word" :) Anyway, here are some of the differences off the top of my
head (not in order of importance)
- Nicer packaging: monadLib has 1 module (or 3 depending on how you
look at it), mtl has 21
- Conceptually simpler types: monadLib provides two base mondas (Id
and Lift) and one transformer per effect. By combining these
programmers can construct all the monads that they need. MTL also
provides these, but in addition it provides other types which I think
are unnecessary and make things look more complex then they are (RWS
monad, strict/lazy version of monads, predefined base monads)
- Correct back-tracking transformer, called ChoiceT. At least in
the past MTL's ListT worked only for commutative monads, I am not sure
if that was fixed.
- In monadLib one can throw arbitrary exceptions (there is no need
for an Error class). I never understood what's the point of the class
Error.
- MonadLib has a more general "MonadIO" class, called "InBase". It
allows executing computations in the base monad of a tower of monads,
even when the base monad is not IO.
- MonadLib organizes the different effect operators in a slightly
different hierarchy of classes which, in principle, allows for more
fine-grained control over effect (e.g., you could have a type that
ensure that a computation will only raise exceptions but not handle
them).
I think that's probably about it. As I said, none of these are huge
issues, indeed monadLib was originally designed to replace mtl, so
they are fairly similar in style and appearance. This never happened
because it was in the early days of Haskell libraries and we had no
good process for doing things like that. Also, I am not that
interested in marketing :-)
On Ganesh's question if monadLib could be written in terms of
"transformers": no, because transformers uses a different list
transformer. Furthermore, I would not be inclined to do it because it
would add an extra unnecessary dependency to monadLib, and also I
think that transformers has some of the same problems as mtl (17
modules, some of which define things like RWS).
Apologies if was too critical of MTL, I think that it is a fine
library which is clearly used by many people. I just think that
monadLib is a bit nicer.
-Iavor
On Fri, Mar 20, 2009 at 1:16 AM, Sittampalam, Ganesh
Duncan Coutts wrote:
On Thu, 2009-03-19 at 16:39 -0700, Iavor Diatchki wrote:
Hello,
I would like to point out that another option is monadLib, which has been around for a while. It was never marketed very much so it never become particularly popular but it works pretty well (my colleagues and I use it on a number of projects).
Can you market it a bit more please :-). Tell us what the advantages of it are over mtl.
Also, is there any scope for eliminating duplication by depending on transformers for the common datatypes etc? I'm sure monadLib has its own distinctive features but for those parts that are the same I feel we really should be trying to avoid incompatibilities.
Cheers,
Ganesh
=============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
Iavor Diatchki wrote:
On Ganesh's question if monadLib could be written in terms of "transformers": no, because transformers uses a different list transformer.
I was only suggesting that the common types should be shared - obviously if the list transformer is different then it shouldn't be.
Furthermore, I would not be inclined to do it because it would add an extra unnecessary dependency to monadLib, and also I think that transformers has some of the same problems as mtl (17 modules, some of which define things like RWS).
Fair enough. On the other hand, the benefit would be that libraries based on monadLib would interoperate better with libraries based on transformers. monadLib itself would only re-export the things from transformers that form part of the monadLib design, so the extra modules wouldn't pollute monadLib itself. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
On Sat, 21 Mar 2009, Iavor Diatchki wrote:
Hello, There are a number of reasons why I prefer monadLib over mtl. None of them are huge issues, which is why I never bothered to "spread the word" :) Anyway, here are some of the differences off the top of my head (not in order of importance) - Nicer packaging: monadLib has 1 module (or 3 depending on how you look at it), mtl has 21
I think modules are there to be used. So, at least for me, it's a good thing, that MTL uses separate modules for different concerns. My critics is more that MTL uses identifiers that are designed as if everything could be in one module. E.g. State and StateT should be better State.Base and State.Transformer.
- Conceptually simpler types: monadLib provides two base mondas (Id and Lift) and one transformer per effect.
I find this idea very elegant. Now in transformers the base monads like State, Reader, Writer are replaced by type synonyms that equal StateT Identity and so on. This way, 'put' and 'get' do not need to be type class methods, at least when accessing the top monad in a stack. However I still don't understand, why monadLib achieves the distinction between lazy and strict in the base monad, whereas transformers has still distinct lazy and strict transformers.
- In monadLib one can throw arbitrary exceptions (there is no need for an Error class). I never understood what's the point of the class Error.
Error class was needed to implement the exception throwing as 'fail'. It's as broken as 'fail' belonging to Monad class.
On Thu, Mar 19, 2009 at 05:14:22PM -0000, Sittampalam, Ganesh wrote:
Would now be a good time to start it, or do we need more experience of transformers?
Perhaps sooner would be better that later, as there are so many packages involved (~350, of which over 100 include mtl types and classes in their interfaces). I think it's necessary to split off the multi-parameter type classes from the rest, so that the transformers can be used either on their own or with type families, and clients of the different configurations can be used together. A transition will be disruptive, as only 30 of the packages have upper bounds on their mtl dependencies, but I think we can reduce the disruption. The combination transformers + monads-fd is close to a compatible replacement for mtl at the source level, except that State, Writer, etc are now type synonyms, which will break some code. Of course the package names are also different. We can't just rename monads-fd as mtl-2.0, because Control.Monad.Identity and Control.Monad.Trans are in the transformers package. But we could make a compatibility version of mtl along the lines of base3-compat. (And we need to rename the modules in monads-tf.)
On Fri, Mar 20, 2009 at 9:47 AM, Ross Paterson
On Thu, Mar 19, 2009 at 05:14:22PM -0000, Sittampalam, Ganesh wrote:
Would now be a good time to start it, or do we need more experience of transformers?
Perhaps sooner would be better that later, as there are so many packages involved (~350, of which over 100 include mtl types and classes in their interfaces).
I think it's necessary to split off the multi-parameter type classes from the rest, so that the transformers can be used either on their own or with type families, and clients of the different configurations can be used together.
A transition will be disruptive, as only 30 of the packages have upper bounds on their mtl dependencies, but I think we can reduce the disruption.
The combination transformers + monads-fd is close to a compatible replacement for mtl at the source level, except that State, Writer, etc are now type synonyms, which will break some code. Of course the package names are also different. We can't just rename monads-fd as mtl-2.0, because Control.Monad.Identity and Control.Monad.Trans are in the transformers package. But we could make a compatibility version of mtl along the lines of base3-compat. (And we need to rename the modules in monads-tf.)
The other thing to think about is with regards to FunctionalDependencies vs. TypeFamilies. If we have two different libraries, one providing a TF interface and one providing an FD interface, we will naturally have some developers using one of them and others using another, based on personal preference. This is all well and good for application code, but it gets messy for libraries. If package foo declares some datatypes and makes them instances of monads-tf classes, and package bar declares some datatypes and makes them instances of monads-fd classes, then it will be hard for an application or another library to use both foo and bar in conjunction with each other because they will not be using the same monad classes. Would it be best practice for libraries to depend on *both* packages and declare instances for both classes? Alex
Ross Paterson wrote:
The combination transformers + monads-fd is close to a compatible replacement for mtl at the source level, except that State, Writer, etc are now type synonyms, which will break some code. Of course the package names are also different. We can't just rename monads-fd as mtl-2.0, because Control.Monad.Identity and Control.Monad.Trans are in the transformers package. But we could make a compatibility version of mtl along the lines of base3-compat. (And we need to rename the modules in monads-tf.)
The compatibility layer could continue to export the old separate types for State, Writer, etc, couldn't it? Are there any problems with adding transformers and monads-fd to extralibs pending the Haskell Platform being ready? Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
On Sat, Mar 21, 2009 at 04:19:05PM -0000, Sittampalam, Ganesh wrote:
Ross Paterson wrote:
The combination transformers + monads-fd is close to a compatible replacement for mtl at the source level, except that State, Writer, etc are now type synonyms, which will break some code. Of course the package names are also different. We can't just rename monads-fd as mtl-2.0, because Control.Monad.Identity and Control.Monad.Trans are in the transformers package. But we could make a compatibility version of mtl along the lines of base3-compat. (And we need to rename the modules in monads-tf.)
The compatibility layer could continue to export the old separate types for State, Writer, etc, couldn't it?
It could, though then they'd be different types than the transformer versions. There's a trade-off.
Are there any problems with adding transformers and monads-fd to extralibs pending the Haskell Platform being ready?
That should work, but that wouldn't be till September/October. I'm not sure what the HP schedule is. Another possibility is to upload mtl-2.0 as a compatibility layer.
Ross Paterson wrote:
On Sat, Mar 21, 2009 at 04:19:05PM -0000, Sittampalam, Ganesh wrote:
The compatibility layer could continue to export the old separate types for State, Writer, etc, couldn't it?
It could, though then they'd be different types than the transformer versions. There's a trade-off.
Yeah. I guess we could see how much stuff breaks first. It'll only be the things that rely on it being a real type *and* don't have an upper bound on their mtl deps.
Are there any problems with adding transformers and monads-fd to extralibs pending the Haskell Platform being ready?
That should work, but that wouldn't be till September/October. I'm not sure what the HP schedule is. Another possibility is to upload mtl-2.0 as a compatibility layer.
I don't really understand the relationship between extralibs and hackage - I was assuming that changes to mtl had to go into extralibs to become official. Uploading to hackage as well would obviously help the migration happen sooner. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
On Sat, 21 Mar 2009, Ross Paterson wrote:
Are there any problems with adding transformers and monads-fd to extralibs pending the Haskell Platform being ready?
That should work, but that wouldn't be till September/October. I'm not sure what the HP schedule is. Another possibility is to upload mtl-2.0 as a compatibility layer.
We already found out, that compatibility to mtl cannot be achieved with a package based on transformers. So why shall we rewrite mtl in terms of transformers+monad-fd at all? I welcome advertising transformers+monad-fd, but I don't see the benefits of breaking mtl.
Henning Thielemann wrote:
On Sat, 21 Mar 2009, Ross Paterson wrote:
Are there any problems with adding transformers and monads-fd to extralibs pending the Haskell Platform being ready?
That should work, but that wouldn't be till September/October. I'm not sure what the HP schedule is. Another possibility is to upload mtl-2.0 as a compatibility layer.
We already found out, that compatibility to mtl cannot be achieved with a package based on transformers.
Can you elaborate on this or point me at the past discussion? I can't find anything from a quick look through the archives, apart from the issue that haddock will go wrong if mtl just re-exports things from transformers.
So why shall we rewrite mtl in terms of transformers+monad-fd at all? I welcome advertising transformers+transformers+monad-fd, but I don't see the benefits of breaking mtl.
If we don't make mtl and transformers use the same types, we will have some packages with interfaces that use one and some with interfaces that use the other for quite a long time to come. Also, if mtl stays in extralibs/the Haskell Platform but remains incompatible with transformers, then it will be in some way blessed which will hinder a move to transformers, but if we suddenly remove it then a lot of people will suddenly have to go and find it from hackage when previously they got it with GHC. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
On Sat, 21 Mar 2009, Sittampalam, Ganesh wrote:
Henning Thielemann wrote:
We already found out, that compatibility to mtl cannot be achieved with a package based on transformers.
Can you elaborate on this or point me at the past discussion? I can't find anything from a quick look through the archives, apart from the issue that haddock will go wrong if mtl just re-exports things from transformers.
In mtl State is a type with constructor State, whereas in transformers State is a type synonym with no custom constructor. So, if mtl uses the State type synonym from transformers it cannot be compatible with old mtl versions.
So why shall we rewrite mtl in terms of transformers+monad-fd at all? I welcome advertising transformers+transformers+monad-fd, but I don't see the benefits of breaking mtl.
If we don't make mtl and transformers use the same types, we will have some packages with interfaces that use one and some with interfaces that use the other for quite a long time to come.
That's why I think that we should extensively tell people to use 'transformers' instead of 'mtl'.
Also, if mtl stays in extralibs/the Haskell Platform but remains incompatible with transformers, then it will be in some way blessed which will hinder a move to transformers, but if we suddenly remove it then a lot of people will suddenly have to go and find it from hackage when previously they got it with GHC.
I don't like people forcing this way, as I for myself could spend my whole life keeping my Haskell libraries up-to-date without adding any feature or fixing any bug. I think, mtl should be removed from extralibs, but it should not be upgraded in an incompatible way. We would break packages, not more. I think, incompatibility between libraries based on mtl and those based on transformers is enough hassle to make developers think about a move to 'transformers'. I remember this was your motivation, too, right?
Henning Thielemann wrote:
In mtl State is a type with constructor State, whereas in transformers State is a type synonym with no custom constructor. So, if mtl uses the State type synonym from transformers it cannot be compatible with old mtl versions.
Oh right, we already discussed that in this thread. 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. We can test hackage (which isn't the entire world, but is a lot of it) to decide which to do.
I don't like people forcing this way, as I for myself could spend my whole life keeping my Haskell libraries up-to-date without adding any feature or fixing any bug. I think, mtl should be removed from extralibs, but it should not be upgraded in an incompatible way. We would break packages, not more.
I think that after the relative chaos of the base 2 -> base 3 upgrade, the general policy nowadays is to minimise disruption when changing things. Completely removing a package from extralibs seems quite disruptive to me.
I think, incompatibility between libraries based on mtl and those based on transformers is enough hassle to make developers think about a move to 'transformers'. I remember this was your motivation, too, right?
I'm not convinced that individual developers would make this move very quickly, especially since the disruption wouldn't directly manifest in their packages, but only in things that use their packages. Cheers, Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
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.
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, and then a variant with the transformers compatibility. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
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. 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, Mar 24, 2009 at 4:42 PM, Sittampalam, Ganesh
Sittampalam, Ganesh wrote:
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.
As long as we're on the topic of class constraints, is there any reason that the Monad instance for ContT m has a class constraint on the type of 'm'? I'm pretty sure we can lose it, as well as the similar class constraint on the instance of MonadCont. That's one of the most important things about the (ContT m) monad to me - it's a monad transformer that doesn't hit the class dictionary of what it's wrapping around. Antoine
On Tue, Mar 24, 2009 at 08:30:57PM -0500, Antoine Latter wrote:
As long as we're on the topic of class constraints, is there any reason that the Monad instance for ContT m has a class constraint on the type of 'm'? I'm pretty sure we can lose it, as well as the similar class constraint on the instance of MonadCont.
I've now removed these constraints from the development versions of transformers, monads-fd and monads-tf.
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 ===============================================================================
On 2009 Mar 22, at 2:31, Sittampalam, Ganesh wrote:
Henning Thielemann wrote:
I don't like people forcing this way, as I for myself could spend my whole life keeping my Haskell libraries up-to-date without adding any feature or fixing any bug. I think, mtl should be removed from extralibs, but it should not be upgraded in an incompatible way. We would break packages, not more.
I think that after the relative chaos of the base 2 -> base 3 upgrade, the general policy nowadays is to minimise disruption when changing things. Completely removing a package from extralibs seems quite disruptive to me.
But the ultimate objective is for all of extralibs to go away in favor of the Haskell Platform, isn't it? That will assuredly be disruptive, but the current situation is arguably even more disruptive because random packages are forced to update when ghc development leads to an update. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
Brandon S. Allbery KF8NH wrote:
On 2009 Mar 22, at 2:31, Sittampalam, Ganesh wrote:
Henning Thielemann wrote:
I don't like people forcing this way, as I for myself could spend my whole life keeping my Haskell libraries up-to-date without adding any feature or fixing any bug. I think, mtl should be removed from extralibs, but it should not be upgraded in an incompatible way. We would break packages, not more.
I think that after the relative chaos of the base 2 -> base 3 upgrade, the general policy nowadays is to minimise disruption when changing things. Completely removing a package from extralibs seems quite disruptive to me.
But the ultimate objective is for all of extralibs to go away in favor of the Haskell Platform, isn't it? That will assuredly be disruptive,
At that point the recommended installation route will be of the Platform, not of "just GHC". The first Platform release will be precisely extralibs + cabal-install + deps, so there won't be any disruption assuming that people follow that recommendation.
but the current situation is arguably even more disruptive because random packages are forced to update when ghc development leads to an update.
Agreed. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
On Sun, 2009-03-22 at 21:23 +0000, Sittampalam, Ganesh wrote:
But the ultimate objective is for all of extralibs to go away in favor of the Haskell Platform, isn't it? That will assuredly be disruptive,
At that point the recommended installation route will be of the Platform, not of "just GHC". The first Platform release will be precisely extralibs + cabal-install + deps, so there won't be any disruption assuming that people follow that recommendation.
Right. Initially the platform will not add disruption. In the future, if the consensus is for breaking changes in library organisation then the platform provides the mechanism to manage that disruption in a way that is less painful (ie by coordinating the changes). That doesn't mean it's ok to make whatever changes you like all the time, but it should help minimise the pain with any changes we deem necessary. Duncan
participants (10)
-
Alexander Dunlap -
Antoine Latter -
Brandon S. Allbery KF8NH -
Duncan Coutts -
Henning Thielemann -
Iavor Diatchki -
minh thu -
Nicolas Pouillard -
Ross Paterson -
Sittampalam, Ganesh