<html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">+1 from me also<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 12 Feb 2024, at 22:29, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>I support this.</div><div><br></div><div>Simon <br></div>
</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 12 Feb 2024 at 15:02, Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</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 style="overflow-wrap: break-word;">Summarizing the discussion:<div><br></div><div>- Only a few have us have joined in. I'll take that as a signal that most don't have an opinion.</div><div>- There is some design wiggle-room. But there seem to be few strong opinions about how to set the knobs.</div><div>- Moritz is concerned about backward compatibility, given that there may not be wide knowledge in the community that -XLinearTypes is experimental.</div><div><br></div><div>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><br></div><div>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><br></div><div>Any objections to this plan?</div><div><br></div><div>Thanks,</div><div>Richard</div><div><div><br><blockquote type="cite"><div>On Jan 25, 2024, at 3:07 AM, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Arnaud, I agree that _we_ consider LinearTypes experimental. I hope we can get <a href="https://github.com/ghc-proposals/ghc-proposals/pull/617" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/617</a> agreed on soon, so that the compiler has<div>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><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" target="_blank">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">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></div><br><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">moritz.angermann@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">I'll have to recuse myself from this, as much of this is currently going above my head. My overall understanding is that<div>this mostly relaxes what we accept, and therefore won't break existing code?</div><div><br></div><div>Best,</div><div> Moritz</div><div></div></div><br><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">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">On Wed, 24 Jan 2024 at 16:39, 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"><div style="font-family:tahoma,sans-serif"><div>Do newtypes make a difference? E.g let N x = e in ...</div><div>where N is the data contructor of a newtype?</div></div></div></blockquote><div><br></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></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></div><div class="gmail_quote">(then if pat is an unhappy pattern, `let pat` must be unrestricted).</div><div class="gmail_quote"><br></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></div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><br><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>
</blockquote></div>
_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br></div></blockquote></div><br></div></div>_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
_______________________________________________<br>ghc-steering-committee mailing list<br>ghc-steering-committee@haskell.org<br>https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br></div></blockquote></div><br></body></html>