Haskell 2010 libraries
malcolm.wallace at cs.york.ac.uk
Fri Apr 30 08:19:51 EDT 2010
> 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
just to freeze it, and discourage its general use.)
* Create a new "haskell2010" package (for ghc this will be built on
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
* Create a new "ghcextras" package which re-exports (or defines
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
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
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.
More information about the Libraries