Haskell 2010 libraries

[Malcolm Wallace]

>  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?

This sounds like a potentially complicated new mechanism, introducing  
lots of new subtleties.  Probably not a good idea for that reason alone.

>  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.

In many ways this corresponds to my preferred solution, although I  
would rephrase it thus:

   * Deprecate use of the "base" package,  (I do not mean to remove  
"base",
     just to freeze it, and discourage its general use.)
   * Create a new "haskell2010" package (for ghc this will be built on  
top
     of "base", but other compilers might make a different choice).
   * Create a new "portablebase" package which contains (or re-exports)
     all of the remaining useful and portable parts of the current  
"base"
     _and_ "haskell2010".
   * Create a new "ghcextras" package which re-exports (or defines  
afresh)
     all of the useful but non-portable parts of the current "base".

So "haskell2010" would be stable and unchanging.  "portablebase" would  
be a superset of "haskell2010", and continue to evolve with community  
input, and parts of it would eventually migrate into "haskell2011",  
"haskell2012", etc.  Meanwhile "ghcextras" would clearly delineate  
those language/library features that are not portable, and it could  
continue to grow, or indeed shrink, with some parts migrating into  
"portablebase" as the language definition adopts extensions, or as  
other compilers adopt implementation strategies.

To illustrate the forward compatibility story, I envisage that when  
"haskell2011" is created, a new version of "portablebase" would depend  
on (and re-export) it instead of "haskell2010".  This would be OK  
because the "portablebase" API would be non-decreasing, and new  
Reports should not make library changes that have not already been  
trialled in the community.  On the other hand, the "ghcextras" package  
would be free to shrink as functionality is gradually transferred to  
"portablebase".

Because I suggest that "portablebase" re-export the "haskell2010" API  
in its entirety, it would be impossible to use both packages  
explicitly at the same time from a single module - users would need to  
choose one or the other.  Also, packages which currently depend on  
"base" should be encouraged to upgrade to a dependency on  
"haskell2010" rather than on "portablebase", if possible, because it  
provides greater stability of interface.

The overall dependency graph would look something like this:

                           /--- stablestuff   /-- less-stable-stuff
                          /                  /
      base ---  haskell2010 --- portablebase ---\
           \--  ghcextras   ---------------------\=== experimental-stuff

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

This seems superficially attractive, but I think it would be  
impossible in practice to guarantee anything.  For instance, the  
semantics of "take" and "drop" changed between Haskell 1.4 and  
Haskell'98 iirc, with no corresponding change in the API.  With  
separate packages it is possible to retain and choose between both  
sets of semantics.

Regards,
     Malcolm