First of all, thank you to everyone who has volunteered to help/maintain the Data.Set/Map/etc code. I believe that standard and *stable* libraries for basic data structures are very important to the community, and encourage any improvements or changes to the code. I agree that the whole show/read part of the library is not well thought out -- I guess there should be the standard read/show instances together with some pretty show functions for debugging/education. However, keep in mind that the goal and design of the Data.Set/Map/etc structures were to be a stable and complete concrete design of data structures with documented worst-case time complexity. It was not designed as a general data structure interface that could accommodate many different implementations. i.e.
What exactly does prohibit the use of a class here? What about the class design of Edison (I admit I never used it). http://www.haskell.org/ghc/docs/edison/users004.html#toc3
That is why I think that we should not use classes or anything fancy here. The design of a proper general data structure interface is desirable and a very interesting challenge, but it should belong in a different module/library (Data.Generic.Set, Data.Edison, ?) that perhaps uses Data.Set/Map/etc, or Adrian's AVL modules to provide implementations. All the best, -- Daan. ps. Just to be clear, the code does not belong to me any more and the libraries are free to use and modify, and I wouldn't mind at all if someone wants to take a different direction with it (especially since I can not contribute myself anyway :-). In general, I think it should be easier for everyone to contribute code to the library base. This was one of the discussion topics at the Haskell workshop and I think this is a good case where it seems to be difficult to contribute easily: there seemed to be many people that had their own read instances but weren't able to add this code to the standard libraries -- I am all for anarchy and fun ;-) and I think the libraries would be better because of it. Maybe we should think about how patches could be easily contributed -- should we move over to darcs for the standard library code? Together with clear instructions on how to send in patches? -- maybe even allow everyone to just commit...
IMHO the use of interfaces (instead of relying on the discipline of library writers and users) is the important step forward from the collections framework of STL (C++) to that of Java.
We certainly don't want to fall behind that, or if we do, we need to have very good reasons.