Drastic Prelude changes imminent

[Edward Kmett]

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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/91e03d72/attachment.html>