Haskell 2010 libraries

[Ian Lynagh]

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.


Thanks
Ian