ANN: ListLike, a generic interface over list-like structures
Hi, I'm pleased to announce the first release of ListLike, a generic interface to the various list-like structures in Haskell. This grew out of the annoyance at having to handle Strings and ByteStrings differently in my code, and has expanded on well past there. ListLike implements an API very similar to Data.List, but based on a typeclass. The module ships with instance definitions for lists, ByteStrings, lazy ByteStrings, Arrays, and even Maps. Additional classes are available for types that implement some additional features: String-like behavior, infinite list capability, and I/O. Finally, an extensive set of default functions is provided. Only minimal effort -- as little as four functions -- are needed to make your list-like type an instance of ListLike. ListLike is backed by an extensive suite of QuickCheck tests wrapped in HUnit, which tests virtually every function against every type. As of right now, 1567 test cases are executed, and all pass. Homepage: http://software.complete.org/listlike/ Download from: http://software.complete.org/listlike/downloads API ref: http://software.complete.org/listlike/static/doc/ Hackage page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ListLike-1.0.0 -- John
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 classes in Data.Traversable? http://darcs.haskell.org/ghc-6.6/packages/base/Data/Traversable.hs Dan Weston John Goerzen wrote:
Hi,
I'm pleased to announce the first release of ListLike, a generic interface to the various list-like structures in Haskell.
This grew out of the annoyance at having to handle Strings and ByteStrings differently in my code, and has expanded on well past there.
ListLike implements an API very similar to Data.List, but based on a typeclass. The module ships with instance definitions for lists, ByteStrings, lazy ByteStrings, Arrays, and even Maps.
Additional classes are available for types that implement some additional features: String-like behavior, infinite list capability, and I/O.
Finally, an extensive set of default functions is provided. Only minimal effort -- as little as four functions -- are needed to make your list-like type an instance of ListLike.
ListLike is backed by an extensive suite of QuickCheck tests wrapped in HUnit, which tests virtually every function against every type. As of right now, 1567 test cases are executed, and all pass.
Homepage: http://software.complete.org/listlike/
Download from: http://software.complete.org/listlike/downloads
API ref: http://software.complete.org/listlike/static/doc/
Hackage page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ListLike-1.0.0
-- John _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
On 2007-09-17, Dan Weston <westondan@imageworks.com> 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
On 9/17/07, John Goerzen <jgoerzen@complete.org> wrote:
That does show one annoying property of typeclasses: instances too easily appear and are impossible to replace.
The problem would be solved if it was possible to explicitly import and export instance declarations. I asked this before [1] but I actually almost never had the need for it. But then I'm not a library writer... It would be nice to know how serious this problem is. Are there other people that have had a similar problem? Thanks, Bas [1] http://www.haskell.org/pipermail/haskell-prime/2006-November/001843.html
On Monday 17 September 2007 6:14:57 pm Bas van Dijk wrote:
On 9/17/07, John Goerzen <jgoerzen@complete.org> wrote:
That does show one annoying property of typeclasses: instances too easily appear and are impossible to replace.
The problem would be solved if it was possible to explicitly import and export instance declarations.
I asked this before [1] but I actually almost never had the need for it. But then I'm not a library writer...
It would be nice to know how serious this problem is. Are there other people that have had a similar problem?
I have also been annoyed by this with instances of Read and Show. In several situations, I preferred to have my own formatter or parser, and it would have been most convenient to do so as a different instance of Read or Show. However, I would not say that it has ever been a serious problem. Workarounds exist, such as creating new typeclasses or simply using dedicated functions. It would be nice if there were some syntax where you could say something along the lines of instance (Show a, a /= Integer) => MyShow a where myshow = show instance MyShow Integer where myshow = customshow for example. -- John
participants (3)
-
Bas van Dijk -
Dan Weston -
John Goerzen