Re: Proposal: keep Data.Map.foldWithKey

Am 15.12.2010 15:38, schrieb Johan Tibell:

Hi all,

On Tue, Dec 14, 2010 at 1:28 PM, Christian Maeder wrote:

...

I've now created a proper library proposal to keep Data.Map.foldWithKey. Exchange arguments and make up your mind until Jan. 15th.

http://hackage.haskell.org/trac/ghc/ticket/4842

My vote is "no", there are already too many fold variants in Data.Map. We have

{left,right} x {non-strict,strict} x {with key, without key} = 8 combinations together.

Currently only two of these 8 are visible and a third foldlWithKey' is commented out. Is there a demand for the strict variants (to be expressed by a proposal)? It would need some more documentation to choose the right version. foldr' is also missing for list probably because foldr is not tail recursive. Control.Monad.foldM is also only a left version (and I do not propose to add foldrM and foldlM and deprecate foldM later). For the "without key" variants I see no need. Omitting an unused first argument can be easily done using "const". foldx = foldxWithKey . const (Maybe "foldxWithKey" should have been named just "foldx" in the first place.)

Adding back the "directionless" version would mean another 4 versions of we want symmetry. This in a module that already has 150 functions.

My count of exported names is 97 (via ":browse Data.Map" inside ghci) Cheers Christian

We need to do something about the large amount of both API (i.e. usability tax) and implementation (maintainer overhead) duplication in the containers library. Throwing out functions that don't add much to expressibility* only gets us so far, but I think it's a step in the right direction.

* I appreciate that being able to use a "directionless" fold lets the author communicate his intent slightly better, but I think it's outweighed by the API growth and code duplication.

Johan