Drastic Prelude changes imminent

[Edward Kmett]

The original intent had been to have a discussion about deprecating the
generalized combinators in Data.List in 7.12 and removing them in 7.14 once
we had the ability to deprecate a re-export.

This path gives a 2 year window for the much smaller pool of users who
import Data.List qualified and also use List.foldr to drop "List." from
their code, and a way to gracefully provide warnings, without immediately
breaking the larger pool of users who import Data.List unqualified and just
reach for members that aren't in the Prelude and rely on the lack of
conflicts today.

I don't see a path that results in monomorphic members of Data.List for
those particular combinators that doesn't require a sharp shock in which a
bunch of code breaks for a large pool of users without us being able to
warn them first.

-Edward



-Edward

On Wed, Feb 4, 2015 at 12:05 PM, Johan Tibell <johan.tibell at gmail.com>
wrote:

>
>
> On Wed, Feb 4, 2015 at 9:01 AM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> 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.
>>
>
> I didn't quite follow this. Does this mean that the Data.List functions
> will be generalized for now but eventually monomorphized again?
>
>
>>
>> -Edward
>>
>> On Wed, Feb 4, 2015 at 11:13 AM, Christopher Done <chrisdone 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*.
>>>
>>> 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 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/20150204/773ebab8/attachment.html>