Haskell 2010 libraries

[Simon Marlow]

On 01/05/10 17:16, Ian Lynagh wrote:

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

In this scenario there would be base as it is now, and base2010 (or 
whatever you want to call it) that is base minus the modules in 
haskell2010.  So you can add things to base:Data.List, but 
haskell2010:Data.List must export exactly the API as specified in the 
report.

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

Yes, that's true. Adding methods to classes is possible, but adding 
constructors to datatypes, or new instances, is not.

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

FWIW, I omitted mentioning that option because I think it's the worst of 
the bunch :-)  I think that putting version numbers into module names is 
a very dangerous thing to start doing.  When you want to upgrade your 
code to Haskell 2011, you have to change not just the .cabal file but 
all the imports too.  Keeping version dependencies collected together in 
one place and not scattered through source code is one of the better 
design decisions we made, I believe.

Doing "nothing" as you suggest is an option, but it would mean using the 
non-hierarchical names for the FFI libraries.  There's nothing 
technically wrong with it, but I find it a bit odd to be standardising 
modules with names that in practice almost no code has ever used.  I 
suppose those are the names in the FFI addendum though.

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

Not sure what you mean here - modules are imported, not packages.  Type 
error!

It's the modules that overlap between the two packages that are the 
problem.  If someone imports Data.List, do they mean the haskell2010 or 
the base one?  If you're suggesting that we choose based on whether the 
flag -fhaskell2010 is set, then that really amounts to the haskell2010 
package shadowing base when -fhaskell2010 is on.  It might be the right 
thing, but it's a slightly ugly special case.

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

I thought the *eventual* plan was to properly standardise lots of 
libraries, with the Haskell Platform being an intermediate step on the 
way to standardisation. Though I don't think we ever actually decided 
anything, really.

Cheers,
	Simon