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