<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 22, 2015 at 12:20 PM, Mario Blažević <span dir="ltr"><<a href="mailto:mblazevic@stilo.com" target="_blank">mblazevic@stilo.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">On 15-10-22 09:29 AM, Geoffrey Mainland 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">
...<span class=""><br>
<br>
1) What is the master plan, and where is it documented, even if this<br>
document is not up to the standard of a proposal? What is the final<br>
target, and when might we expect it to be reached? What is in the<br>
pipeline after MRP?<br>
<br>
Relatedly, guidance on how to write code now so that it will be<br>
compatible with future changes helps mitigate the stability issue.<br>
</span></blockquote>
<br>
I have been fully in favour of all the proposals implemented so far, and I think that having an explicit master plan would be a great idea. It would address some of the process-related objections that have been raised, and it would provide a fixed long-term target that would be much easier to make the whole community aware of and contribute to.<br>
<br>
For that purpose, the master plan should be advertised directly on the front page of <a href="http://haskell.org" rel="noreferrer" target="_blank">haskell.org</a>. Once we have it settled and agreed, the purpose of the base-library commitee would essentially become to figure out the details like the timeline and code migration path. One thing they wouldn't need to worry about is whether anybody disagrees with their goals.<span class=""><br>
<br>
<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">
2) How can I write code that makes use of the Prelude so that it will<br>
work with every new GHC release over the next 3 years? 5 years? For<br>
example, how can I write a Monad instance now, knowing the changes that<br>
are coming, so that the instance will work with every new GHC release<br>
for the next 3 years? 5 years? If the answer is "you can't," then when<br>
might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to<br>
say I don't know the answer!<br>
</blockquote>
<br></span>
From the discussions so far it appears that the answer for 3 years (or at least the next 3 GHC releases) would be to write the code that works with the current GHC and base, but this policy has not been codified anywhere yet. Knowing the upcoming changes doesn't help with making your code any more robust, and I think that's a shame. We could have a two-pronged policy:<br>
<br>
- code that works and compiles with the latest GHC with no *warnings* will continue to work and compile with no *errors* with the following 2 releases, and<br>
- code that also follows the forward-compatibility recommendations current for that version of GHC will continue to work and compile with no *errors* with the following 4 releases.<br></blockquote><div><br></div><div>We have adopted a "3 release policy" facing backwards, not forwards. However, all proposals currently under discussion actually meet a stronger condition, a 3 release policy that you can slide both forward and backwards to pick the 3 releases you want to be compatible with without using CPP. It also appears that all of the changes that we happen to have in the wings<br><br><a href="https://ghc.haskell.org/trac/ghc/wiki/Status/BaseLibrary">https://ghc.haskell.org/trac/ghc/wiki/Status/BaseLibrary</a></div><div><br></div><div>comply with both of your goals here. However, I hesitate to say that we can simultaneously meet this goal and the 3 release policy facing backwards _and_ sufficient notification in all situations even ones we can't foresee today. As a guideline? Sure. If we have two plans that can reach the same end-goal and one complies and the other doesn't, I'd say we should favor the plan that gives more notice and assurance. However, this also needs to be tempered against the number of years folks suffer the pain of having in an inconsistent intermediate state. (e.g. having generalized combinators in Data.List today)</div><div><br></div><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">
The forward-compatibility recommendations would become a part of the online GHC documentation so nobody complains they didn't know about them. Personally, I'd prefer if the recommendations were built into the compiler itself as a new class of warnings, but then (a) some people would insist on turning them on together with -Werror and then complain when their builds break and (b) this would increase the pressure on GHC implementors.</blockquote><div> </div><div>The current discussion is centering around adding a -Wcompat flag that warns of changes that you maybe can't yet implement in a way that would be backwards compatible with a 3 release backwards-facing window, but which will eventually cause issues.</div><div><br></div><div>-Edward</div></div></div></div>