<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>