Please don't deprecate Haskell 98 modules.

[Gwern Branwen]

On Wed, Mar 10, 2010 at 7:56 PM, John Meacham <john at repetae.net> wrote:
> Please don't deprecate these modules.
>
> It is actively contributing to bitrot to deprecate a perfectly useful
> and well defined API. When I write new code that only needs C, I don't
> use C++ just because C is older. Likewise, when writing Haskell code
> today that doesn't require anything more than haskell 98, I use haskell
> 98. Because it is a well defined standard that I know will be supported
> by future and past compilers. Unlike writing to some current snapshot of
> what the libraries look like.
>
> Encouraging people to use bleeding edge APIs just contributes to the
> already dicey problem of writing future and backwards compatible code in
> Haskell, in fact, writing to haskell 98 is the _only_ option at the
> moment with any ability to do so.
>
> Haskell 98 should never be deprecated, because it is a stable, well defined
> standard that useful programs can be written to if someone chooses to do
> so and wants their code to have a chance of working down the road
> without having to continually keep changing it to keep up with libraries
> changes.
>
>        John

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

I don't think haskell98 meaningfully helps one write long-term code.
Something that helps long-term code is explicit imports, for example,
since it future-proofs one against added clashing function names and
makes it vastly easier for future programmers to update imports and
uses. But being able to write 'import List' versus 'import Data.List'?
No, I don't see that at all. What, are functions like 'isInfixOf'
going to be removed from Data.List though guaranteed to be in List?

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.

-- 
gwern