Drastic Prelude changes imminent

[Johan Tibell]

On Wed, Feb 4, 2015 at 9:22 AM, Edward Kmett <ekmett at gmail.com> wrote:

> 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.
>

Wait, are we removing foldr from Data.List entirely?


>
> 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/fee3d5bd/attachment.html>