On Wed, Mar 10, 2010 at 7:56 PM, John Meacham
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