Haskell 2010: libraries
marlowsd at gmail.com
Wed Jul 8 10:09:29 EDT 2009
This is more of a consistency issue than anything else. We have to
decide what to do with the libraries in the Report.
Right now, the Haskell Report specifies 15 library modules. Things like
Maybe, Char, IO, Time, and Random. The situation is not ideal, for many
- There are a lot more than 15 library modules available to Haskell
programmers! The libraries section of the report was a good
idea when there were no libraries at all, nowadays it makes
a lot less sense.
- These modules are using the old non-hierarchical names. Best
practice these days is to use the hierarchical versions.
- some of these libraries have well-known problems, and some have
been superseded by better libraries: Time is a good example.
On the other hand, some people like having these modules around, and
deliberately use them because they aren't allowed to change.
I'm mainly concerned with projecting a consistent picture in the Report,
so as not to mislead or confuse people. Here are the options I can see:
1. Just drop the whole libraries section from the report. The
Report will still define the Prelude, however.
There will be some loose ends where the rest of the report
refers to entities from these libraries, e.g. the Prelude
refers to Rational from the Ratio library. We just have to
fix up these references, moving the appropriate definitions
into the Report as necessary.
2. Just drop the obvious candidates (Time, Random, CPUTime,
Locale, Complex?), leaving the others.
3. Update the libraries to match what we have at the moment.
e.g. rename List to Data.List, and add the handful of
functions that have since been added to Data.List. One
problem with this is that these modules are then tied to
the language definition, and can't be changed through
the usual library proposal process. Also it would seem
slightly strange to have a seemingly random set
of library modules in the report.
4. Combine 2 and 3: drop some, rename the rest.
5. Don't do anything.
Note that we have to take into account the FFI libraries too: the FFI
addendum includes modules such as Foreign, CForeign, Storable,
MarshalError, and so on. The same issues apply: the report needs to
mention some of the types and entities exported by these modules.
I'm tending towards (1), mainly because it provides a clean break and is
likely to be the least confusing for users: they have one place to go
looking for library documentation.
Please keep discussion focussed: this is about how libraries are
presented in the Haskell report, not about library standardisation in
general. I'm aware there are much wider issues, but we have some
immediate problems to address.
More information about the Haskell-prime