You complain there's no return on investment, but you are wrong:
1. You can implement amap/amap and amap/coerce rules for each instance. These rules are simply unavailable in the current scheme because of the simplifier phase structure.
2. There's no law that an IArray implementation has to be based on an actual flat array in memory. One based on another data structure may well prefer a different sort of amap implementation. For example, you could make a Seq-based IArray instance that would want amap = fmap, preserving the structure instead of having to rebalance over and over and killing constant factors.
amap :: (IArray a e', IArray a e, Ix i) => (e' -> e) -> a i e' -> a i ethis looks like map. just with a class constraint. I dont buy that theres any ROI for putting it into the class at all.By the same arguement, map and fold in Vector should be part of the class.-1On Fri, Nov 14, 2014 at 4:30 PM, David Feuer <david.feuer@gmail.com> wrote:I realized what I wrote about amap earlier was utterly boneheaded, because it has the wrong type for fmap. The only way to accomplish my goal is to make Data.Array.IArray.amap a method of the IArray class. This will allow IArray instances to offer optimized versions and things like amap/coerce rules. The current implementation of amap can become the default one.
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries