<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I have not followed the discussion on this one, but I have a clarifying question:</div><div class=""><br class=""></div><div class="">- 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 class=""><br class=""></div><div class="">Otherwise, I'm not very knowledgeable about this end of the operation. I'll go with the consensus opinion on this.</div><div class=""><br class=""></div><div class="">Richard</div><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 14, 2018, at 1:49 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" class="">iavor.diatchki@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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 class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Feb 12, 2018 at 9:29 AM Ryan Newton <<a href="mailto:rrnewton@gmail.com" class="">rrnewton@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">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 class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Feb 12, 2018 at 12:24 PM, Iavor Diatchki <span dir="ltr" class=""><<a href="mailto:iavor.diatchki@gmail.com" target="_blank" class="">iavor.diatchki@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I support this. <div class=""><br class=""></div><div class="">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 class=""><div class="gmail_quote"><div class=""><div class="m_-2716427062567210055h5"><div dir="ltr" class="">On Mon, Feb 12, 2018 at 9:13 AM Ryan Newton <<a href="mailto:rrnewton@gmail.com" target="_blank" class="">rrnewton@gmail.com</a>> wrote:<br class=""></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="m_-2716427062567210055h5"><div dir="ltr" class=""><div class="">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 class="">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 class="">argue for "accept"</b>.<br class=""></div><div class=""><br class=""></div><div class=""><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" class="">In short, <span id="m_-2716427062567210055m_-9195740632752032102m_-5664814179703483304goog_1240068977" class=""></span>the proposal <span id="m_-2716427062567210055m_-9195740632752032102m_-5664814179703483304goog_1240068978" class=""></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" class="">"linear types"</a>, <a href="https://github.com/ghc-proposals/ghc-proposals/pull/8" target="_blank" class="">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 class=""><br class=""></div><div class="">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" class=""><div class=""><br class=""></div><div class=""> -Ryan</div></div><div dir="ltr" class=""><div class=""><br class=""></div><div class="">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" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <span dir="ltr" class=""><<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Committee,<br class="">
<br class="">
this is your secretary speaking:<br class="">
<br class="">
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/8" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals/pull/8</a><br class="">
was brought before the committee, by our own Simon Marlow.<br class="">
<br class="">
I propose Ryan Newton as the Shepherd, because he asked for it :-)<br class="">
<br class="">
Ryan, please reach consensus as described in<br class="">
<a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br class="">
<br class="">
I suggest you make a recommendation about the decision, maybe point out<br class="">
debatable points, and assume that anyone who stays quiet agrees with<br class="">
you.<br class="">
<br class="">
<br class="">
Greetings,<br class="">
Joachim<br class="">
<span class="m_-2716427062567210055m_-9195740632752032102m_-5664814179703483304m_-8292464738700205453HOEnZb"><font color="#888888" class=""><br class="">
<br class="">
--<br class="">
Joachim Breitner<br class="">
<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a><br class="">
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank" class="">http://www.joachim-breitner.de/</a><br class="">
</font></span></blockquote></div><br class=""></div></div></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 class=""></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=""></body></html>