Proposal #3999: Improved folds for Data.Map and Data.IntMap

[Louis Wasserman]

>
> > {-# RULES

>

 > "foldr/Data.Map.elems" forall f z m . foldr f z (elems m) = foldr f z m;

 > "foldl/Data.Map.elems" forall f z m . foldl f z (elems m) = foldl f z m;

 > "foldr/Data.Map.keys" forall f z m . foldr f z (keys m) = foldrWithKey (\
> k _ -> f k) z m;

 > "foldl/Data.Map.keys" forall f z m . foldl f z (keys m) = foldlWithKey (\
> z k _ -> f z k) z m;

 > "foldr/Data.Map.toAscList" forall f z m . foldr f z (toAscList m) =
> foldrWithKey (curry f) z m;

 > "foldl/Data.Map.toAscList" forall f z m . foldl f z (toAscList m) =
> foldlWithKey (curry . f) z m; #-}

A few thoughts on this issue:

   - I've occasionally had problems getting inlining to actually happen,
   which is irritating.
   - Maintaining portability requires almost as much code for the
   preprocessor as the rules I wrote above, and is finicky at best.
   - Perhaps my biggest concern with that approach is that it doesn't play
   nicely with foldl, which came up in the application that motivated this
   proposal!  The rewrite rule approach I outline above is perfectly compatible
   with foldr/build rewriting, but also permits foldls to function nicely.

Louis Wasserman
wasserman.louis at gmail.com
http://profiles.google.com/wasserman.louis


Why not implement elems etc. in terms of build? This would make them play
> nicely with foldr/build fusion at no cost.
>
> Roman
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20100421/9f1eb861/attachment.html