Proposal: keep Data.Map.foldWithKey

[Christian Maeder]

Am 15.12.2010 15:38, schrieb Johan Tibell:
> Hi all,
> 
> On Tue, Dec 14, 2010 at 1:28 PM, Christian Maeder
> <Christian.Maeder at dfki.de> 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