<div dir="ltr"><div dir="ltr">On Fri, 13 Oct 2023 at 11:53, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:tahoma,sans-serif">
But here's the thing: I claim that GR{1-3} aren't going to solve the 
stability problem. I'm confident about this because they're already the 
policy. And while it's not entirely impossible to imagine that writing 
them down more prominently will solve the problems that we have, I don't
 believe we should count on it.

</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif">I agree.  They won't solve it.   (Incidentally, it's not just GR{1-3} but also the categorisation into stable/experimental, which GR{1-3} is predicated on.)   But I think they will help.  You are sceptical, but that's fine.  We'll see.  Provided they are not harmful [and I don't think you are saying that it is] we can just adopt them and move on.<br></div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Completely-solving a complex, multi-faceted problem is hard.   But that should not discourage us from making incremental progress towards that goal.</div></div></blockquote><div><br></div><div>I think there's a misunderstanding here, maybe it's due to the limitation of text communication, or maybe I'm just expressing myself very badly. I'm absolutely fine with enshrining GR{1-3}. I don't think there has been any discussion about them apart from minor rewordings.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:tahoma,sans-serif">   The base-library splitting proposal (now agreed) is another piece of incremental progress that does not solve the problem, but will help.</div></div></blockquote><div><br></div><div>I'm not confident about that. Last week, I even thought of a way it could hurt. We chose to name a bunch of things “Experimental” (rather than, say, GHC-specific), this carries the following risk: if features stay in the ghc-experimental package for too long, they may very well become part of “normal Haskell”. Programmers will start depending on it and will be habituated to understand that “experimental” really means “stable”, and we'll lose all the benefits of the scary warning on the tin. We need a very tight process if we're to make this work at all.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:tahoma,sans-serif">I am not against (in addition) trying to identify particularly painful problems in the past, and seeing what their root causes were.  I just don't want to de-rail making incremental progress at the same time.</div></div></blockquote><div><br></div><div>I sincerely hope I'm not doing that.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:tahoma,sans-serif"></div><div style="font-family:tahoma,sans-serif"></div><div style="font-family:tahoma,sans-serif">I don't like to see you unhappy, Arnaud!<br></div></div></blockquote><div><br></div><div>Haha :D  Thanks. You know what, I don't like seeing me unhappy either! (but I'm not in this particular case)<br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Oct 2023 at 13:23, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">It's
 already the policy in the sense that when we break stuff, we generally 
have a deprecation cycle. But where GR2 diverges from the current 
(informal) policy is in judging when it's OK to make a breaking change. 
GR2 - at least in my interpretation of it, and perhaps we should make 
this clearer - requires that to make a breaking change we have to be 
forced somehow. Because there's a bug that needs fixing, or because the 
current behaviour is broken for some reason. We're not going to make a 
breaking change just because the change would make things better, even 
with a deprecation cycle: those kinds of changes will still be possible,
 but they'll go behind a new language extension flag and/or into the 
next GHC20xx, so the user has control over when they have to adapt their
 code.</div></div></blockquote><div><br></div><div> Maybe, though I actually don't have evidence that we've broken this policy, new or not, in the past. I hope you're right of course. Certainly a (somewhat implicit but real) change that has been brought by the conversations of the past few weeks is a reinforcement of the role of the GHC20xx languages. Let's see how much we can lean on this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>It's probably true that a majority of the backwards compatibility 
issues encountered with a GHC upgrade come from changes in third-party 
packages. But in order to decouple the compiler upgrade from package 
upgrades, we have to make all the existing packages compile with the new
 GHC, so stability has to start with GHC itself.</div></div></blockquote><div><br></div><div>This gives support to Adam's idea of a reinstallable base.</div><div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>Incidentally
 I'd like the stability policy to be extended to compiler and runtime 
flags - i.e. don't gratuitously change the behaviour of existing flags 
or remove them. Extend stability to build systems, not just code. This 
is much harder than language changes because we don't have extensions or
 GHC20xx, but we can do deprecation cycles.</div></div></div></blockquote></div></div></div></div></div><div><br></div><div>This is reasonable, but do you have evidence that it's ever been a problem in the past?<br></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div></div>