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