There were several fixes offered:

1.)  Data.List could cease to re-export Prelude types

This would work, but it would cause code breakage.

2.) Data.List could export monomorphic types, while the Prelude types could be generalized.

Now everyone who imports Data.List would get conflicts with Prelude types, causing code breakage.

3.) Data.List could continue to needlessly re-export Prelude types but have those generalized to match the Prelude.

This is the only option where existing code more or less universally continues to work. 

We can't actually deprecate a re-export at present, so we don't have a path to #1 at the moment, but it'd be a more ideal situation in the long run.

-Edward

On Tue, Jan 27, 2015 at 11:03 AM, Johan Tibell <johan.tibell@gmail.com> wrote:
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*.

* It turns out resolving ambiguity is pretty annoying. The type signatures are awkward to write so I end having to write something akin to

    mymap :: (a -> b) -> [a] -> [b]
    mymap = map


_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries