Philippa Cowderoy wrote: > On Mon, 17 Sep 2007, Adrian Hey wrote: >> Ideally the way to deal with this is via standardised interfaces (using >> type classes with Haskell), not standardised implementations. Even this >> level of standardisation is not a trivial clear cut design exercise. >> e.g we currently have at least two competing class libs, Edison and the >> collections package. Which one should become standard? > > They shouldn't, at least not now. Knock up something lightweight that'll > do for now for each of the modules that're going to be standard, worry > about overarching frameworks later. Realistically we need a standardised > name which we can expect to find an implementation under, with some > performance guarantees even if they're the worst possible ones we can > make.
I am using the collections package on a regular basis, and I am quite satisfied. (I have no experience with Edison so I can't compare them.) The main advantage of a framework such as the collections package offers is that the code becomes a lot more flexible. First, it is easier to experiment with different implementations. In one application I wrote, you can switch from Data.Collections.StdMap (whose implementation is the familiar Data.Map) to e.g. Data.Collections.AvlMap by changing exactly /one/ line of code (of a total of about 1500 in 8 modules). No need to change any of the import declarations, no change in type signatures, nothing. Also, many functions, even whole classes, can be written more polymorphically and thus easier to use in situations other than what they were planned for; you can specify exactly the API that is needed and no more which strengthens static typing. The main disadvantage is that it can become quite hard to understand type errors, which often don't give me any clue what the /cause/ of the problem is. (This might be unavoidable, due to the level of polymorphism, I don't know.) In the end, I think something similar to the collections package should become 'standard' in the sense of getting distributed with the main Haskell implementations. This would encourage more people to try and use them, so we'd gather more experience and would be able to eliminate shortcomings sooner rather than later. Cheers Ben _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe