Please don't deprecate Haskell 98 modules.

[Iavor Diatchki]

Hello,

I agree with John because I don't think that adding warnings about
using the haskell98 package achieves anything meaningful.  The issue
seems to be a matter of taste---some people like it, some don't, and
we already have a system that lets us choose if we want to use it or
not.  It certainly does not seem in the same class of problems as
"incomplete patterns in definitions", for example.

As far as indirect dependencies are concerned, I agree that it might
be nice to have more control over the packages on which we depend
(certainly important in the case of GPLd libraries) but that has
nothing to do with the haskell98 package.

-Iavor

PS:  By the way, I don't see how hierarchical names are important in
any way to Cabal or hackage: I agree that using "." in module names
instead of, say, "_" might look a bit nicer (or just more familiar?)
but, as features go, this is a pretty small one.


On Thu, Mar 11, 2010 at 6:11 PM, John Meacham <john at repetae.net> wrote:
> 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/
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>