<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 class="gmail_default" 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" class="gmail_default">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" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Completely-solving a complex, multi-faceted problem is hard.   But that should not discourage us from making incremental progress towards that goal.   The base-library splitting proposal (now agreed) is another piece of incremental progress that does not solve the problem, but will help.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">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.   <br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I don't like to see you unhappy, Arnaud!<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Oct 2023 at 10:38, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</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"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Oct 2023 at 11:16, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@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"><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">
 The mandate here is “make Haskell more stable” which is quite commendable, but it's also very imprecise

</div></blockquote><div><span class="gmail_default" style="font-family:tahoma,sans-serif"></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif">Is it imprecise?  I think our goal is pretty simple:<b> a program that compiles and runs with GHC 9.8 should also compile and run with GHC 9.10.</b>  That's it.   I think you subscribe to this as a general goal?<br></span></div></div></blockquote><div><br></div><div>I fully subscribe to this goal.<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><span class="gmail_default" style="font-family:tahoma,sans-serif"></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif"></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif">Clearly that is a problem today: many users report that they are using years-old GHCs because the cost of upgrading to the latest version is so high.</span></div></div></blockquote><div><br></div><div>Indeed.<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><span class="gmail_default" style="font-family:tahoma,sans-serif"></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif">The General Rules I suggested at the start of this thread do no more than articulate that goal, and give some general principles that we seek to follow.  I think that does no more than make <i>explicit </i>our <i>implicit </i>way of working (we spend a lot of time on back-compat discussions).  That is, nothing really new here, just making it more explicit.<br></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:tahoma,sans-serif">Can you be more specific about what you don't like?</span></div></div></blockquote><div><br></div>The general rules are perfectly reasonable. I'm much less enthusiastic about an `experimental` flag of sorts.</div><div class="gmail_quote"><br></div><div class="gmail_quote">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. So anyway, we've been having this policy, have we failed to apply it? Why? Or maybe the reason why stability is a concern is because of reasons that aren't caught by this policy, then what is missing? I'm asking these questions in earnest: I really don't know. And I don't think we'll actually make significant progress without getting answers to these questions.<br></div></div>
</blockquote></div>