RE: collections in hierarchical libraries

No one seems to support Edison. However, there is an important difference between Edison and DData: DData provides implementations of specific structures, while Edison tried to provide general collection interfaces *and* implementations. I believe that designing good generic collection interfaces is very hard and may even be impossible to do "right" in current Haskell's. So, I guess we will be stuck with concrete data structures for a while :-)
I second Daan's opinion here. The Haskell community has been searching for good generic collection interfaces for a while and hasn't come up with anything that is obviously the right thing. In the meantime we're stuck with poor data structure support because everyone is waiting for the wonderful generic collection library to come along. Having a well-designed and consistent concrete data structure library is certainly a lot better than nothing. Indeed, it would be more useful in a sense because the barrier to adoption would be low, and it wouldn't have an impact on the existing libraries. If such a thing were to materialise, I'm sure we'd import it into the hierarchical libraries that are shipped with GHC, Hugs & nhc98. Perhaps DData is pretty close to what we're after. Would the interested parties care to thrash out the details and present it to the wider community for comments? Cheers, Simon

In article
<3429668D0E777A499EE74A7952C382D10157C485@EUR-MSG-01.europe.corp.microso
ft.com>,
"Simon Marlow"
I second Daan's opinion here. The Haskell community has been searching for good generic collection interfaces for a while and hasn't come up with anything that is obviously the right thing.
I think that's because the "right thing" involves non-98 extensions (specifically, multiparameter type classes)... -- Ashley Yakeley, Seattle WA

Ashley Yakeley wrote:
I second Daan's opinion here. The Haskell community has been searching for good generic collection interfaces for a while and hasn't come up with anything that is obviously the right thing.
I think that's because the "right thing" involves non-98 extensions (specifically, multiparameter type classes)...
I strongly disagree with this opinion. OPAL has a very good/rich library without fancy extensions. http://uebb.cs.tu-berlin.de/~opal/ocs/doc/html/BibOpalicaManual/BibOpalicaMa... It's more a question of writing it all up consistently. The DData stuff from Daan is a good start: Consistent namings, possibly using qualified imports. Simply add a further structuring level (like "SetLike" and "MapLike" form OPAL) for various set and map implementations. "SetLike" is based on "TreeLike" for sets by binary search trees. "MapLike" is based "SetLike" in order to return a set as the domain of a map. (The Haskell module Data.Set is quite odd as it is based on Data.FiniteMap, thus implementing _finite_ sets.) We also used to have "GraphLike" stuff (based on "MapLike"), but that was never elaborated into presentable details. Maybe Erwigs FGL could take the place of "GraphLike". Cheers Christian
participants (3)
-
Ashley Yakeley
-
Christian Maeder
-
Simon Marlow