Removing mtl from the Haskell Platform
I wanted to pass this idea around the cafe to get some thoughts before submitting a trac on this topic. I'd like to see the mtl removed from the Haskell Platform. The mtl was a tremendous step forward when it was developed. However, we have learned a few things about monad transformers since the development of the mtl, and it is time that we moved forward. There are at least 3 significant problem with the mtl. 1) `pass' should not be a member functions of the MonadWriter class. It is my understanding that there is no `MonadWriter w m => MonadWriter w (ContT s m)' instance because the `pass' function cannot be implemented. I'm also highly suspicious of some other methods too (I'm looking at you `local'). 2) The `StateT s (Cont r a)' instance of callCC is wrong. The paper on modular monad transformers http://www.cs.nott.ac.uk/~mjj/pubs/mmt/mmt.pdf describes why this is wrong. 3) I am told by many people that the order of the state and value pair in `State' is backwards. Actually, I'm not entirely sure what the issue is here, but I trust the people who say this. I think that use of the mtl should be deprecated so that we move on to improved monad transformer libraries. Having the mtl in the Haskell Platform does the opposite by further entrenching its use, possibly to the point where we may not be able to get rid of it for years. If I had to recommend a replace library, I would pick monadLib. However, there are other libraries, such as the mmtl and transformers and it's related packages that I haven't looked at, and may also make fine replacements for the mtl. -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''
roconnor@theorem.ca wrote:
I wanted to pass this idea around the cafe to get some thoughts before submitting a trac on this topic.
I'd like to see the mtl removed from the Haskell Platform.
The mtl was a tremendous step forward when it was developed. However, we have learned a few things about monad transformers since the development of the mtl, and it is time that we moved forward.
I would welcome a newer cleaner library to replace mtl. One caveat, in terms of the HP is that I'd like to see one clear alternative be blessed, instead of listing the alternatives. I think a big part of the reason many people have stuck with mtl is that they lack sufficient knowledge to be able to look at all the options and know which is the best and why, so they choose the one that is familiar. This is similar to the Parsec problem. At the time it was introduced it was a major step forward, but these days there are a number of issues people consistently complain about. There's a large set of parser combinator libraries out there, but no one of them is clearly superior so people stick with what is familiar.
3) I am told by many people that the order of the state and value pair in `State' is backwards. Actually, I'm not entirely sure what the issue is here, but I trust the people who say this.
Lacking type-level functions like flip, we can define the Functor ((,) s) easier than the reverse. This pretties type signatures up significantly when we start composing things[1] and doing other type-level programming. This is also the ordering used in dependently typed languages (replacing (->) with \Pi and (,) with \Sigma). Et cetera. The current order makes the definition of (>>=) appear very marginally prettier, but it makes type signatures much uglier everywhere it's used. [1] e.g. State s = Reader s . Writer s = (->) s . (,) s = /\a. s->(s,a) -- Live well, ~wren
Not of the same gravity as mtl, but I was a bit surprised to see that
PackedString was included, in spite of it being marked as deprecated
on Hackage.
Presumably, this is because some other library depends on this, but I
think platform-blessing a deprecated library is a strange thing to
do. If the functionality cannot be replaced in the dependent, could
it be an option to simply integrate the PS functionality? Or should
it be de-deprecated?
wren ng thornton
[..] in terms of the HP is that I'd like to see one clear alternative be > blessed, instead of listing the alternatives.
FWIW, I strongly agree with this. -k -- If I haven't seen further, it is by standing in the footprints of giants
On Wed, 2009-05-13 at 10:24 +0200, Ketil Malde wrote:
Not of the same gravity as mtl, but I was a bit surprised to see that PackedString was included, in spite of it being marked as deprecated on Hackage.
TemplateHaskell still uses it. There was not a lot we could do for the first release. Similarly for old-time.
Presumably, this is because some other library depends on this, but I think platform-blessing a deprecated library is a strange thing to do. If the functionality cannot be replaced in the dependent, could it be an option to simply integrate the PS functionality?
That's not possible as it is part of the interface.
Or should it be de-deprecated?
I think it should remain deprecated and we should work on the replacement so that TH can switch its dependency. Duncan
Hello Duncan, Wednesday, May 13, 2009, 3:33:13 PM, you wrote:
I think it should remain deprecated and we should work on the replacement so that TH can switch its dependency.
TH isn't high-performance package and i think that it should just switch to use of String -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Wed, 13 May 2009 15:37:52 +0400
Bulat Ziganshin
Hello Duncan,
Wednesday, May 13, 2009, 3:33:13 PM, you wrote:
I think it should remain deprecated and we should work on the replacement so that TH can switch its dependency.
TH isn't high-performance package and i think that it should just switch to use of String
I don't agree. TH can sometimes slow down a build considerably. I don't want to see it getting even slower. -- Robin
Hello Robin, Wednesday, May 13, 2009, 3:45:57 PM, you wrote:
TH isn't high-performance package and i think that it should just switch to use of String
I don't agree. TH can sometimes slow down a build considerably. I don't want to see it getting even slower.
i think GHC compile times is the reason rather than execution of TH scripts -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, May 13, 2009 at 7:45 AM, Robin Green wrote:
I don't agree. TH can sometimes slow down a build considerably. I don't want to see it getting even slower.
I once switched TH to Strings. All the uses are trivial, and the encoded strings so small I found myself wondering whether bytestring/packedstring might not be slower than regular string. Certainly, I didn't notice any significant slowdown. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkoKv/AACgkQvpDo5Pfl1oLNKgCdEKH0nT/6f3lni7QtjUr4Rfwv NAAAn0J+ZBgwYchGVDTbfnhxhuS5dvep =KtIG -----END PGP SIGNATURE-----
gwern0:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Wed, May 13, 2009 at 7:45 AM, Robin Green wrote:
I don't agree. TH can sometimes slow down a build considerably. I don't want to see it getting even slower.
I once switched TH to Strings. All the uses are trivial, and the encoded strings so small I found myself wondering whether bytestring/packedstring might not be slower than regular string.
Certainly, I didn't notice any significant slowdown.
Do you have a patch?
On Wed, May 13, 2009 at 6:31 PM, Don Stewart
Do you have a patch?
No. This was a while ago, and the changes really are trivial. I thought about submitting it, but it seemed to me that the change could only be useful when people upgrade their entire compiler/library infrastructure - link errors otherwise - and I wasn't sure it was worth paddling upstream libraries@. -- gwern
On Wed, 2009-05-13 at 15:37 +0400, Bulat Ziganshin wrote:
Hello Duncan,
Wednesday, May 13, 2009, 3:33:13 PM, you wrote:
I think it should remain deprecated and we should work on the replacement so that TH can switch its dependency.
TH isn't high-performance package and i think that it should just switch to use of String
That's a reasonable proposal for the next major release of the platform. Please do propose it on the libraries list and see if we can get a consensus. Duncan
On 13/05/2009 13:07, Duncan Coutts wrote:
On Wed, 2009-05-13 at 15:37 +0400, Bulat Ziganshin wrote:
Hello Duncan,
Wednesday, May 13, 2009, 3:33:13 PM, you wrote:
I think it should remain deprecated and we should work on the replacement so that TH can switch its dependency. TH isn't high-performance package and i think that it should just switch to use of String
That's a reasonable proposal for the next major release of the platform. Please do propose it on the libraries list and see if we can get a consensus.
I'll do the proposal - I've just made the change locally, I'll validate and then make a patch for comments. Cheers, Simon
ketil:
Not of the same gravity as mtl, but I was a bit surprised to see that PackedString was included, in spite of it being marked as deprecated on Hackage.
Ketil, I would encourage you to open a ticket on the platform wiki summarising the state of the packedstring issue. -- Don
roconnor@theorem.ca wrote:
I think that use of the mtl should be deprecated so that we move on to improved monad transformer libraries. Having the mtl in the Haskell Platform does the opposite by further entrenching its use, possibly to the point where we may not be able to get rid of it for years.
If I had to recommend a replace library, I would pick monadLib. However, there are other libraries, such as the mmtl and transformers and it's related packages that I haven't looked at, and may also make fine replacements for the mtl.
We've discussed replacing it with transformers+monads-fd+an mtl compatiblity layer on libraries@. Ross and I plan to propose doing this for the second release of the platform - it's not fair to disrupt the first release at this stage. transformers+monads-fd is quite a small evolution over mtl - it factors out the fundeps into a separate package, tightens up some of the class constraints, and makes State = StateT Identity etc rather than a separate type. Even this breaks a few packages, but doing anything more substantial would be quite disruptive. That's not to say that we shouldn't do it, though. I guess the libraries@ list will continue to be the place that such decisions get made, but I think it's a bit up in the air at the moment. Cheers, 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:
We've discussed replacing it with transformers+monads-fd+an mtl compatiblity layer on libraries@. Ross and I plan to propose doing this for the second release of the platform - it's not fair to disrupt the first release at this stage.
transformers+monads-fd is quite a small evolution over mtl - it factors out the fundeps into a separate package, tightens up some of the class constraints, and makes State = StateT Identity etc rather than a separate type. Even this breaks a few packages, but doing anything more substantial would be quite disruptive. That's not to say that we shouldn't do it, though.
For those of us wishing to target applications to the Haskell platform (e.g. our software works on Haskell Platform 2009.2, 2009.8, etc) will there be an easy way to determine which Haskell platform is currently installed so that we can accommodate any such incompatible changes? E.g. if Haskell platform = 2009.2 then use libraries mtl, parsec and #define HP_VERSION 200902, if Haskell platform = 2009.8 then use libraries transformers+monads-fd, parsec-compatibility, and #define HP_VERSION 200908. Or am I looking at things the wrong way, and we should instead just use autoconf-like tests for individual libraries, regardless of the platform (if they have mtl, use mtl and #define USE_MTL, otherwise try transformers+monads-fd, otherwise error)? Thanks, Neil.
On Wed, 2009-05-13 at 12:01 +0100, Neil Brown wrote:
Sittampalam, Ganesh wrote:
We've discussed replacing it with transformers+monads-fd+an mtl compatiblity layer on libraries@. Ross and I plan to propose doing this for the second release of the platform - it's not fair to disrupt the first release at this stage.
transformers+monads-fd is quite a small evolution over mtl - it factors out the fundeps into a separate package, tightens up some of the class constraints, and makes State = StateT Identity etc rather than a separate type. Even this breaks a few packages, but doing anything more substantial would be quite disruptive. That's not to say that we shouldn't do it, though.
For those of us wishing to target applications to the Haskell platform (e.g. our software works on Haskell Platform 2009.2, 2009.8, etc) will there be an easy way to determine which Haskell platform is currently installed so that we can accommodate any such incompatible changes? E.g. if Haskell platform = 2009.2 then use libraries mtl, parsec and #define HP_VERSION 200902, if Haskell platform = 2009.8 then use libraries transformers+monads-fd, parsec-compatibility, and #define HP_VERSION 200908.
There are already cpp macros to enable to determine if your package is being compiled using one library or another and to do conditional compilation on the version. There is no additional mechanism planned for the platform as a whole (because there is nothing to enforce that an end user picks a set of dependencies that is consistent with a platform release). Duncan
On Wed, May 13, 2009 at 08:04:52AM +0100, Sittampalam, Ganesh wrote:
We've discussed replacing it with transformers+monads-fd+an mtl compatiblity layer on libraries@. Ross and I plan to propose doing this for the second release of the platform - it's not fair to disrupt the first release at this stage.
transformers+monads-fd is quite a small evolution over mtl - it factors out the fundeps into a separate package, tightens up some of the class constraints, and makes State = StateT Identity etc rather than a separate type. Even this breaks a few packages, but doing anything more substantial would be quite disruptive. That's not to say that we shouldn't do it, though.
Indeed it is a conservative step, but splitting the transformers from the classes makes it easier to experiment with replacements for the classes while retaining a degree of interoperability. Of the issues listed, 1) and 2) are in the type class package (e.g. transformers exports functions for both liftings of callCC). I'm not sure what is meant by 3).
Nothing controversial said here... I'm just agreeing with Russel.
On Tue, May 12, 2009 at 4:03 PM,
I wanted to pass this idea around the cafe to get some thoughts before submitting a trac on this topic.
I'd like to see the mtl removed from the Haskell Platform.
The mtl was a tremendous step forward when it was developed. However, we have learned a few things about monad transformers since the development of the mtl, and it is time that we moved forward.
There are at least 3 significant problem with the mtl.
1) `pass' should not be a member functions of the MonadWriter class. It is my understanding that there is no `MonadWriter w m => MonadWriter w (ContT s m)' instance because the `pass' function cannot be implemented. I'm also highly suspicious of some other methods too (I'm looking at you `local').
2) The `StateT s (Cont r a)' instance of callCC is wrong. The paper on modular monad transformers http://www.cs.nott.ac.uk/~mjj/pubs/mmt/mmt.pdf describes why this is wrong.
3) I am told by many people that the order of the state and value pair in `State' is backwards. Actually, I'm not entirely sure what the issue is here, but I trust the people who say this.
I think that use of the mtl should be deprecated so that we move on to improved monad transformer libraries. Having the mtl in the Haskell Platform does the opposite by further entrenching its use, possibly to the point where we may not be able to get rid of it for years.
If I had to recommend a replace library, I would pick monadLib. However, there are other libraries, such as the mmtl and transformers and it's related packages that I haven't looked at, and may also make fine replacements for the mtl.
-- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Am Mittwoch, 13. Mai 2009 01:03 schrieb roconnor@theorem.ca:
I wanted to pass this idea around the cafe to get some thoughts before submitting a trac on this topic.
I'd like to see the mtl removed from the Haskell Platform.
The mtl was a tremendous step forward when it was developed. However, we have learned a few things about monad transformers since the development of the mtl, and it is time that we moved forward.
There are at least 3 significant problem with the mtl.
1) `pass' should not be a member functions of the MonadWriter class. It is my understanding that there is no `MonadWriter w m => MonadWriter w (ContT s m)' instance because the `pass' function cannot be implemented. I'm also highly suspicious of some other methods too (I'm looking at you `local').
2) The `StateT s (Cont r a)' instance of callCC is wrong. The paper on modular monad transformers http://www.cs.nott.ac.uk/~mjj/pubs/mmt/mmt.pdf describes why this is wrong.
3) I am told by many people that the order of the state and value pair in `State' is backwards. Actually, I'm not entirely sure what the issue is here, but I trust the people who say this.
4) The identifiers State and StateT are flawed. Something of value State s a doesn’t denote a state but a state transformer or however you want to name it. Best wishes, Wolfgang
On Thu, May 14, 2009 at 10:14, Wolfgang Jeltsch
4) The identifiers State and StateT are flawed. Something of value State s a doesn’t denote a state but a state transformer or however you want to name it.
A "state monad", i.e. a monad containing a state? If you use it in a sentence in that way, the name State makes sense. "StateTransformer" or something like that would lead to much confusion with the "state transformer transformer" that is currently called StateT. I don't really see a good alternative to the name State, and a good thing about it is that it is short. Oh, bikesheds ought to be brown, of course. Cheers, Thomas
participants (15)
-
Bulat Ziganshin -
David Leimbach -
Don Stewart -
Duncan Coutts -
Gwern Branwen -
Ketil Malde -
Neil Brown -
Robin Green -
roconnor＠theorem.ca -
Ross Paterson -
Simon Marlow -
Sittampalam, Ganesh -
Thomas ten Cate -
Wolfgang Jeltsch -
wren ng thornton