Drastic Prelude changes imminent

Wed Jan 28 17:35:01 UTC 2015

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