Drastic Prelude changes imminent

Wed Jan 28 17:52:25 UTC 2015

Here is the seed of the current actions w.r.t. generalizing the combinators
in Data.List.

http://osdir.com/ml/libraries@haskell.org/2013-05/msg00324.html

Notice how a few posts in I'd mentioned that if we could deprecate the
export it'd yield a better final state which I still happen to believe.

On Wed, Jan 28, 2015 at 12:35 PM, Edward Kmett <ekmett at gmail.com> wrote:

> On Wed, Jan 28, 2015 at 5:14 AM, Augustsson, Lennart <
> Lennart.Augustsson at sc.com> wrote:
>
>>  I've updated the Wiki page (
>> https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly)
>>
>> with what I think would be a sensible course of actions:
>>
>>
>>
>> Simon Marlow rightly points out that adding a new LANGUAGE pragma is full
>> of backwards compatibility problems.
>>
>> So, here's a different plan how to introduce BBP.
>>
>>
>>
>> * Leave Data.List type signatures and exports alone.
>>
>> * Make ghc 7.10 warn when Data.List has been imported in a way that will
>> break with BBP.
>>
>> * No changes to Prelude signatures, but ship ghc 7.10 with PreludeBBP
>> (which uses Foldable).
>>
>> * Make PreludeBBP the default in ghc 7.12 (or later).
>>
>>
>>
>> This will give us time to discuss exactly what should go into Foldable.
>>
>>
>>
>> The signature changes in Control.Monad and other modules are unrelated to
>> BBP and should be in ghc 7.10.
>>
>>
>>
>> The ghc warning for importing Data.List should be as helpful as possible,
>> something like:
>>
>> Foo:5:1  Warning: Data.List imported unqualified, this will conflict with
>> BBP.
>>
>>          Instead use 'import Data.List(maximumBy, sortBy)'
>>
>>
> Upon reflection, I am prepared to seriously consider this approach.
>
> There is an aspect of this proposal that I quite like.
>
> Deprecating the re-exports in Data.List and Control.Monad is definitely a
> good thing in the long term.
>
> There is, however,  a question of whether it makes more sense to leave the
> monomorphic combinators in Data.List that collide with the Prelude at all
> after such a deprecation cycle. The warning you give by way of example
> there says that 'importing this module unqualified will conflict with the
> BBP' on the other hand, looking forward at the state that results in the
> least long term confusion, we might prefer to say that if we import the
> module explicitly listing a combinator that is already exported by the
> Prelude but which will be generalized that it will conflict with the BBP.
>
> e.g. it is
>
> import Data.List (foldr)
>
> It seems to me that in the long term removing the redundant export
> entirely from base is the avenue that leads to the least confusion.
>
> I've been eyeballing deprecating the re-exports of combinators from the
> mtl for a long time, but have lacked a mechanism in the language for
> expressing it.
>
> Even if we don't implement the rest of the proposal, I would love to have
> the ability to express these things.
>
>
> *However,* I'd like you to seriously consider an alternative viewpoint,
> which is that I strongly believe that what you are asking for actually
> forces considerably more work for more people over the course of the next
> year for few reasons:
>
>
> 1.) A large number of folks have been proactive in responding to the
> release candidates for 7.10.1 by updating their packages to be 7.10-ready.
> Several hundred packages have already been patched and uploaded to hackage,
> most of the packages in stackage are 7.10 ready today.
>
> https://github.com/fpco/stackage/issues/378
>
> A significant subset of those would be broken by your proposal. This means
> that there would now be hundreds of packages on hackage by our most active
> contributors with broken versions that need to be manually made
> uninstallable by an arcane process using the package management tools.
>
>
> 2.) An _alarming_ amount of code imports Control.Monad and then uses mapM
> or imports Data.List unqualified. This is why we didn't remove those
> combinators or ask for tools for deprecating them earlier in 7.10. The
> deprecation cycle you are proposing affects easily an order of magnitude
> more code than the proposed changes in 7.10, and worse it is often the kind
> of code that is written by those least prepared to understand what is
> happening. This is why above, I mentioned that it might be better to
> consider a version of the proposal where the explicit import of a
> combinator we'd like to remove as a re-export is flagged.
>
>
>
> Ultimately the ability to deprecate a re-export would be useful as a way
> to mitigate future changes, even if we decided to let BBP roll on in 7.10
> due to issue #1 above. We could also apply it to Data.List and the
> re-exported combinators in Control.Monad (and those in the mtl) to get to a
> state where future language changes can go through something much closer to
> the process you have envisioned in this article.
>
>
> So as a concrete alternative proposal, I'd like to suggest that we
> consider:
>
> Shipping the BBP as planned.
>
> Adding to GHC the ability to complain if a given re-export is the only way
> a symbol finds its way into scope that you use, and apply those flags to
> Control.Monad.mapM and a bunch of combinators in Data.List.*.
>
> This would build a path that would enable us to in the future enact
> release plans closer to what you have here, but would avoid forcing a huge
> pile of double-work on all the folks who have already adapted their code.
>
>
> On the other hand, I'm happy to revisit through the libraries@ process if
> we want to head back to a 7.8-style Foldable. It strikes me, though, that
> the better time to do that would have been 3 months ago when we had long
> threads on the topic on the mailing list, rather than after the release
> candidate.
>
> If we did revisit the current design, it wouldn't come without a cost: If
> we do that it would means that a number of key combinators in Data.Foldable
> will necessarily change their stack behavior as they fold in different
> directions currently than the Prelude combinators.
>
> Adding the members enabled the [] instance to retain the current
> semantics, and allowed users who don't like the behavior of 'sum' and the
> like to fix it on a one-off basis on their own containers.
>
> It seems that pushing for such a change needs to reach a much higher bar
> of acceptance, as it results in existing code yielding different answers
> with very different stack behavior.
>
> -Edward
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/c1af0d06/attachment-0001.html>