Haskell 2010 libraries

Ian Lynagh igloo at earth.li
Sat May 1 12:16:27 EDT 2010

On Fri, Apr 30, 2010 at 09:37:39PM +0100, Simon Marlow wrote:
> 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.

If they are non-overlapping, how would a new Data.List function be
added? Or an existing Data.List function be altered?

No matter what solution is chosen, changes to datatypes or classes seem
likely to be troublesome.

I think the library change plans are underdeveloped, the libraries
should be unchanged in H2010, and we should resolve this issue before
changing them in a future language revision. That would keep other
options open, such as the report standardising Haskell2011.Data.List
rather than Data.List, etc.

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

Direct imports of base* and haskell* could be (dis)allowed by the
implementation depending on whether it is in "Haskell 2010 mode" or not.

> We hope in the future that the set of libraries standardised in the  
> report grows beyond what we have in base currently

Oh, I thought the plan was for library standardisation in the report to
be reduced, with perhaps the Haskell Platform becoming the new library
standardisation effort.


More information about the Libraries mailing list