- ghc-steering-committee

Need more Trac tickets
by Richard Eisenberg 03 Jun '18

03 Jun '18

Hi all, Ryan Scott very helpfully this morning labeled the Trac tickets that have grown from proposals. However, there remain a good many proposals without corresponding Trac tickets. I propose that we make it a shepherd's responsibility to make sure that a Trac ticket is created upon the acceptance of a proposal. Specifically: a shepherd should encourage the proposer to make the Trac ticket, and if this fails to happen, then for the shepherd to do it himself. (Why have the proposer do it? 1. To lessen the burden on the shepherd. 2. To subtly encourage the proposer to ponder the possibility of implementing.) What do we think? We'll still have to make tickets for those accepted proposals but with not tickets... Richard

2 5

Array resizing primitives (#121), proposal: accept with modifications
by Simon Marlow 03 Jun '18

03 Jun '18

I propose that we accept https://github.com/ghc- proposals/ghc-proposals/pull/121 With one modification (below). In summary, this proposal suggests adding primitives for resizing (shrinking or expanding) primitives mutable arrays of pointers. See the proposal for motivation. There would be two primitives per array type: shrinkArray# :: MutableArray# s a -> Int# -> State# s -> State# s resizeArray# :: MutableArray# s a -> Int# -> a -> State# s -> (# State# s, MutableArray# s a #) (these mirror the existing shrink and resize primitives we have for ByteArray#, with the same rationale) The biggest downside is that we currently have sizeOfMutableArray# :: MutableArray# s a -> Int # which would need to be replaced by a stateful operation getSizeOfMutableArray# :: MutableArray# s a -> State# s -> (# State# s, Int# #) So we would need to deprecate the old primops, update any code we have that uses them, and clearly indicate the unsafety in the docs. But this has knock-on effects in Data.Primitive: sizeofMutableArray :: MutableArray s a -> Int this would need to be deprecated and replaced by a PrimMonad operation. The pure version would be unsafe in the sense that it could return the wrong size, and a future indexing operation relying on the incorrect size could access an out-of-bounds element. Suggested modifications: * Remove the ArrayArray# primitives, add UniftedArray# primitives instead (see https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0021-u… ) Cheers Simon On 1 May 2018 at 13:12, Joachim Breitner <mail(a)joachim-breitner.de> wrote: > Dear Committee, > > this is your secretary speaking: > > Array resizing primitives have been proposed by David Feuer: > https://github.com/ghc-proposals/ghc-proposals/pull/121 > > I propose Simon Marlow as the shepherd. > > 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/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee(a)haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > >

3 2

Treat kind and type vars identically with `forall` #103
by Simon Peyton Jones 23 May '18

23 May '18

Dear GHC steering committee I strongly propose that we accept Treat kind and type vars identically with `forall` #103 https://github.com/ghc-proposals/ghc-proposals/pull/103 It makes our design much more simple and uniform - both in the specification and in the implementation. The current setup is a terrible dogs breakfast. Moreover, I propose that we adopt it without a 3-release wait after #83 - see under Alternatives. Any programs that are rejected by #103 can be fixed by adding some extra forall k's. And that change will be accepted NOW if you add -XTypeInType. Simon

4 7

Deriving via (#120), Recommendation: accept
by Joachim Breitner 22 May '18

22 May '18

Dear Committee, this is your secretary speaking: Deriving via was proposed, by Ryan, Icelandjack and Andres, https://github.com/ghc-proposals/ghc-proposals/pull/120 rendered at https://github.com/Icelandjack/ghc-proposals/blob/patch-3/proposals/0000-de… I’ll shepherd that myself. The proposal adds a new deriving strategy that works like GND, but explicitly names the other, representationally equal type whose instance should be copied. The proposal comes with a paper and an implementation, has been met with great enthusiasm in the community, and I expect that our users will do many great things with it, and all that with relatively little theoretical and implemntational overhead. I therefore wholeheartedly recomment that we accept this proposal. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 4

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 16 May '18

16 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 15 May '18

15 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 15 May '18

15 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 15 May '18

15 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