Haskell 2010 libraries

[Duncan Coutts]

On Fri, 2010-04-30 at 10:42 +0100, Simon Marlow wrote:
> 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.
> 
> 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.

This problem with the Prelude also already exists. It is currently not
possible to write a H98-only program that depends only on the haskell98
package and not on the base package, because the Prelude is exported
from base and not from haskell98.

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

So one option is simply to have the client specify shadowing by the
order in which packages are listed on the command line / in the .cabal
file (or some other compiler-dependent mechanism).

If people think the order in the .cabal file is not sufficiently
explicit then I'm sure we can concoct some more explicit syntax. We
already need to add some syntax to allow a package to depend on multiple
versions of a single dependency.

The advantage of the client doing it is it's quite general. The downside
is it's quite general: people can do it anywhere and can easily get
incompatible collections of types. For example base:Prelude.Int would
only be the same as haskell2010:Prelude.Int because it is explicitly set
up to be that way. Arbitrary shadowing would not be so co-operative.


The provider doing it seems fairly attractive. Cases of co-operative
overlapping have to be explicitly constructed by the providing packages
anyway (see e.g. base3 and base4).

I'm not quite sure how it would be implemented but from the user's point
of view they just list the package dependencies as usual and get the
sensible overlapping order. Presumably packages not designed to be used
in an overlapping way should still give an error message.

The provider doing it rather than the client should avoid the user
having to think too much or there being too many opportunities to do
foolish and confusing things. Only the sensible combinations should
work.

> Thoughts?  Better ideas?

So I think I quite like option 3. I doesn't sound to me as complicated
or as subtle as Malcolm seems to fear.

If I write:

build-depends: base, haskell2010

then since haskell2010 has been explicitly set up for this overlapping
to be allowed, then we get haskell2010 shadowing base (irrespective of
the order in which the client lists the packages).

Duncan