Re: [ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: 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 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 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 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@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 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@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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc- steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee