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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
