Haskell 2010 libraries
marlowsd at gmail.com
Fri Apr 30 16:37:39 EDT 2010
On 30/04/10 13:19, Malcolm Wallace wrote:
>> 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 topcommon
> 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 it seems this is closer to option (2) in my message, because
portablebase and haskell2010 overlap, and are therefore mutually
exclusive, whereas in (4) haskell2010 and base2010 are non-overlapping -
that's the crucial difference.
I described this as a non-option because I thought trying to use the
packages together might be a common problem that leads to obscure error
messages about ambiguous modules, but perhaps it's not that bad, or at
least not worse than the other solutions.
I think we can leave the question of whether to abstract the existing
base into separate "portablebase" and "ghcextras" packages as a separate
issue - there are merits to doing something like this for sure, but I'd
like to focus specifically on Haskell 2010, and I think
portablebase/ghcextras are orthogonal.
> 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
We hope in the future that the set of libraries standardised in the
report grows beyond what we have in base currently, so I'm not sure how
much sense it makes for portablebase to re-export the haskell20xx
modules. Generally speaking we've been tyring to make base smaller
rather than larger. Indeed right now there are some modules in the
report that aren't in base, although those are the ones we're
considering removing in this iteration.
I like the picture where we have a small base, lots of independent
packages, and one or more haskell20xx packages that re-exports all the
standardised stuff from the other packages. This arrangement extends
smoothly, the only problem is that haskell20xx overlaps with the other
>> 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.
Yes, I agree - that's a non starter.
More information about the Libraries