Haskell 2010 libraries

[Simon Marlow]

Hi Folks,

I'm editing the Haskell 2010 report right now, and trying to decide what 
to do about the libraries.  During the Haskell 2010 process the 
committee agreed that the libraries in the report should be updated, 
using the current hierarchical names, adding new functionality from the 
current base package, and dropping some of the H'98 library modules that 
now have better alternatives.

In Haskell 2010 we're also adding the FFI modules.  The FFI addendum 
used non-hierarchical names (CForeign, MarshalAlloc etc.) but these are 
usually known by their hierarchical names nowadays: e.g. Foreign.C, 
Foreign.Marshal.Alloc.  It would seem strange to add the 
non-hierarchical names to the Haskell language report.

So this is all fine from the point of view of the Haskell report - I can 
certainly update the report to use the hierarchical module names, but 
that presents us with one or two problems in the implementation.

The obvious thing to do would be to make a haskell2010 package that 
re-exports the appropriate modules from base, providing a fixed API that 
people can depend on when they write Haskell 2010 code.  However, what 
happens when someone wants to write some code that uses Haskell 2010 
libraries, but also uses something else from base, say 
Control.Concurrent?  The modules from haskell2010 overlap with those 
from base, so all the imports of Haskell 2010 modules will be ambiguous. 
  The Prelude is a bit of a thorny issue too: currently it is in base, 
but we would have to move it to haskell2010.

Bear in mind these goals: we want to

   a. support writing code that is Haskell 2010 only: it only uses
      Haskell 2010 language features and modules.

   b. not break existing code as far as possible

   c. whatever we do should extend smoothly when H'2011 makes
      further changes, and so on.

Here are some non-options:

   1. Not have a haskell2010 package.  We lose (a) above, and we
      lose the ability to add or change the API for these modules,
      in base, since they have to conform to the H'2010 spec.  If
      H'2011 makes any changes to these modules, we're really stuck.

   2. As described above: you can either use haskell2010, or base,
      but not both.  It would be painful to use haskell2010 in
      GHCi, none of the base modules would be available.

Here are some options:

   3. allow packages to shadow each other, so haskell2010 shadows
      base.  This is a tantalising possibility, but I don't have
      any idea what it would look like, e.g. should the client or
      the package provider specify shadowing?

   4. Provide a haskell2010 package and a base2010 package that
      re-exports all of base except the modules that overlap with
      haskell2010.  You can either use haskell2010,
      haskell2010+base2010, or base.  This is a bit like (1), but
      avoids the need for shadowing by using package re-exports,
      on the other hand confusion could well arise due to the
      strange base2010 package, and some people would surely try
      to use haskell2010 + base and run into difficulties.

   5. Not have a haskell2010 package, but have the report say that
      implementations are allowed to add things to the standard
      libraries.

Thoughts?  Better ideas?

Cheers,
	Simon