Proposal: Non-allocating way to iterate over a Data.Map: traverseWithKey_

Milan Straka fox at ucw.cz
Tue Jul 30 17:32:44 CEST 2013


Hi Ryan,

> -----Original message-----
> From: Ryan Newton <rrnewton at gmail.com>
> Sent: 30 Jul 2013, 09:35
>
> > (!) adjust adjustWithKey alter delete empty findWithDefault foldl
> > foldl' foldlWithKey foldlWithKey' foldr foldr' foldrWithKey
> > foldrWithKey' insert insertLookupWithKey insertWith insertWithKey
> > lookup map mapAccum mapAccumRWithKey mapAccumWithKey mapMaybe
> > mapMaybeWithKey mapWithKey member notMember toList update
> > updateLookupWithKey updateWithKey
> >
> 
> So then this becomes a recommendation for the implementation strategy then
> right? (e.g. within containers)  Users probably still want a rich set of
> variants, and they need to be packaged somewhere.  But it seems like
> there's an argument that deriving these from a small core helps to ensure
> that there are no bugs.
> 
> Yet that sounds like a battle for another day.  On the topic of this
> proposal -- since Shachaf doesn't object, would you (Johan / Milan) mind
> merging this patch?

I would like to postpone merging for a bit and spend more time
investigating the issue.

I want to investigate why exactly
  foldrWithKey (\k a b -> f k a *> b) (pure ())
does not work as I would expect it not to allocate.

I am not convinced that traverseWithKey_ is a good addition to the API
because my original thought was "this is just a fold". The API of
containers has tendency to grow, so I am careful about adding functions
that can be expressed easily using existing ones.

Of course, ability to iterate effectively over the elements of the
containers definitely IS useful, so if I am unable to make the fold work
(or GHC optimizer cannot do it at present), I will merge it.

Cheers,
Milan




More information about the Libraries mailing list