On Saturday 24 March 2007 03:48, Stefan O'Rear wrote:
1. Namespace pollution
The Prelude uses many simple and obvious names. Most programs don't use the whole Prelude, so names that aren't needed take up namespace with no benefit. [...]
Even though I think that the current Prelude is far from perfect, one should not forget that is a very solid foundation of a "common language": If one sees e.g. '(.)' or 'map', it is immediately clear to everybody what this means, without having to scan through (perhaps long) import lists. Of course one could hide some parts of the Prelude etc., but I think in the long run this only leads to confusion. Redefining common things, heavy use of tons of self-defined operators etc. all make maintenance much harder. Try reading Lisp code with heavy use of macros or C++ code with tons of overloadings. This is more like Sudoku solving than anything else, because there is no "common language" between the author and the reader anymore. And taking away the prelude is a little bit like taking away 'int', 'double', 'for', 'while' etc. from the C programmer...
11. Committeeism
Because the Prelude has such a wide audience, a strong committee effect exists on any change to it. This is the worst kind of committeeism, and impedes real progress while polluting the Prelude with little-used features such as fail in Monad (as opposed to MonadZero) and until.
Depending on your viewpoint, you can see this as a plus. Everybody agrees that finalizers are evil, but propose the removal of that method from java.lang.Object to the Java people. :-) My proposal would be to incrementally improve the Prelude, modularize it a bit more, fix the Num hierarchy, but basically leave it as it is. Cheers, S.