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

[Richard Eisenberg]

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 <mailto: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 <mailto: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 <mailto: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 <mailto:mail at 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 at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 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/20180216/037710cf/attachment.html>