Prelude

Per Larsson per at L4i.se
Fri Oct 24 11:48:01 EDT 2003


Haskell has an elegant mechanism for overloading operators and function names.
In the prelude, a lot of efforts have been made to overload arithmetic names 
and operators for numerical classes. I think it is a pity that the prelude is 
considerably more careless with other "good" names which, in my opion, should 
have been included in type classes. 

For example:

&&, ||, (not): These could have been included in  a Boolean 
(ComplementedBoolean) class and reused for other boolean algebras than the 
Bool data type,  e.g. in library Data.Bits, library Data.Set , lifted for 
monads or simply being available for user defined types e.g. representing 
logical formulae or parser combinators.

++, concat: These could be the names in the Monoid class instead of tying them 
to lists.

map: This could be the name in the Functor class instead of being tied to 
lists.

null, elem, filter,  reverse..etc.: Many of the list functions could be 
collected in a generic Sequence class, (in the style of the Edison library 
design, which has an excellent naming scheme also for collections and 
mappings) and thereby be reused for other list implementations.

Given such overloading, as a bonus, some other names can be given a more 
generic type, e.g. and, or, any, all.

There are also other old solutions in the prelude which makes life more 
difficult for the designers of the new hierachical libraries, I'm thinking 
for example of the discussions regarding new IO file primitives and new 
exception handling primitives and the inefficiency of the Read class as a 
generic parser mechanism.

 My conclusion is that the prelude is far too big and inflexible,  
unnecessarily stealing many important names which preferably should be 
included in type classes, retyped to more general types, or moved to 
specialized libraries where some experimentation is allowed before standards 
are cemented.  Therefore, it starts to look rusty and should be considered to 
be shrinked and redesigned in the next haskell standard (before it is too 
late).

Best Regards 
Per


More information about the Haskell mailing list