Please don't deprecate Haskell 98 modules.

Gwern Branwen gwern0 at
Fri Mar 12 20:44:46 EST 2010

On Fri, Mar 12, 2010 at 5:43 PM, Aaron Denney <wnoise at> wrote:
> On 2010-03-11, Yitzchak Gale <gale at> wrote:
>> John Meacham wrote:
>>> Please don't deprecate these modules.
>>> It is actively contributing to bitrot to deprecate a perfectly useful
>>> and well defined API.
>> I think "deprecate" is just the wrong word. Gwern is not
>> saying that we should remove haskell98 from Hackage,
>> nor remove the -98 flag from Hugs, nor build a special
>> case into compilers that make modules not compile if
>> they use Haskell 98 syntax.
> It is precisely the right word -- in the context of computer standards
> it means discouraging use due to new ways of accomplishing the same
> thing, while still allowing it.  Doing any of those things you mentioned
> would not be deprecation, but breaking.
>> As I understand it, the problem he is trying to solve is the
>> following:
> I don't see why it's a problem, frankly.
>> Haskell code today uses hierarchical module names almost
>> universally. This has been the case for years.
> Check and check.
>> Yet a huge number
>> of packages on Hackage directly or indirectly depend on the
>> the haskell98 module, whose sole purpose is to allow the old
>> non-hierarchical module names from pre-addendum Haskell 98.
> In other words, to _implement the standard_.  Some people do
> code to the standard as much as practicable, because that portion
> is then guaranteed to work, leaving only uncertainties about the
> portions that aren't Haskell 98.  If you want to instead throw their
> code on a treadmill of evolving "what works as of GHC-HEAD", then you
> have to be the maintainer.
>> Gwern is just trying to think of a way to remove all of those
>> spurious dependencies. I agree that this cleanup would be
>> a good idea. The only question is, how do we best go about it?
> I don't see how it's a _useful_ cleanup, or that the dependencies
> are truly spurious.

You haven't been paying attention then, or you're using a different
definition of 'spurious' than I am. *Many* packages do not use
haskell98! I'm pretty sure I've said this already. I have sent in
multiple patches which consisted solely of one line removing haskell98
from the .cabal because the haskell98 modules *were not imported*.

I don't know how a dependency can be more spurious than that.


More information about the Libraries mailing list