Reform of the Monad, and Disruptive Change
There has been a fair amount of discussion, both on this list and libraries, regarding the Monad class hierarchy. The many on the libraries list expressed support for the patch at http://hackage.haskell.org/trac/ghc/ticket/4834, conditional on it being part of the next Haskell report. However, Haskell' prefers patches to have been implemented before proposing here. What is the best way out of this deadlock?
On 4 Feb 2011, at 09:41, John Smith wrote:
There has been a fair amount of discussion, both on this list and libraries, regarding the Monad class hierarchy. The many on the libraries list expressed support for the patch at http://hackage.haskell.org/trac/ghc/ticket/4834 , conditional on it being part of the next Haskell report. However, Haskell' prefers patches to have been implemented before proposing here.
What is the best way out of this deadlock?
I suggested, and several people +1'd, that if we are making disruptive changes to the standard libraries defined in the Language Report (especially the Prelude), then we should aim to make a thorough job of cleaning up all the cruft and redesigning in a single strike. This means not just rearranging the Monad hierarchy, but looking at I/O types, exceptions, the default strictness of foldl, and much much more. I would expect the language committee to get involved in reviewing the decisions of the base library strike force. Then (for instance) ghc could make a major release with the refreshed libraries, and after a little experience in the field (and perhaps a few patches), the libraries would then proceed to be blessed as part of the subsequent language standard. Regards, Malcolm
On 04/02/2011 12:08, Malcolm Wallace wrote:
I suggested, and several people +1'd, that if we are making disruptive changes to the standard libraries defined in the Language Report (especially the Prelude), then we should aim to make a thorough job of cleaning up all the cruft and redesigning in a single strike. This means not just rearranging the Monad hierarchy, but looking at I/O types, exceptions, the default strictness of foldl, and much much more. I would expect the language committee to get involved in reviewing the decisions of the base library strike force.
Then (for instance) ghc could make a major release with the refreshed libraries, and after a little experience in the field (and perhaps a few patches), the libraries would then proceed to be blessed as part of the subsequent language standard.
Regards, Malcolm
I thoroughly agree with this. However, in the event that this does not happen, piecemeal fixes are better than none. (Seeing as the inertia in Haskell is such that Haskell 2011 was cancelled, and Haskell Platform 2011 contains no new packages, such a task force doesn't seem very likely.)
On Fri, Feb 04, 2011 at 12:49:09PM +0200, Dark Lord wrote:
On 04/02/2011 12:08, Malcolm Wallace wrote:
I suggested, and several people +1'd, that if we are making disruptive changes to the standard libraries defined in the Language Report (especially the Prelude), then we should aim to make a thorough job of cleaning up all the cruft and redesigning in a single strike. This means not just rearranging the Monad hierarchy, but looking at I/O types, exceptions, the default strictness of foldl, and much much more. I would expect the language committee to get involved in reviewing the decisions of the base library strike force.
Then (for instance) ghc could make a major release with the refreshed libraries, and after a little experience in the field (and perhaps a few patches), the libraries would then proceed to be blessed as part of the subsequent language standard.
I thoroughly agree with this. However, in the event that this does not happen, piecemeal fixes are better than none.
(Seeing as the inertia in Haskell is such that Haskell 2011 was cancelled, and Haskell Platform 2011 contains no new packages, such a task force doesn't seem very likely.)
Also note that the H' process is the way it is because "fix everything at once" in the language turned out to be infeasible. The same may or may not be true for the libraries. I don't object to a "fix everything at once" libraries change, but in the absence of it happening, fixing things individually is also good with me. (where "individually" would still mean, for example, all Monad class reshuffling should happen at once, but the strictness of foldl' would be a separate change). Thanks Ian
On 04/02/2011, at 10:49, Dark Lord wrote:
I thoroughly agree with this. However, in the event that this does not happen, piecemeal fixes are better than none.
FWIW, I disagree. To put it bluntly, why is repeatedly breaking a lot of code better than not breaking it at all? Breaking a lot of code once might be ok because the benefits of fixing many issues probably outweigh the costs. But for each individual change (such as the Monad redesign), the costs far outweigh the benefits, IMO.
(Seeing as the inertia in Haskell is such that Haskell 2011 was cancelled, and Haskell Platform 2011 contains no new packages, such a task force doesn't seem very likely.)
Introducing backwards-incompatible changes into a language standard *should* be hard. Roman
On 04/02/2011, at 10:08, Malcolm Wallace wrote:
I suggested, and several people +1'd, that if we are making disruptive changes to the standard libraries defined in the Language Report (especially the Prelude), then we should aim to make a thorough job of cleaning up all the cruft and redesigning in a single strike. This means not just rearranging the Monad hierarchy, but looking at I/O types, exceptions, the default strictness of foldl, and much much more.
Is there a list of known issues for the standard libraries somewhere? Would it perhaps make sense to create a design bug tracker for them?
Then (for instance) ghc could make a major release with the refreshed libraries, and after a little experience in the field (and perhaps a few patches), the libraries would then proceed to be blessed as part of the subsequent language standard.
Perhaps GHC could be released with two sets of libraries. This would give people time to experiment without breaking existing code. It would also make implementing individual changes much easier. Roman
Perhaps GHC could be released with two sets of libraries. This would give people time to experiment without breaking existing code. It would also make implementing individual changes much easier.
I fully support this. {-# LANGUAGE NewPrelude #-} or something similar would be wonderful.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/4/11 14:30 , Daniel Peebles wrote:
Perhaps GHC could be released with two sets of libraries. This would give people time to experiment without breaking existing code. It would also make implementing individual changes much easier.
I fully support this. {-# LANGUAGE NewPrelude #-} or something similar would be wonderful.
Or Haskell Platform/Haskell Future with some way other than standard level to select it... although I don't recall if this is easily doable. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery.b@gmail.com system administrator [openafs,heimdal,too many hats] kf8nh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1MuzIACgkQIn7hlCsL25UoiQCeK0YqPIw69jcFaw0ZfVv1HLT/ riUAoJe5efmuWLLIHunvUvYPZJBszcTh =zdsY -----END PGP SIGNATURE-----
participants (7)
-
Brandon S Allbery KF8NH -
Daniel Peebles -
Dark Lord -
Ian Lynagh -
John Smith
-
Malcolm Wallace -
Roman Leshchinskiy