Haskell 2010 libraries

[Simon Marlow]

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

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

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

Yes, I agree - that's a non starter.

Cheers,
	Simon