Removal of UniqMap module

Andreas Klebinger klebinger.andreas at gmx.at
Sun May 10 12:54:23 UTC 2020


My two cents:

> I needed it today and now I am unsure what the
> suitable replacement is.

If you need it (inside GHC) just re add it.

If you think it should be kept as part of GHC's API re add it and add a
comment stating such.

Iirc it was removed since no one used it, not because anything was wrong
with it design wise iirc.

> As a general point, please can we stop with these annoying
> refactorings which delete unused code

In general I think these kind of refactorings are needed and fine.
But it does feel like people became a bit overzealous in that regard
recently.

Cheers
Andreas

Richard Eisenberg schrieb am 10.05.2020 um 14:43:
>
>> On May 10, 2020, at 11:22 AM, Matthew Pickering <matthewtpickering at gmail.com> wrote:
>>
>> Hi,
>>
>> I noticed that the UniqMap module was removed from the tree
>>
>> See 1c7c6f1afc8e7f7ba5d256780bc9d5bb5f3e7601
>>
>> Why was it removed?
>  From the commit message: "This module isn't used anywhere in GHC." That seems like a good reason to remove, to me. While I can understand the frustration at having this disappear when you need it, we can't quite just keep whole unused modules around in the hope that someone someday will use them.
>
>> I needed it today and now I am unsure what the
>> suitable replacement is.
> A UniqFM whose range includes the domain element would work fine, I think.
>
>> As a general point, please can we stop with these annoying
>> refactorings which delete unused code
> I disagree here. A codebase as large and sprawling as GHC's needs constant pruning. The alternative is not to control the sprawl, and that seems considerably worse than refactorings and churn.
>
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



More information about the ghc-devs mailing list