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
