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

[Ryan Newton]

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-
>>>> steering-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/20180219/da21666f/attachment.html>