<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="h5"><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="h5"><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_-9195740632752032102m_-5664814179703483304goog_1240068977"></span>the proposal <span id="m_-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_-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>