Please don't deprecate Haskell 98 modules.

[John Meacham]

On Thu, Mar 11, 2010 at 09:59:11AM -0500, Gwern Branwen wrote:
> No one is talking about removing haskell98; my bug report is about
> warning about use of it. You can go on using 'import Monad' if you
> like - just like you can go on shadowing variables, omitting
> pattern-matches & type sigs, naming unused variables, and defining
> unused functions. Just like with haskell98, there are (contrived and
> otherwise) scenarios where one actually wants to do those things,
> which is why they aren't *errors*.

Except that writing a program that just uses Haskell 98 is a virtue, not
a vice. When you target a standard your program becomes much easier to
maintain. As it is now, it is a major pain to write future compatible
haskell. For instance, pretty much every ghc compiler release I have had to
modify code due to one of the libraries suddenly exporting something it
didn't before. Like you say, qualified imports can help with this, but
it still doesn't protect against the meaning of functions changing and
can be much harder to maintain. It doesn't matter whether that is
unlikely or not, it is sometimes important to _know_ a program or library will
continue to work in the future. If you are printing a book with Haskell
code, or heck, just want to be able to publish it and not have to keep
modifying it every time there is a new compiler release.  Right now it
is almost impossible to be 'done' with a Haskell program. you
continually have to churn the dependency list and keep up with changes in
ghc, targetting haskell 98 when possible gets rid of those issues
completely. As will targetting Haskell 2010, or any other specific
release. We should be _encouraging_ writing against standards when
possible, not discouraging it. Haskell 98 may be aethetically
displeasing in some ways, but that doesn't diminish its usefulness as a
standard.

> Nor do you address the multiple strikes against haskell98 that I've
> already adduced: that it encourages people (like you!) to duplicate
> library code; that it leads to mixture of modern and old module names
> (I'm not sure that I've yet run into a package which needed only
> haskell98 and not also 'base'); that it hides the finer-grained
> dependencies (reverse dependencies were linked; notice that each
> package that depends on haskell98 may be screwing up the reverse
> dependency list of process/random/containers/old-locale/...); etc.

One has to duplicate library code if one wants their program to be
portable to libraries/versions of ghc that don't have said code in their
library. Having newer packages depend on older, portable packages should
not be a burden or force the portable packages to be needlessly changed.
If this somehow is an issue, that seems like an issue with the package
manager that needs to be addressed, not by the brute force approach of
dragging everything to haskell-prime kicking and screaming.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/