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

[Ryan Newton]

Ok, I'm not hearing any strong objections and over the long course of
discussion in various venues, reactions have been mostly positive.  Since
committee discussion here has died down, I move to go ahead and accept this
proposal if there are no further objections.

Best,
  -Ryan


On Mon, Feb 19, 2018 at 11:53 AM, Ryan Newton <rrnewton at gmail.com> wrote:

> Hi Richard,
>
> My feeling is that "what to allow re: IO/ST/PrimMonad" is can be changed
> later if needed.  From a minimality perspective, yes, IO and ST may be
> subsumed by a more generic form.  But I think they are probably pretty
> important as convenience features.  (And from the perspective of IO being a
> PrimMonad, it's just a specialization of an already valid type, which seems
> pretty reasonable.)
>
> I was also concerned about a syntactic check, e.g. problems with type
> synonyms.  Simon M's response was here:
> https://github.com/ghc-proposals/ghc-proposals/pull/
> 8#issuecomment-315449267
>
>
> -Ryan
>
> On Fri, Feb 16, 2018 at 2:42 PM, Richard Eisenberg <rae at cs.brynmawr.edu>
> wrote:
>
>> I have not followed the discussion on this one, but I have a clarifying
>> question:
>>
>> - The proposal describes the shape of the mutable constructors very
>> concretely, offering the PrimMonad formulation separate from IO and ST.
>> However, doesn't the PrimMonad case subsume IO and ST? That is, couldn't we
>> remove the points about IO and ST? Or is the check very syntactic and
>> require one of those concrete syntactic shapes?
>>
>> Otherwise, I'm not very knowledgeable about this end of the operation.
>> I'll go with the consensus opinion on this.
>>
>> Richard
>>
>> On Feb 14, 2018, at 1:49 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>> wrote:
>>
>> 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-steeri
>>>>> ng-committee
>>>>>
>>>>
>>> _______________________________________________
>> 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/20180223/94315367/attachment.html>