[Haskell-cafe] Why the Prelude must die

[Claus Reinke]

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> 
(<things you import in every one of your modules make up your project's prelude>).

} * 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