What's the future of the haskellYYYY packages?

On 11 November 2011 15:09, Henning Thielemann
On Fri, 11 Nov 2011, Bas van Dijk wrote:
I forgot the reason why we need Control.Monad.Instances which exports orphaned Functor and Monad instances for ((->) r), ((,) a) and (Either e):
Compatibility with Haskell 98's Prelude?
Thanks I understand. What exactly is the future plan of the haskell98 and haskell2010 packages? I understand that the Haskell' Process[1] now only deals with the Haskell language and that the evolution of the core libraries is now the responsibility of the Library Submission Process[2]. Does this mean we stop making haskellYYYY packages? I think that would be a good thing. Since these packages block innovation in certain parts of base (for example: getting rid of some orphaned instances in Control.Monad.Instances or designing a new monad hierarchy). Regards, Bas [1] http://hackage.haskell.org/trac/haskell-prime/wiki/Process [2] http://www.haskell.org/haskellwiki/Library_submissions

On 11/11/2011 15:06, Bas van Dijk wrote:
On 11 November 2011 15:09, Henning Thielemann
wrote: On Fri, 11 Nov 2011, Bas van Dijk wrote:
I forgot the reason why we need Control.Monad.Instances which exports orphaned Functor and Monad instances for ((->) r), ((,) a) and (Either e):
Compatibility with Haskell 98's Prelude?
Thanks I understand.
What exactly is the future plan of the haskell98 and haskell2010 packages? I understand that the Haskell' Process[1] now only deals with the Haskell language and that the evolution of the core libraries is now the responsibility of the Library Submission Process[2]. Does this mean we stop making haskellYYYY packages?
I don't think that's true. Both Haskell 98 and Haskell 2010 specified a number of library modules, which are implemented by the packages haskell98 and haskell2010 respectively. If we want to support those standards, we have to support their libraries too.
I think that would be a good thing. Since these packages block innovation in certain parts of base (for example: getting rid of some orphaned instances in Control.Monad.Instances or designing a new monad hierarchy).
They don't necessarily block progress in the base package, they just mean that more code has to be copied into haskell98/haskell2010 to maintain the original API. I'm not sure to what extent we want to do this. So far we've only had to copy a few individual functions and fix export lists. The change to Num recently meant that we have diverged from Haskell 98 and Haskell 2010 in a fairly fundamental way, and to recover compatibility we would have to copy a lot of code into haskell98 and haskell2010. On the other hand the change doesn't break very much code, so we could let it slip (I think that's what we'll do). It would be a shame to drop compatibility for Haskell 2010 only two years after it was released. I don't have a good feeling for how important this is though - certainly not much code on Hackage is written in pure Haskell 98 or Haskell 2010, but what about course materials and textbooks? Cheers, Simon

Simon> On 11/11/2011 15:06, Bas van Dijk wrote:
I'm not sure to what extent we want to do this. So far we've only had to copy a few individual functions and fix export lists. The change to Num recently meant that we have diverged from Haskell 98 and Haskell 2010 in a fairly fundamental way, and to recover compatibility we would have to copy a lot of code into haskell98 and haskell2010.
What's wrong with copying a lot of code? It's not code that's going to need maintenance is it? -- Colin Adams Preston Lancashire () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

On 11/11/2011 16:40, Colin Paul Adams wrote:
Simon> On 11/11/2011 15:06, Bas van Dijk wrote:
I'm not sure to what extent we want to do this. So far we've only had to copy a few individual functions and fix export lists. The change to Num recently meant that we have diverged from Haskell 98 and Haskell 2010 in a fairly fundamental way, and to recover compatibility we would have to copy a lot of code into haskell98 and haskell2010.
What's wrong with copying a lot of code? It's not code that's going to need maintenance is it?
I don't have a big problem with it, no. It's just the time required to actually do it - depending on how deep the divergence is, you might have to pull a lot of the GHC.* modules in the base package over, and the intermodule dependencies can be quite tricky. There are the lesser issues of the extra compile time and disk space for the duplicated library code too. Also, the more copying you do, the less it becomes possible to have a program that consists of a combination of haskell2010 modules and modules that import the base package. Essentially it becomes impossible to have libraries written in pure Haskell 2010. Again, I don't know how much we care about that. Cheers, Simon

On 11 November 2011 17:50, Simon Marlow
Also, the more copying you do, the less it becomes possible to have a program that consists of a combination of haskell2010 modules and modules that import the base package. Essentially it becomes impossible to have libraries written in pure Haskell 2010. Again, I don't know how much we care about that.
What is the purpose of haskellYYYY if it becomes impossible to combine (either directly or indirectly) base and haskellYYYY? Is it just so that book authors can base their books on a stable API? If so, why can't they just base their books on some version of base exploiting the PVP? Cheers, Bas

On Fri, Nov 11, 2011 at 5:00 PM, Bas van Dijk
On 11 November 2011 17:50, Simon Marlow
wrote: Also, the more copying you do, the less it becomes possible to have a program that consists of a combination of haskell2010 modules and modules that import the base package. Essentially it becomes impossible to have libraries written in pure Haskell 2010. Again, I don't know how much we care about that.
What is the purpose of haskellYYYY if it becomes impossible to combine (either directly or indirectly) base and haskellYYYY?
Is it just so that book authors can base their books on a stable API? If so, why can't they just base their books on some version of base exploiting the PVP?
Cheers,
Bas
My understanding was that base is large and fairly intricate (contains use of ExistentialQuantification, RankNTypes, and so forth) whereas haskell2010 is comparatively simple to implement, so there's more hope that it could be provided by a non-GHC compiler. In practice I suspect that it's not often used in this way, but I like the idea. Ben
participants (4)
-
Bas van Dijk
-
Ben Millwood
-
Colin Paul Adams
-
Simon Marlow