Removal of UniqMap module

2020-05-10 Thread Matthew Pickering
Hi,

I noticed that the UniqMap module was removed from the tree

See 1c7c6f1afc8e7f7ba5d256780bc9d5bb5f3e7601

Why was it removed? I needed it today and now I am unsure what the
suitable replacement is.

As a general point, please can we stop with these annoying
refactorings which delete unused code
and move around definitions for no clear purpose. The amount of churn
on the code base has wasted me a lot of time recently.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: Removal of UniqMap module

2020-05-10 Thread Richard Eisenberg


> On May 10, 2020, at 11:22 AM, Matthew Pickering  
> 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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


Re: Removal of UniqMap module

2020-05-10 Thread Andreas Klebinger

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  
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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs