[ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: Ryan Newton

[Iavor Diatchki]

I support this.

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.

On Mon, Feb 12, 2018 at 9:13 AM Ryan Newton <rrnewton at gmail.com> wrote:

> 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"*.
>
> 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" <https://github.com/ghc-proposals/ghc-proposals/pull/91>, this
> proposal <https://github.com/ghc-proposals/ghc-proposals/pull/8>
> 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.
>
> 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.
>
>   -Ryan
>
> 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.
>
>
> On Fri, Jul 14, 2017 at 8:17 AM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
>> Dear Committee,
>>
>> this is your secretary speaking:
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/8
>> was brought before the committee, by our own Simon Marlow.
>>
>> I propose Ryan Newton as the Shepherd, because he asked for it :-)
>>
>> Ryan, please reach consensus as described in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> I suggest you make a recommendation about the decision, maybe point out
>> debatable points, and assume that anyone who stays quiet agrees with
>> you.
>>
>>
>> Greetings,
>> Joachim
>>
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180212/c72dffb9/attachment-0001.html>