<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">I think the conclusion of the last round of discussion was to go ahead with the implementation and use experience with that to understand the impact on GHC and to refine the proposal.  We'll be in good shape if we can demonstrate that mutable fields aren't 
too intrusive, and it'll need a prototype implementation to be able to 
establish that. <br><br></div><div class="gmail_quote">The status of the proposal isn't blocking the implementation, I think the limiting factor is cycles to work on it, that's all. I'm not sure what the correct state to put the proposal in at this stage is - dormant perhaps?<br><br></div><div class="gmail_quote">Cheers<br></div><div class="gmail_quote">Simon<br></div><div class="gmail_quote"><br>On 5 May 2018 at 22:06, 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 Ryan,<br>
<br>
what is the status of this proposal? It seems that it was not met with<br>
enthusiasm, but also not with opposition? Shall I mark it as accept?<br>
<br>
Cheers,<br>
Joachim<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Am Sonntag, den 11.02.2018, 00:43 -0500 schrieb Ryan Newton:<br>
> 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 March 10th, or earlier if consensus occurs.  Let's use this email thread for that discussion.  In this mail I summarize public discussion and argue for "accept".<br>
> <br>
> In short, the proposal adds a way to have multiple mutable fields within a data-constructor, without the indirection of using IORef.  Second to "linear types", this proposal 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.  <br>
> <br>
> 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.<br>
> <br>
>   -Ryan<br>
> <br>
> 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.<br>
> <br>
> <br>
> On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br>
> > 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>
> > <br>
> > <br>
> > --<br>
> > Joachim Breitner<br>
> >   <a href="mailto:mail@joachim-breitner.de">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>
> <br>
</div></div><span class="im HOEnZb">> ______________________________<wbr>_________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org">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>
</span><div class="HOEnZb"><div class="h5">-- <br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de">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>
</div></div><br>______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org">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>
<br></blockquote></div><br></div></div>