Version 5 (modified by Simon Marlow, 11 years ago) (diff)

add some slightly more concrete proposals

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

  1. 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.
  2. 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).
  3. 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.