Haskell 2010 libraries
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
More information about the Libraries