Call for consensus: addition of split package to platform
Hi everyone, Following the great feedback I got on the initial proposal, and after testing with the GHC 7.6 release candidate, I have just released split-0.2.0.0, which I am proposing for inclusion in the HP. The full proposal, links to previous discussion, etc. can be found on the wiki: http://trac.haskell.org/haskell-platform/wiki/Proposals/split Comments, questions, constructive criticism, etc. are still welcome, but this time around I hope we can build a consensus as to whether it should go in the platform or not. I would also like people's opinions on the one big question remaining: whether to use cabal's mechanisms to conditionally include some code, allowing the 'build' function to be taken from GHC.Exts when available, or defined manually otherwise. This would make split fully H2010-compatible. The currently released version does NOT include this, so it is H2010-compatible but GHC specific. The options are: 1) just use a generic version of 'build' (simplest option) 2) use only GHC's version of build (slightly faster) 3) do the conditional thing to choose between 1) and 2) at compile time (most general but most complicated/cumbersome) -Brent
On Tue, 21 Aug 2012, Brent Yorgey wrote:
I would also like people's opinions on the one big question remaining: whether to use cabal's mechanisms to conditionally include some code, allowing the 'build' function to be taken from GHC.Exts when available, or defined manually otherwise. This would make split fully H2010-compatible. The currently released version does NOT include this, so it is H2010-compatible but GHC specific. The options are:
1) just use a generic version of 'build' (simplest option)
2) use only GHC's version of build (slightly faster)
3) do the conditional thing to choose between 1) and 2) at compile time (most general but most complicated/cumbersome)
The best solution would be to have a package that provides the 'build' function for all compilers. For GHC it exports the fusing 'build' and for other compilers it exports a generic version. I think this 'build' function is useful for other packages, too. This package does not yet exist and if it would exist then it should or must be part of the platform. For now I would think a simple solution is ok, thus I vote for solution number 1. Later you can simply switch the import of 'build'.
I have just released split-0.2.1.0. This version is identical to the previous release except * I have updated pointers to the darcs repo, which has moved to http://hub.darcs.net/byorgey/split * I have taken the simple route of going back to a generic implementation of 'build', instead of exporting it from GHC.Exts. This makes the package completely 100% Haskell2010 compliant, and fits with the explicit philosophy of having efficiency be a non-goal. My current understanding is that the consensus is for inclusion of this in the HP. Otherwise, please speak up now! =) -Brent On Tue, Aug 21, 2012 at 02:48:28PM -0400, Brent Yorgey wrote:
Hi everyone,
Following the great feedback I got on the initial proposal, and after testing with the GHC 7.6 release candidate, I have just released split-0.2.0.0, which I am proposing for inclusion in the HP. The full proposal, links to previous discussion, etc. can be found on the wiki:
http://trac.haskell.org/haskell-platform/wiki/Proposals/split
Comments, questions, constructive criticism, etc. are still welcome, but this time around I hope we can build a consensus as to whether it should go in the platform or not.
I would also like people's opinions on the one big question remaining: whether to use cabal's mechanisms to conditionally include some code, allowing the 'build' function to be taken from GHC.Exts when available, or defined manually otherwise. This would make split fully H2010-compatible. The currently released version does NOT include this, so it is H2010-compatible but GHC specific. The options are:
1) just use a generic version of 'build' (simplest option)
2) use only GHC's version of build (slightly faster)
3) do the conditional thing to choose between 1) and 2) at compile time (most general but most complicated/cumbersome)
-Brent
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (2)
-
Brent Yorgey -
Henning Thielemann