|Version 5 (modified by 11 years ago) (diff),|
Shrink the Prelude
People sometimes complain that the Prelude steals lots of good names from the user. Think of 'map' or (+). Yes, most of the time we want these names to have a standard interpretation, but occasionally it is useful to be able to redefine them to mean something else. For instance, there are several proposals to change the prelude's numeric class hierarchy into something more flexible involving rings, groups, and so on.
But it is tedious if the user of such a proposed replacement for the Prelude must explicitly hide the standard prelude in every importing module.
Thus it might be useful to trim the Prelude down to the bare minimum possible. Most users of e.g. list functions would then need to import Data.List, users of numeric functions would need to import Data.Numeric, and so on. Of course, some users (e.g. university teachers) might want to collect a bunch of utility libraries into a single import resembling the current Prelude. But the point is that they could choose the features they want to expose to students, and hide those they want to avoid as well. For instance, there are certainly some teachers who would like to be able to ignore the class overloading system altogether at the beginning, then perhaps introduce the concept later on, once the basics have been covered.
Examples of proposals for restructuring the Prelude
- revise the Numeric class hierarchy, e.g. collapse classes
RealFrac, Fractional, and
- make String into a class rather than a type, with instances for
Concrete proposals for deciding what to remove
- Remove entities that clash with other common libraries, which would otherwise require
import Prelude hiding. For example, a function called
catchis also exported by
take/dropare also exported by
Data.Sequence. A list of these can easily be constructed.
- Remove entities that are used in fewer than N% of modules (measure as much code as we can get our hands on, choose some appropriate N).
- Decide what to keep.
For the record I (Simon M.) support doing at the very least (1), and I'm interested in measuring code along the lines of (2) so that we can find out what things are hardly ever used. (3) is rather less conservative.
At the moment this is an idea for a proposal, rather than a proposal. It needs to be made concrete before we can act on it.
On the other hand, any firm proposal in this area would cost a significant amount of work. Some indication of general positivity or negativity towards the idea would help us know whether it is worth expending effort on devising some definite proposals.