Please review: Mutable constructor fields, Shepherd: Ryan Newton

Joachim Breitner

14 Jul 2017 14 Jul '17

12:17 p.m.

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/

Attachments:

signature.asc (application/pgp-signature — 833 bytes)

Show replies by date

Ryan Newton

11 Feb 11 Feb

5:43 a.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

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 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/

Iavor Diatchki

12 Feb 12 Feb

5:24 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

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

Ryan Newton

5:29 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: 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 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

Iavor Diatchki

14 Feb 14 Feb

6:49 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

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
...
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

Richard Eisenberg

16 Feb 16 Feb

7:42 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

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 mailto:rrnewton@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 mailto: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 mailto:rrnewton@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 mailto:mail@joachim-breitner.de> wrote: Dear Committee,

this is your secretary speaking:

https://github.com/ghc-proposals/ghc-proposals/pull/8 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 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 mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 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

Ryan Newton

19 Feb 19 Feb

4:53 p.m.

New subject: 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

Ryan Newton

23 Feb 23 Feb

8:22 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: 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 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 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-steeri ng-committee

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

Joachim Breitner

1 Mar 1 Mar

5:17 a.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

Hi, Am Freitag, den 23.02.2018, 15:22 -0500 schrieb 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.

it has been quiet here, but I see new activity on https://github.com/ghc-proposals/ghc-proposals/pull/8 Is this a sign that the proposal is not yet as polished as would hope for? Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de https://www.joachim-breitner.de/

Simon Marlow

8:48 a.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

Simon has provided a detailed review (thanks!) so I think we'll need some time to digest those comments and suggestions and modify the proposal. In light of that shall we put the proposal back into the discussion phase for now? Cheers Simon On 1 March 2018 at 05:17, Joachim Breitner wrote:

...

Hi,

Am Freitag, den 23.02.2018, 15:22 -0500 schrieb 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.

it has been quiet here, but I see new activity on https://github.com/ghc-proposals/ghc-proposals/pull/8

Is this a sign that the proposal is not yet as polished as would hope for?

Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de https://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

Simon Peyton Jones

8:54 a.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

I don’t mean to be negative about it. I’m sold on the motivation. It just seems quite a deep-seated change (e.g. affecting transformations in Core because mutable constructors have identity) and I don’t have that satisfying “aha” feeling when all the pieces mesh together – something that is a hallmark of Haskell. I wish I could propose a constructive alternative. It’s tiresome when people just object on somewhat vague grounds but don’t offer any concrete alternatives. Simon From: ghc-steering-committee [mailto:ghc-steering-committee-bounces@haskell.org] On Behalf Of Simon Marlow Sent: 01 March 2018 08:49 To: Joachim Breitner Cc: ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: Ryan Newton Simon has provided a detailed review (thanks!) so I think we'll need some time to digest those comments and suggestions and modify the proposal. In light of that shall we put the proposal back into the discussion phase for now? Cheers Simon On 1 March 2018 at 05:17, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hi, Am Freitag, den 23.02.2018, 15:22 -0500 schrieb 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.

it has been quiet here, but I see new activity on https://github.com/ghc-proposals/ghc-proposals/pull/8 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F8&data=04%7C01%7Csimonpj%40microsoft.com%7Cda6f622af1f445a397cd08d57f51491f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636554909454432423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=AcpE8whWwCIWKuNvG%2Fmwvjay0zXbPC0mP6zxk168TAk%3D&reserved=0 Is this a sign that the proposal is not yet as polished as would hope for? Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de https://www.joachim-breitner.de/https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cda6f622af1f445a397cd08d57f51491f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636554909454432423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=Lj%2Fxq4DdTDxtnnLOZ83qwgJED7%2BTNHTP054tFT5TtTI%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Ryan Newton

3 Mar 3 Mar

11:14 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

I'm certainly fine with going back to discussion. Simon PJ, much of your review was improvements/edits, and after those are incorporated, which are the highest priority, deal-breaker issues for you? In particular, the requirement to use reallyUnsafePtrEq# received some subsequent discussion. If we require at least one mutable field for a constructor to have physical equality, then reallyUnsafePtrEq# can be avoided both in derived or handwritten equality functions. Does that improve your assessment? Best, -Ryan On Thu, Mar 1, 2018 at 3:48 AM, Simon Marlow wrote:

...

Simon has provided a detailed review (thanks!) so I think we'll need some time to digest those comments and suggestions and modify the proposal. In light of that shall we put the proposal back into the discussion phase for now?

Cheers Simon

On 1 March 2018 at 05:17, Joachim Breitner wrote:

...
Hi,

Am Freitag, den 23.02.2018, 15:22 -0500 schrieb 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.

it has been quiet here, but I see new activity on https://github.com/ghc-proposals/ghc-proposals/pull/8

Is this a sign that the proposal is not yet as polished as would hope for?

Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de https://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

Simon Peyton Jones

5 Mar 5 Mar

9:17 a.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

which are the highest priority, deal-breaker issues for you? As I say, I’m uncomfortable, but since I can’t identify anything solidly wrong with it, I don’t want to stand in the way. Once we have a full implementation, and can see the impacts on the codebase, we may be in a better position to judge. (This is true of every proposal whose impacts across the compiler are hard to predict, not just this one.) If we require at least one mutable field for a constructor to have physical equality, then reallyUnsafePtrEq# can be avoided both in derived or handwritten equality functions Well, of course you need at least one mutable field! But having got it, how do we get rid of the unsafe-ptr-eq? Perhaps the thing to do is to update the proposal to whatever the new idea is? Simon From: Ryan Newton [mailto:rrnewton@indiana.edu] Sent: 03 March 2018 23:14 To: Simon Marlow ; Simon Peyton Jones Cc: Joachim Breitner ; ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: Ryan Newton I'm certainly fine with going back to discussion. Simon PJ, much of your review was improvements/edits, and after those are incorporated, which are the highest priority, deal-breaker issues for you? In particular, the requirement to use reallyUnsafePtrEq# received some subsequent discussion. If we require at least one mutable field for a constructor to have physical equality, then reallyUnsafePtrEq# can be avoided both in derived or handwritten equality functions. Does that improve your assessment? Best, -Ryan On Thu, Mar 1, 2018 at 3:48 AM, Simon Marlow mailto:marlowsd@gmail.com> wrote: Simon has provided a detailed review (thanks!) so I think we'll need some time to digest those comments and suggestions and modify the proposal. In light of that shall we put the proposal back into the discussion phase for now? Cheers Simon On 1 March 2018 at 05:17, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hi, Am Freitag, den 23.02.2018, 15:22 -0500 schrieb 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.

it has been quiet here, but I see new activity on https://github.com/ghc-proposals/ghc-proposals/pull/8 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F8&data=04%7C01%7Csimonpj%40microsoft.com%7C0fbe8d22dcbd49db82bd08d5815c8c66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636557156850040805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=0V4RHBIaGCfrcdDceNHqqgME11gjUc7o78vGYO2Xfog%3D&reserved=0 Is this a sign that the proposal is not yet as polished as would hope for? Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de https://www.joachim-breitner.de/https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0fbe8d22dcbd49db82bd08d5815c8c66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636557156850040805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=q60KMAI7yEupX4KCbr0xqXNcxEeiNqfh6OdyoMLZJEA%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto: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.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Ryan Newton

3:42 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

Dear Simon,

...

If we require at least one mutable field for a constructor to have physical equality, then reallyUnsafePtrEq# can be avoided both in derived or handwritten equality functions

Well, of course you need at least one mutable field! But having got it, how do we get rid of the unsafe-ptr-eq?

FYI, the proposal as written now also allows constructors with no mutable fields but still offering O(1) physical identity: data T where MkT :: [Int] -> IO T deriving Eq But if this is disallowed, and we have *at least one* mutable field... data T where MkT :: mutable [Int] -> IO T Then the simple observation is that we no longer need to use reallyUnsafePtrEq on two MkT constructors themselves, rather we can simply use Ref# equality on any pair of matching fields: eq (MkT a) (MkT b) = refEq a b Ref# equality is just a one-word pointer comparison of course, but unlike reallyUnsafePtrEq, it's always safe.

...

Perhaps the thing to do is to update the proposal to whatever the new idea is?

Yes, indeed! Let's. Best, -Ryan

...

Simon

*From:* Ryan Newton [mailto:rrnewton@indiana.edu] *Sent:* 03 March 2018 23:14 *To:* Simon Marlow ; Simon Peyton Jones < simonpj@microsoft.com> *Cc:* Joachim Breitner ; ghc-steering-committee@haskell.org *Subject:* Re: [ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: Ryan Newton

I'm certainly fine with going back to discussion.

Simon PJ, much of your review was improvements/edits, and after those are incorporated, which are the highest priority, deal-breaker issues for you?

In particular, the requirement to use reallyUnsafePtrEq# received some subsequent discussion. If we require at least one mutable field for a constructor to have physical equality, then reallyUnsafePtrEq# can be avoided both in derived or handwritten equality functions. Does that improve your assessment?

Best,

-Ryan

On Thu, Mar 1, 2018 at 3:48 AM, Simon Marlow wrote:

Simon has provided a detailed review (thanks!) so I think we'll need some time to digest those comments and suggestions and modify the proposal. In light of that shall we put the proposal back into the discussion phase for now?

Cheers

Simon

On 1 March 2018 at 05:17, Joachim Breitner wrote:

Hi,

Am Freitag, den 23.02.2018, 15:22 -0500 schrieb 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.

it has been quiet here, but I see new activity on https://github.com/ghc-proposals/ghc-proposals/pull/8 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F8&data=04%7C01%7Csimonpj%40microsoft.com%7C0fbe8d22dcbd49db82bd08d5815c8c66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636557156850040805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=0V4RHBIaGCfrcdDceNHqqgME11gjUc7o78vGYO2Xfog%3D&reserved=0

Is this a sign that the proposal is not yet as polished as would hope for?

Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de https://www.joachim-breitner.de/ https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0fbe8d22dcbd49db82bd08d5815c8c66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636557156850040805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=q60KMAI7yEupX4KCbr0xqXNcxEeiNqfh6OdyoMLZJEA%3D&reserved=0

_______________________________________________ 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

Simon Peyton Jones

4:18 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

Ref# equality is just a one-word pointer comparison of course, but unlike reallyUnsafePtrEq, it's always safe. I haven’t checked, but there is presumably a new primop eqRef# :: Ref# a -> Ref# a -> Bool? Or (hmm) maybe eqRef# :: Ref# a -> Ref# b -> Maybe (a ~ b) a bit like equality on TypeRep. NNTR: just a suggestion for the proposal. Simon From: Ryan Newton [mailto:rrnewton@indiana.edu] Sent: 05 March 2018 15:42 To: Simon Peyton Jones Cc: Simon Marlow ; Joachim Breitner ; ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: Ryan Newton Dear Simon, If we require at least one mutable field for a constructor to have physical equality, then reallyUnsafePtrEq# can be avoided both in derived or handwritten equality functions Well, of course you need at least one mutable field! But having got it, how do we get rid of the unsafe-ptr-eq? FYI, the proposal as written now also allows constructors with no mutable fields but still offering O(1) physical identity: data T where MkT :: [Int] -> IO T deriving Eq But if this is disallowed, and we have at least one mutable field... data T where MkT :: mutable [Int] -> IO T Then the simple observation is that we no longer need to use reallyUnsafePtrEq on two MkT constructors themselves, rather we can simply use Ref# equality on any pair of matching fields: eq (MkT a) (MkT b) = refEq a b Ref# equality is just a one-word pointer comparison of course, but unlike reallyUnsafePtrEq, it's always safe. Perhaps the thing to do is to update the proposal to whatever the new idea is? Yes, indeed! Let's. Best, -Ryan Simon From: Ryan Newton [mailto:rrnewton@indiana.edumailto:rrnewton@indiana.edu] Sent: 03 March 2018 23:14 To: Simon Marlow mailto:marlowsd@gmail.com>; Simon Peyton Jones mailto:simonpj@microsoft.com> Cc: Joachim Breitner mailto:mail@joachim-breitner.de>; ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] Please review: Mutable constructor fields, Shepherd: Ryan Newton I'm certainly fine with going back to discussion. Simon PJ, much of your review was improvements/edits, and after those are incorporated, which are the highest priority, deal-breaker issues for you? In particular, the requirement to use reallyUnsafePtrEq# received some subsequent discussion. If we require at least one mutable field for a constructor to have physical equality, then reallyUnsafePtrEq# can be avoided both in derived or handwritten equality functions. Does that improve your assessment? Best, -Ryan On Thu, Mar 1, 2018 at 3:48 AM, Simon Marlow mailto:marlowsd@gmail.com> wrote: Simon has provided a detailed review (thanks!) so I think we'll need some time to digest those comments and suggestions and modify the proposal. In light of that shall we put the proposal back into the discussion phase for now? Cheers Simon On 1 March 2018 at 05:17, Joachim Breitner mailto:mail@joachim-breitner.de> wrote: Hi, Am Freitag, den 23.02.2018, 15:22 -0500 schrieb 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.

it has been quiet here, but I see new activity on https://github.com/ghc-proposals/ghc-proposals/pull/8 https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F8&data=04%7C01%7Csimonpj%40microsoft.com%7C0fbe8d22dcbd49db82bd08d5815c8c66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636557156850040805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=0V4RHBIaGCfrcdDceNHqqgME11gjUc7o78vGYO2Xfog%3D&reserved=0 Is this a sign that the proposal is not yet as polished as would hope for? Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de https://www.joachim-breitner.de/https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C0fbe8d22dcbd49db82bd08d5815c8c66%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636557156850040805%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=q60KMAI7yEupX4KCbr0xqXNcxEeiNqfh6OdyoMLZJEA%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto: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.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

5 May 5 May

9:06 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

Dear Ryan, what is the status of this proposal? It seems that it was not met with enthusiasm, but also not with opposition? Shall I mark it as accept? Cheers, Joachim Am Sonntag, den 11.02.2018, 00:43 -0500 schrieb Ryan Newton:

...

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", this proposal 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 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 -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Simon Marlow

8 May 8 May

2:27 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

I think the conclusion of the last round of discussion was to go ahead with the implementation and use experience with that to understand the impact on GHC and to refine the proposal. We'll be in good shape if we can demonstrate that mutable fields aren't too intrusive, and it'll need a prototype implementation to be able to establish that. The status of the proposal isn't blocking the implementation, I think the limiting factor is cycles to work on it, that's all. I'm not sure what the correct state to put the proposal in at this stage is - dormant perhaps? Cheers Simon On 5 May 2018 at 22:06, Joachim Breitner wrote:

...

Dear Ryan,

what is the status of this proposal? It seems that it was not met with enthusiasm, but also not with opposition? Shall I mark it as accept?

Cheers, Joachim

...
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", this proposal generated the most total comments during

Am Sonntag, den 11.02.2018, 00:43 -0500 schrieb Ryan Newton: 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 -- 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

Joachim Breitner

2:28 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

Hi, Am Dienstag, den 08.05.2018, 15:27 +0100 schrieb Simon Marlow:

...

I'm not sure what the correct state to put the proposal in at this stage is - dormant perhaps?

Maybe “needs revision” (in the sense that it needs information that comes from working on the implementation)? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Simon Marlow

3:53 p.m.

New subject: Please review: Mutable constructor fields, Shepherd: Ryan Newton

On 8 May 2018 at 15:28, Joachim Breitner wrote:

...

Hi,

Am Dienstag, den 08.05.2018, 15:27 +0100 schrieb Simon Marlow:

...
I'm not sure what the correct state to put the proposal in at this stage is - dormant perhaps?

Maybe “needs revision” (in the sense that it needs information that comes from working on the implementation)?

Sounds good. Simon

...

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

2621

Age (days ago)

2919

Last active (days ago)

List overview

Download

18 comments

7 participants

participants (7)

Iavor Diatchki
Joachim Breitner
Richard Eisenberg
Ryan Newton
Ryan Newton
Simon Marlow
Simon Peyton Jones