On 2007-09-17, Dan Weston <[EMAIL PROTECTED]> wrote: > I noticed that there is no Data.Foldable context to your FoldableLL > class. How does your ListLike API work with/compare to/derive from the
At one point, I had declared that every instance of Data.Foldable to be an instance of FoldableLL. However, I had trouble making Data.Map into a Foldable instance in this way, because the standard library defines it to already be a Foldable instance. If memory serves, when I read the source for Data.Foldable, the "elements" if a Map were the keys only, while the Data.Map instance for ListLike (and FoldableLL) treats the "elements" as (key, value) pairs. Since that incorrect (for this application) instance of Data.Map was already in Data.Foldable, using Data.Foldable for this purpose was impossible. However, for some specific types, the FoldableLL instance may reuse Data.Foldable code if the implementor wants it. FoldableLL is very similar to Foldable, except it is essentially: class FoldableLL full item | full -> item where while Foldable is class FoldableLL full > classes in Data.Traversable? I believe it was the same problem. The functions exported by the ListLike module are a superset of Foldable. I also provide mapM and sequence in ListLike, which I think ought to do most of what Traversable does. I think there was also a "kind" problem with both. ListLike is to be useful for any type where there is a distinct container type and a distinct element type. For instance, you may have: instance ListLike [a] a where instance ListLike (Data.Map k v) (k, v) where I know it is possible to solve that, and in fact if you look at the history of my tree, you'll see where I had the Foldable instance... but with the Map problem, it just didn't seem worth it (or possible). That does show one annoying property of typeclasses: instances too easily appear and are impossible to replace. -- John _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell