<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 28, 2015 at 5:14 AM, Augustsson, Lennart <span dir="ltr"><<a href="mailto:Lennart.Augustsson@sc.com" target="_blank">Lennart.Augustsson@sc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">





<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">I've updated the Wiki page (<a href="https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly</a>)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">with what I think would be a sensible course of actions:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Simon Marlow rightly points out that adding a new LANGUAGE pragma is full of backwards compatibility problems.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">So, here's a different plan how to introduce BBP.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">* Leave Data.List type signatures and exports alone.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">* Make ghc 7.10 warn when Data.List has been imported in a way that will break with BBP.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">* No changes to Prelude signatures, but ship ghc 7.10 with PreludeBBP (which uses Foldable).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">* Make PreludeBBP the default in ghc 7.12 (or later).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">This will give us time to discuss exactly what should go into Foldable.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">The signature changes in Control.Monad and other modules are unrelated to BBP and should be in ghc 7.10.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">The ghc warning for importing Data.List should be as helpful as possible, something like:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">Foo:5:1  Warning: Data.List imported unqualified, this will conflict with BBP.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)">         Instead use 'import Data.List(maximumBy, sortBy)'<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u></span></p></div></div></blockquote><div><br></div><div>Upon reflection, I am prepared to seriously consider this approach. <br></div><div><br></div><div>There is an aspect of this proposal that I quite like.</div><div><br></div><div><div>Deprecating the re-exports in Data.List and Control.Monad is definitely a good thing in the long term.</div></div><div><br></div><div>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.</div><div><br></div><div>e.g. it is</div><div><br></div><div>import Data.List (foldr)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Even if we don't implement the rest of the proposal, I would love to have the ability to express these things.</div><div><br></div><div><br></div><div><b>However,</b> 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:</div><div><br></div><div><br></div><div>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.<br></div><div><br></div><div><a href="https://github.com/fpco/stackage/issues/378">https://github.com/fpco/stackage/issues/378</a><br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div>So as a concrete alternative proposal, I'd like to suggest that we consider:</div><div><br></div><div>Shipping the BBP as planned.</div><div><br></div><div>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.*.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div><div>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.</div></div><div><br></div><div>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.</div><div><br></div><div>-Edward</div></div></div></div>