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

Iavor Diatchki iavor.diatchki at gmail.com
Wed Feb 14 18:49:57 UTC 2018


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.






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

> 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/20180214/398bf72a/attachment.html>


More information about the ghc-steering-committee mailing list