<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Summarizing the discussion:<div class=""><br class=""></div><div class="">- Only a few have us have joined in. I'll take that as a signal that most don't have an opinion.</div><div class="">- There is some design wiggle-room. But there seem to be few strong opinions about how to set the knobs.</div><div class="">- Moritz is concerned about backward compatibility, given that there may not be wide knowledge in the community that -XLinearTypes is experimental.</div><div class=""><br class=""></div><div class="">While I agree it is regrettable that GHC itself has no built-in notion of "experimental", I'm not particularly moved by Moritz's concern here (sorry, Moritz!) -- I wager that LinearTypes is known to be pretty new and with sharp edges, and I'm pretty relaxed about changing it. We should prioritize cleaning this up so that we can be clearer in the future about what's experimental and what's not. To be clear, I think backward compatibility / stability is essential for GHC/Haskell, but I also think that until we have these notions baked into GHC (which we should do post-haste), we can use our judgement to determine that this change would not violate most users' assumptions of stability.</div><div class=""><br class=""></div><div class="">I'd like to declare this proposal accepted-modulo-tweaks. That is, I'd like to say that we'll accept this proposal, with the understanding that Arnaud and I will work out any remaining design details (as discussed in this thread), including a clear, unambiguous bit of documentation in the user manual and an update proposal. The patch implementing this change (already merged!) has some documentation, but it doesn't accurately reflect the implementation, and so a further patch will be necessary. I can review that further patch, focusing on the documentation piece.</div><div class=""><br class=""></div><div class="">Any objections to this plan?</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Richard</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 25, 2024, at 3:07 AM, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" class="">moritz.angermann@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Arnaud, I agree that _we_ consider LinearTypes experimental. I hope we can get <a href="https://github.com/ghc-proposals/ghc-proposals/pull/617" class="">https://github.com/ghc-proposals/ghc-proposals/pull/617</a> agreed on soon, so that the compiler has<div class="">this knowledge as well. I am however not able to fully comprehend the technical details of this proposal right and therefore will defer to others on this!</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 25 Jan 2024 at 16:01, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" class="">arnaud.spiwack@tweag.io</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">Moritz: there's one breakage introduced (but only for users of LinearTypes, which is considered experimental), namely that LinearTypes is proposed to now imply MonoLocalBinds.<br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 25 Jan 2024 at 07:18, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" target="_blank" class="">moritz.angermann@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class="">I'll have to recuse myself from this, as much of this is currently going above my head. My overall understanding is that<div class="">this mostly relaxes what we accept, and therefore won't break existing code?</div><div class=""><br class=""></div><div class="">Best,</div><div class=""> Moritz</div><div class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 25 Jan 2024 at 00:39, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank" class="">arnaud.spiwack@tweag.io</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div dir="ltr" class="">On Wed, 24 Jan 2024 at 16:39, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank" class="">simon.peytonjones@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><div style="font-family:tahoma,sans-serif" class=""><div class="">Do newtypes make a difference? E.g let N x = e in ...</div><div class="">where N is the data contructor of a newtype?</div></div></div></blockquote><div class=""><br class=""></div>I don't think it has too. So for the moment, I vote to stick to the current proposal and consider this like all lazy non-variable patterns: must be unrestricted.</div><div class="gmail_quote"><br class=""></div><div class="gmail_quote">I suspect that there's a possible refinement where we say that a happy pattern is either:</div><div class="gmail_quote">- A variable</div><div class="gmail_quote">- Strict</div><div class="gmail_quote">- A newtype constructor where the inner pattern is happy.</div><div class="gmail_quote"><br class=""></div><div class="gmail_quote">(then if pat is an unhappy pattern, `let pat` must be unrestricted).</div><div class="gmail_quote"><br class=""></div><div class="gmail_quote">But I don't think I'm quite ready to go there for the time being, and that'll be a backward compatible change if we change our mind.<br class=""></div></div>
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
</blockquote></div><br clear="all" class=""><br class=""><span class="gmail_signature_prefix">-- </span><br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class="">Arnaud Spiwack<br class="">Director, Research at <a href="https://moduscreate.com/" rel="noopener noreferrer" target="_blank" class="">https://moduscreate.com</a> and <a href="https://tweag.io/" rel="noopener noreferrer" target="_blank" class="">https://tweag.io</a>.</div></div>
</blockquote></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></body></html>