Re: [Haskell-cafe] Why the Prelude must die

why do people insist that what they don't need has no right to live? also, there doesn't seem to be anything left in the Prelude itself, it just re-exports everything from one particular collection of modules. so the Prelude isn't really a useful target for complaints anymore, only the implicit import Prelude and the organisation of the base package are. authors and readers of older haskell books, as well as other programmers caring about stability will want -package haskell98 to provide the one implicitly imported Prelude. for those about to rely on -package haskell-prime, things are still open, while those relying on -package base will want clear documentation on which versions of base are backwards-compatible with all those haskell programs currently out there relying on an implicit Prelude, and which are not.

1. Namespace pollution 2. Monomorphism 3. Supports obsolete programming styles

these points could be addressed by requiring explicit import Prelude, starting from packages haskell-prime and the next version of base.

4. Stagnation 5. Inflexibility 6. Dependency 7. Monolithicity

these points seem to apply to package base rather than just the Prelude.

8. Monolithic itself 9. One-size-fits-all-ism 10. Portability 11. Committeeism 12. There is no escape 13. There can be no escape

once most code-bases have shifted to explicit import Prelude, it will become easier to replace that with import MyFavouritePrelude, where appropriate. that will also add more force to the recommendation to be more specific about imports, eg, import Data.List instead of import Prelude. once the Prelude is less attractive as an exaggerated swiss army knife style dumping ground for and source of definitions, the focus will perhaps shift to the separate modules it re-exports. i could well imagine different projects and books defining their own Prelude, re-exporting all those and only those modules needed or appropriate for their code. for instance, a haskell programming tutorial will have different needs (only basics) than a graphics tutorial (gui libs) than a book (functions provided in or disscussed in the book) than a script (System.Environment, System.Directory,..) than a <insert your current project here> (). } * If there is a "module M where" clause in the beginning of the file, } then it's a "proper" module and shouldn't import the Prelude. agreed, at least not implicitly, and with the caveats on backwards-compatibility mentioned above. } * If there is no module declaration then it's a "quick'n dirty script" } and should have the Prelude implicitly imported. which Prelude, though? haskell98? haskell-prime? current-base? shell-scripting? } * Interactive interpreters should probably import the Prelude. which makes sense for playing around, but not for interacting with real modules. ------ i suggest to make 'import Prelude' explicit for future versions of haskell (haskell-prime, base-<next-version>), and to have a standard flag for adding imports to non-explicit interpreter/runhaskell-sessions. starting an interactive system without explicitly loaded modules, and without --implicit-import flags, needs to load some default prelude, but should make it obvious that there is an implicit default import going on, and explain how to reproduce that import in proper modules (by giving a message "no modules loaded - loading default Prelude: <which>" that message should probably not be a warning, to avoid confusing beginners;-). the scrap module (no module header) could be handled like any session without explicitly loaded modules, so it will either follow the --implicit-import flags, or implicitly import the default prelude if there are no such flags (perhaps we should start distinguishing scrap modules from an implicit Main?). the default prelude would depend on the version of haskell selected (haskell98, haskell-prime, haskell-current), and it would be easy to add runhaskell-script (like runhaskell, but with a different implicit prelude, more suited to scripting). claus