|Version 6 (modified by malcolm.wallace@…, 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 Floating.
- make String into a class rather than a type, with instances for [Char], PackedString, etc
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 catch is also exported by Control.Exception, take/drop are 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.
- Remove the implicit import of the Prelude in its entirety. Where a syntactic desugaring rule currently uses an entity from the Prelude, the new interpretation is that it uses whatever binding of that entity is in scope - if there is no such entity in scope, it is an error. For compatibility, the current Prelude can continue to be made available as an explicit import, so that the only change required to fix existing code is import Prelude. Indeed, an implementation may choose to provide a compile-time option like -fimplicit-prelude, the inversion of ghc's -fno-implicit-prelude, to avoid the need to change old code at all.
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. (4) is Malcolm's idea.
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.