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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
