<div dir="ltr">Hi Richard,<div><br></div><div>My feeling is that "what to allow re: IO/ST/PrimMonad" is can be changed later if needed. From a minimality perspective, yes, IO and ST may be subsumed by a more generic form. But I think they are probably pretty important as convenience features. (And from the perspective of IO being a PrimMonad, it's just a specialization of an already valid type, which seems pretty reasonable.)</div><div><br></div><div>I was also concerned about a syntactic check, e.g. problems with type synonyms. Simon M's response was here:</div><div><a href="https://github.com/ghc-proposals/ghc-proposals/pull/8#issuecomment-315449267">https://github.com/ghc-proposals/ghc-proposals/pull/8#issuecomment-315449267</a></div><div><br></div><div><br></div><div>-Ryan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 16, 2018 at 2:42 PM, Richard Eisenberg <span dir="ltr"><<a href="mailto:rae@cs.brynmawr.edu" target="_blank">rae@cs.brynmawr.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I have not followed the discussion on this one, but I have a clarifying question:</div><div><br></div><div>- The proposal describes the shape of the mutable constructors very concretely, offering the PrimMonad formulation separate from IO and ST. However, doesn't the PrimMonad case subsume IO and ST? That is, couldn't we remove the points about IO and ST? Or is the check very syntactic and require one of those concrete syntactic shapes?</div><div><br></div><div>Otherwise, I'm not very knowledgeable about this end of the operation. I'll go with the consensus opinion on this.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Richard</div></font></span><div><div class="h5"><br><div><blockquote type="cite"><div>On Feb 14, 2018, at 1:49 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>> wrote:</div><br class="m_-6337073319781760449Apple-interchange-newline"><div><div dir="ltr"><div>Perhaps, although I am not sure it is really worth the extra effort. I think if we agree to accept this (which I hope we do), we can just implement it as intended. I have some work hours that I've put aside to work on this, once it is properly approved.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Feb 12, 2018 at 9:29 AM Ryan Newton <<a href="mailto:rrnewton@gmail.com" target="_blank">rrnewton@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ah, I see, does it make sense for it to be implemented "frontend only" first, with it desugaring into the current MutVar# primitives in the backend?<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 12, 2018 at 12:24 PM, Iavor Diatchki <span dir="ltr"><<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I support this. <div><br></div><div>The status of the implementation, at least on my end. is stalled a bit, as I've been really busy with work. Overall though, Ryan has a version that works for STM (although it is against an older GHC and mixed up with other experiments he is working on). I also have a branch, where we've implemented the basic primitives, and started work on the front-end, but there is quite a bit to do still (e.g., we haven't really done code the code generation changes). I'd say there are a bunch of interesting implementation questions that we need to answer, but in terms of the user-facing language changes, the proposal seems sound to me.</div></div><br><div class="gmail_quote"><div><div class="m_-6337073319781760449m_-2716427062567210055h5"><div dir="ltr">On Mon, Feb 12, 2018 at 9:13 AM Ryan Newton <<a href="mailto:rrnewton@gmail.com" target="_blank">rrnewton@gmail.com</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-6337073319781760449m_-2716427062567210055h5"><div dir="ltr"><div>Reboot! This has long sat idle, but I propose to now formally start the committee discussion period: mandatory 4 weeks, closing at end of day <b>March 10th</b>, or earlier if consensus occurs. Let's use this email thread for that discussion. In this mail I summarize public discussion and <b>argue for "accept"</b>.<br></div><div><br></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">In short, <span id="m_-6337073319781760449m_-2716427062567210055m_-9195740632752032102m_-5664814179703483304goog_1240068977"></span>the proposal <span id="m_-6337073319781760449m_-2716427062567210055m_-9195740632752032102m_-5664814179703483304goog_1240068978"></span>adds a way to have multiple mutable fields within a data-constructor, without the indirection of using IORef. </span>Second to <a href="https://github.com/ghc-proposals/ghc-proposals/pull/91" target="_blank">"linear types"</a>, <a href="https://github.com/ghc-proposals/ghc-proposals/pull/8" target="_blank">this proposal</a> generated the most total comments during public discussion (107). This level of discussion was good -- given that accepted GHC proposals so far are mostly syntactic (or API tweaks), this would be the first with major compiler backend & runtime consequences. </div><div><br></div><div>Ed Kmett and Ryan Yates have demonstrated the applicability of this concept to data-structure implementation. (Indeed, I think there's a good reason that almost all languages mutation with mutation are implemented so as to allow a single heap object to have multiple mutable fields within it.) During the public discussion, questions were raised about interactions with other features and implementation strategy -- in particularly changes to core. But I believe that all major concerns were eventually answered.</div></div><div dir="ltr"><div><br></div><div> -Ryan</div></div><div dir="ltr"><div><br></div><div>P.S. Iavor, Trevor, and Ryan Yates were all working on implementation of this feature at various points. Not sure what the current status of implementation efforts are.</div></div><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Committee,<br>
<br>
this is your secretary speaking:<br>
<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/8" rel="noreferrer" target="_blank">https://github.com/ghc-<wbr>proposals/ghc-proposals/pull/8</a><br>
was brought before the committee, by our own Simon Marlow.<br>
<br>
I propose Ryan Newton as the Shepherd, because he asked for it :-)<br>
<br>
Ryan, please reach consensus as described in<br>
<a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank">https://github.com/ghc-<wbr>proposals/ghc-proposals#<wbr>committee-process</a><br>
<br>
I suggest you make a recommendation about the decision, maybe point out<br>
debatable points, and assume that anyone who stays quiet agrees with<br>
you.<br>
<br>
<br>
Greetings,<br>
Joachim<br>
<span class="m_-6337073319781760449m_-2716427062567210055m_-9195740632752032102m_-5664814179703483304m_-8292464738700205453HOEnZb"><font color="#888888"><br>
<br>
--<br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.<wbr>de/</a><br>
</font></span></blockquote></div><br></div></div></div></div>
______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@<wbr>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-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
</blockquote></div>
</blockquote></div><br></div>
</blockquote></div>
______________________________<wbr>_________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@<wbr>haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div>