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

[Ryan Newton]

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?


On Mon, Feb 12, 2018 at 12:24 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> 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/db243559/attachment.html>