May 2018 - ghc-steering-committee

Volutneer shepherding for linear types sought
by Joachim Breitner 21 May '18

21 May '18

Hi committee, usually, when a proposal has been submitted, I just pick a shepherd¹. But I feel the linear types proposal, at https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li… is not something I can just impose on any of you. Therefore, I’d like to have a volunteer to step forward and claim this one. Any takers? Joachim ¹ In case you are curious, I look at this data to make a pick: * Low number of pending proposals shepherded * Low number of total proposals handled * Prior activity on the proposal discussion * Expertise and interest, as perceived by me You can influence that easily by engaging in a proposal discussion before it is submitted; that’s a sure way of getting a proposal assigned. -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 5

Resurrect Pattern Signatures (#119), Recommendation: accept
by Christopher Allen 18 May '18

18 May '18

This proposal splits out the faculty for assigning type signatures to variables destructured out of a pattern from ScopedTypeVariables. https://github.com/ghc-proposals/ghc-proposals/pull/119/ My recommendation is to accept the proposal, with some reservations. ScopedTypeVariables is one of the more popular candidates for "this should always be on regardless." The cases in which STV would be useful greatly outnumber the downsides Gundry cited in my experience. My impression of this upheld by my industrial experience and that of the other industrial programmers I've talked to in the past about ScopedTypeVariables. Almost any time it is brought up almost invariably the conversation touches on, "why isn't this on by default?" I understand STV could break programs with overlapping names that are intended to be independent type variables, I don't presume to litigate or resolve that issue here. Extension fatigue is wearing on the Haskell users I regularly interact with, especially as it's unclear if Haskell Prime will convene and consolidate commonly used extensions into the core language. In my view these aren't sufficient reason to reject the proposed extension on the merits so my recommendation is to accept it as-is. I think the case for this proposal is particularly strong as it would clean up the extension's presently somewhat confusing relationship with STV. If no objections are raised, it should be assumed that this has the assent of the committee. -- Chris Allen

5 6

Please Review: bundling patterns with type synonyms (#28), Shepherd: Chris Allen
by Joachim Breitner 15 May '18

15 May '18

Dear Committee, this is your secretary speaking: bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski https://github.com/ghc-proposals/ghc-proposals/pull/28 I propose Chris Allen as the shepherd, as he has already looked at this. Chris, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please Review: Type annotated quoters (#125), Shepherd: Simon Peyton Jones
by Joachim Breitner 14 May '18

14 May '18

Dear Committee, this is your secretary speaking: Type annotated quoters have been proposed by Winterland https://github.com/ghc-proposals/ghc-proposals/pull/125 I propose Simon Peyton Jones as the shepherd, as he has already looked at this. Simon, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

TypeApplications for Overloaded Literals (#129), Recommendation: accept
by Joachim Breitner 14 May '18

14 May '18

Dear Committee, this is your secretary speaking: Sandy Maguire proposes to change the desugaring of overloaded literals so that they work nicely with type applications https://github.com/ghc-proposals/ghc-proposals/pull/129 rendered at https://github.com/isovector/ghc-proposals/blob/type-apps/proposals/0000-ty… I’ll shepherd that myself. The proposal is a good example for a working proposal system here. The original version of the proposal was rather complex, reshuffling type arguments and stuff. But community input distilled this much smaller change, which can be summarized: Desugar `5` into `integerLit (5 :: Integer)` where integerLit :: Integer -> forall a. Num a => a integerLit = fromInteger This allows `5 @Int` to work just fine. The proposal does not require a language extension, and does not change what happens in the light of `RebindableSyntax`. I therefore recommend that we accept this proposal. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 8

Proposal UnliftedArray#: recommend acceptance
by Simon Marlow 14 May '18

14 May '18

UnliftedArray# has been proposed by Andrew Martin: https://github.com/ghc-proposals/ghc-proposals/pull/112 In a nutshell, the proposal is to add new primitive types UnliftedArray# and MutableUnliftedArray# data UnliftedArray# :: TYPE 'UnliftedRep -> TYPE 'UnliftedRep data MutableUnliftedArray# :: TYPE 'LiftedRep -> TYPE 'UnliftedRep -> TYPE 'UnliftedRep with the appropriate set of primops, e.g. indexUnliftedArray# :: forall (a :: TYPE 'UnliftedRep). UnliftedArray# a -> Int# -> a This makes complete sense and it is what we would have done from the start, except that we only recently gained the ability to talk about type variables that range over unlifted types. UnliftedArray# subsumes some existing rather ugly sets of primops that were added because we lacked the ability to define the more general version, like ArrayArray# And ByteArrayArray#, also including the hilarious indexArrayArrayArray# :: ArrayArray# -> Int# -> ArrayArray# All of this can be defined in terms of the general UnliftedArray#. (the migration will be easier if we can use UnliftedNewtypes to define ArrayArray# in terms of UnliftedArray#, otherwise we have to keep the original versions in the compiler, but I don't think the exact mechanism matters all that much for the purposes of accepting or rejecting the proposal). Incidentally we might also want UnliftedMutVar#, UnliftedMVar#, UnliftedTVar#, and maybe UnliftedStablePtr# but that's for another proposal. I propose that we accept this. Any objections? Cheers Simon

7 6

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

Please Review: Kinds Without Promotion, Shepherd: Ryan Newton
by Joachim Breitner 05 May '18

05 May '18

Dear Committee, this is your secretary speaking: Kinds Without Promotion by Yavor https://github.com/ghc-proposals/ghc-proposals/pull/106 I propose Ryan Newton as the shepherd. Ryan, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Please Review: Top-level kind signatures, Shepherd: Roman Leshchinskiy
by Joachim Breitner 05 May '18

05 May '18

Dear Committee, this is your secretary speaking: Top-level kind signatures by Richard has been proposed: https://github.com/ghc-proposals/ghc-proposals/pull/54 I propose Roman Leshchinskiy as the shepherd, who is already shepherding the closely related proposal #81. Roman, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

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