The current step was to generalize them so that code that imported
Data.List so that they don't conflict with the Prelude versions.
The intent was that once we gained the ability to deprecate re-exports that
we'd remove them entirely. We now have a patch that enables us to do such
things.
It turns out that if you look at hackage, for the most part folks are
actually importing Data.List unqualified to bring into scope foldl' or
sort. Almost nobody invokes foldr from it.
The "generalization and subsequent re-export deprecation" path breaks less
code than the "leaving them monomorphic and breaking everyone who uses
Data.List unqualified" path, even if it leads to an intermediate state that
is a bit awkward, and doesn't lead easily to a final state where
monomorphic versions of those combinators are available.
-Edward
On Wed, Feb 4, 2015 at 11:13 AM, Christopher Done
Looking at the generalizations in Data.List I find them pretty odd now when I think about it. I'd expect Data.List functions to be monomorphic to lists, just like I expect functions in Data.Map to be monomorphic to maps. Now there might be generalized versions of these functions in e.g. the Prelude, but generalizing Data.List means that I don't even have the monomorphic versions available if I want to resolve ambiguity by using them*.
Sums up my feelings exactly. Data.Map, Data.List, etc. should be monomorphic. Adding generalized functions in Data.List is a little baffling. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries