Haskell 2010 libraries
marlowsd at gmail.com
Sat May 1 15:05:58 EDT 2010
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
> 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
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
More information about the Haskell-prime