September 2017 - ghc-steering-committee

Please review: Mutable constructor fields, Shepherd: Ryan Newton
by Joachim Breitner 08 May '18

08 May '18

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(a)joachim-breitner.de http://www.joachim-breitner.de/

7 18

Committee Discussion : Lazy unboxed tuples
by Ryan Newton 05 May '18

05 May '18

Dear Committee, The public discussion <https://github.com/ghc-proposals/ghc-proposals/pull/35> for this one <https://github.com/goldfirere/ghc-proposals/blob/unbanged-strict-patterns/p…> has happened, now for 4 weeks of committee discussion and final accept/reject. In that public discussion, you can see on Jan 11 options broken down as (1),(2),(3), with this proposal being (1). This seems to have stopped in a weird place where there was some substantial argument for (2) and (3) in the latter half of the comments, but the proposal is for (1). Richard, one bit that threw me off was this: *"we should require the bang even on bare variables, but that would break a lot of code I think."* Because that makes it seem like in spite of this cleaning-up proposal, GHC still has a basically inconsistent position on how to interpret variable-bindings of unlifted kind in patterns. Discuss? -Ryan On Tue, Jul 11, 2017 at 11:08 AM, Joachim Breitner <mail(a)joachim-breitner.de > wrote: > Hi, > > it is by Richard, I just got the URL wrong. The right pull request is > https://github.com/ghc-proposals/ghc-proposals/pull/35 > sorry for that. > > Using this thread is fine. > > Joachim > > Am Dienstag, den 11.07.2017, 10:58 -0400 schrieb Ryan Newton: > > Just to clarify, this is proposed by a user "winterland". I.e. not > > Richard, right? In the process document it is the author that "brings > > it before the committee" correct? > > > > I checked and it looks like our process document does not specify the > > means of our committee discussion. I propose we discuss this one > > right here on this thread, which we've already got sitting in our > > inboxes. > > > > Best, > > -Ryan > > > > > > On Tue, Jul 11, 2017 at 2:58 AM, Joachim Breitner <mail@joachim-breit > > ner.de> wrote: > > > Dear Committee, > > > > > > this is your secretary speaking: > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/45 > > > was brought before the committee, by our own Richard. > > > > > > I propose Ryan Newton as the Shepherd, just to rotate this role > > > properly. > > > > > > 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(a)joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > > > -- > Joachim “nomeata” Breitner > mail(a)joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata(a)joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata(a)debian.org > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee(a)haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > >

5 6

GHC steering committee participation
by Atze Dijkstra 22 Oct '17

22 Oct '17

Dear committee members, as you may have noticed I have not actively participated in proposal reviewing. I can wrap this in a long or short story, but at the core lies lack of time combined with my role at Standard Chartered (SC) evolving in a direction less involved with GHC and Haskell language design/implementation than I originally thought it might be. Privately, outside of SC, I also see little time and energy left for committee activities. The work on proposals seems to have started actively and vigorously and I'd rather not be this silent non-contributing participant. I feel it is important to have somebody from what can likely be called the largest Haskell based industrial development group be in contact with and contribute to what by definition is an important tool for us. After some consultation with colleagues I found Roman Leshchinskiy (rleshchinskiy(a)gmail.com) to be willing to replace me in the committee. For most of the committee members I guess he is already known from the FP community so I leave further introduction up to himself. Within SC Roman is responsible for GHC related supporting infrastructure and as such is more than I am involved in and confronted with GHC intricacies, which places him at a better position to contribute to the GHC steering committee from an industrial perspective. I am aware that stepping down might cause inconvenience, but also feel that this better can be done now than later when the committee is already on farther on its way in dealing with proposals. I am also aware that it is not really up to me to decide what to do next after me stepping down, but I feel the proposed replacement by Roman is the best option from my perspective. all the best, Atze

7 11

Proposal: Type Fixity (#65), Recommendation: Reject
by Joachim Breitner 07 Oct '17

07 Oct '17

Dear Committee, Ryan Scott’s proposal to allow fixity declaration to explicitly target values or types has been brought before us: https://github.com/RyanGlScott/ghc-proposals/blob/type-infix/0000-type-infi… https://github.com/ghc-proposals/ghc-proposals/pull/65 I (the secretary) nominates myself as the shepherd, so I can right away continue giving a recommendation. I propose to reject this proposal. The main reasons are: * it is not clear if there is a real use case for this. Has anyone ever complained about the status quo? The proposal does not motivate the need for a change well enough. (There is a related bug in TH, but that bug can probably simply be fixed.) * The status quo can be sold as a feature, rather than a short-coming. Namely that an operator has a fixed fixity, no matter what namespace it lives in. This matches morally what other languages do: In Gallina, fixity is assigned to names independent of their definition, AFAIK. * There is a non-trivial implementation and education overhead, a weight that is not pulled by the gains. If we’d design Haskell from scratch, my verdict might possibly be different (but maybe we wouldn’t even allow types and values to share names then…) Please contradict me or indicate consensus by staying silent. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

8 19

Explicit foralls
by Simon Peyton Jones 20 Sep '17

20 Sep '17

Friends I propose that we accept the Explicit Foralls proposal<https://github.com/ghc-proposals/ghc-proposals/pull/55>. * No one objected * It makes the language more expressive and uniform * It fixes a long-standing ticket #2600 The only bump in the road is the double forall in RULES (see the Examples in the proposal). But that's not Ricahrd's fault, and the proposed solution seems reasonable. I move to accept. Simon

3 3

Status
by Joachim Breitner 08 Sep '17

08 Sep '17

Hi, off the floor at the Haskell Symposium, the current status. I think many of us are here in Oxford. I guess we could try to meet in person and work off the backlog simply by quick real-live discussion – but maybe people have better things to do, and not all of us are here. So let’s just carry on as usual. Since the last status update one new proposals has come up for deliberation, and one proposals was accepted. Open at the moment are: NOUNPACK on function arguments https://github.com/ghc-proposals/ghc-proposals/pull/46 Shepherd: Simon Marlow Status: There was more discussion on GitHub, and @treeowl will have a look if the proposal text is reflecting all that discussion. (Still waiting on @treeowl.) Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Newton Status: Still waiting for Ryan to make a recommendation. Explicit foralls proposal https://github.com/ghc-proposals/ghc-proposals/pull/55 Shepherd: Simon Peyton Jones Status: Simon recommended to accept this, and we see silent consensus emerging. Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: Waiting for Ryan to make a recommendation. Or Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Chakravarty Status: Waiting for Manuel to make a recommendation. Type fixity https://github.com/ghc-proposals/ghc-proposals/pull/65 Shepherd: Joachim Breitner Status: Rejection recommended, but met with different opinions here. We need to either continue debating or *gasp* actually vote. Besides these, there are some proposals actively under discussion. You can always check them out at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+no… Greetings, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0