| One could possibly argue that the right solution is to | put the operations in classes?
The problem is that sometimes the type of an operation on a particular data structure is not completely according to the general structure. There might be extra restrictions on the type arguments for example (think of Set.map), or there might be an extra argument required or something. Nothing that stops you from having the same name! Also, I think the existence of a possibly better solution (using type classes) is no argument of having names like mapSet and newIORef all over the place. BTW, I realize that it is not easy to change the names of existing libraries, even if their naming scheme is horribly inconsistent, with Data.FiniteMap and Data.Set as good (?) examples. But there is no reason to make a fresh start when designing the naming scheme *standard* for (new) libraries. Why is the naming scheme standard, described at: http://www.haskell.org/hierarchical-modules/libraries/library-design.html still using Haskell 1.2 naming schemes? Do people simply not like qualified names? | There has from time to time been suggestions and | discussion about doing this, but I guess there are | significant obstacles -- surely, somebody must have tried | to clean this up? I think Chris Okasaki did a nice job and made a good data structure library proposal with Edison (years ago). It uses both the qualified names trick and type classes. Why nobody uses it (or even knows about it) is a mystery to me. (The reason Chris gave himself is that he did not completely populate his data structure library framework and that people rather implement their own data structures then instead of fitting them into his framework.) Hereby, I call for a revival of Edison! :-) Regards, /Koen _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell