- ghc-steering-committee

Please Review: Provenance-Qualified Package Imports, Shepherd: Ben Gamari
by Joachim Breitner 02 Apr '18

02 Apr '18

Dear Committee, this is your secretary speaking: Provenance-Qualified Package Imports by Gershom Bazerman https://github.com/ghc-proposals/ghc-proposals/pull/115 I propose Ben Gamari as the shepherd. Ben, 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 0

Quantified constraints
by Simon Peyton Jones 02 Apr '18

02 Apr '18

Joachim I'd like submit the Quantified Constraints proposal<https://github.com/ghc-proposals/ghc-proposals/pull/109> (#109) to the committee Simon

1 0

Re: [ghc-steering-committee] Proposal: Binding existential type variables (#96)
by Simon Peyton Jones 29 Mar '18

29 Mar '18

Note we aren't binding any type variables here, we're just selecting a specific instantiation of the constructor via type application Interesting. (I did misunderstand you!) So in your example, Int and only Int would do at that spot. To you it seems like a “natural meaning” but not to me. In a pattern I expect to enumerate the bound variables, and that is just what is proposed here, * using @ to distinguish type binders from term binders just as visible type application * uses @ to distinguish type argument from term arguments Also, you can readily do what you want with an ordinary type signature in a pattern h (C n :: C Int) = n -- infers h :: C Int -> Int Moreover you don’t explain what it would mean to supply the existential argument with @ applications in a pattern match. Do those bind type variables? I think we should be cautious about rejecting one proposal because it precludes another, unless the other is actually made and worked out so we can see it. I say cautious, not that it’s an invalid argument – we don’t want to accept proposals that everyone agrees will preclude future flexibility. But here it is controversial (at least between you and me 😊). Would you like to make an alternative proposal? Simon From: Roman Leshchinskiy <rleshchinskiy(a)gmail.com> Sent: 26 March 2018 09:54 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: [ghc-steering-committee] Proposal: Binding existential type variables (#96) On Mon, Mar 26, 2018 at 8:59 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: The reason is that the proposal "steals" the syntax for explicit type application in patterns but it seems to me that type application in patterns makes perfect sense! I disagree with Roman here. I don’t think type application makes sense in patterns. Suppose we have data T a where MkT :: [a] -> [b] -> T a f :: T c -> c -> [c] f t x = x : (case t of T ys zs -> if length zs > 1 then ys else []) Then · ‘c’ is really bound at f’s definition site; not in the pattern match · You might want to mention ‘c’ in lots of places, not just inside the pattern match, so you might want to make ‘c’ lexically scope over its entire actual scope. Providing a convenient way to make it scope over just part of its actual scope seems entirely ad-hoc. We might want to do that at any sub-expression. And we can do so with an ordinary type signature with an explicit forall. · In contrast the type of ‘zs’ really is bound at the pattern match. · Imagine that we had a type-passing implementation that really did pass data structures representing types for every big lambda and type application. Then we really would store the data structure representing the existential inside the data constructor, and match it in a pattern; but it would be a waste of space to store and match the universal too. · In Core, we have MkT :: forall a b . [a] -> [b] -> T a, so a use of MkT as a constructor is applied to two types. But in a pattern match we just match one type, namely the existential one. Simon, I think you might have misunderstood me. I'm not proposing to be able to *bind* universally quantified variables via @ in patterns. My argument is much simpler. To revisit my example: data C a = C a This gives us the constructor C :: forall a. a -> a and in expressions, C @Int is the Int -> Int instance of the constructor. Personally, I would expect C @Int to have the exact same meaning in patterns since it makes total sense there (to me, at least), like in my example: h (C @Int n) = n -- infers h :: C Int -> Int Note we aren't binding any type variables here, we're just selecting a specific instantiation of the constructor via type application, just like we would do in expressions. Under the proposal, the meaning of @ in patterns would be different and to me, surprising. In fact, I naively assumed that the above is already possible with visible type application. Now, perhaps type application in patterns isn't and will never be useful and repurposing the syntax is ok? After all, patterns already reuse function application syntax in much the same way. I'll certainly reconsider my opinion if that's the case but I don't think this has been discussed at all so far. Hence, I'm very wary of taking away syntax that already has a natural meaning. Roman

5 18

As patterns in pattern synonyms (#94), Recommendation: accept
by Joachim Breitner 22 Mar '18

22 Mar '18

Dear Committee, this is your secretary speaking: As patterns in pattern synonyms, by Richard. https://github.com/ghc-proposals/ghc-proposals/pull/94 rendered at https://github.com/ghc-proposals/ghc-proposals/blob/as-pattern-synonyms/AsP… I’ll shepherd that myself. This proposal removes restrictions on what can be used in unidirectional pattern synonyms, where @-pattern were previously disallowed. The restriction would make sense if patterns synonyms are macros, but they are not. I am always in favor of removing special cases and restrictions, so I recommend to accept this proposal. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 6

Status
by Joachim Breitner 18 Mar '18

18 Mar '18

Hi, I hope you all survived the ICFP deadline well, and surely you are now all eager to work off the pretty long list of proposals that are before us. Since the last status update, we * were asked to review these proposals: - kind and type vars in forall (Shepherd: SPJ) - Source Plugins (Shepherd: Chris Allen) - Constraint vs. Type (Shepherd: SPJ) - Type-level type app (Shepherd: Richard) - kind!! (Shepherd: Manuel) - as-patterns (Shepherd: me) - scoped type vars (Shepherd: Roman) - or-patterns (Shepherd: Manuel) * got a recommendation from shepherds about: - Int8/Word8 (accept) - DH quantifiers (accept) - Type-level type app (accept) - Constraint vs. Type (accept) - as-patterns (accept) * decided about the following proposals - unlifted newtypes (accept) - Int8/Word8 (accept) - type level app (accept) - as-patterns (accept) Plenty of work to do, as we currently have to act on the following 12 proposals! Plugin recompilation API https://github.com/ghc-proposals/ghc-proposals/pull/108 Shepherd: Ben, recommends acceptance Status: Ongoing discussion, with me solitarily holding up the process with criticism Source Plugins https://github.com/ghc-proposals/ghc-proposals/pull/107 Shepherd: Chris Allen Status: Waiting for Allen’s recommendation kind and type vars https://github.com/ghc-proposals/ghc-proposals/pull/103 Shepherd: SPJ Status: Waiting for Simon to make a recommendation Dependent Haskell quantifier syntax https://github.com/ghc-proposals/ghc-proposals/pull/102 Shepherd: Joachim, recommends acceptance Status: Reservations from SPJ and Iavor, no consensus emerging so far. Binding existential variables https://github.com/ghc-proposals/ghc-proposals/pull/96 Shepherd: Roman Status: Waiting for Roman to make a recommendation Embrace Type-In-Type https://github.com/ghc-proposals/ghc-proposals/pull/83 Shepherd: Iavor Status: Ongoing discussion, mostly about the fate of * Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Unclear. Blocked on #102? :kind!! https://github.com/ghc-proposals/ghc-proposals/pull/79 Shepherd: Manuel Status: Waiting for Manuel to make a recommendation Or-Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Status: Waiting for Manuel to make a recommendation Constraint vs. Type https://github.com/ghc-proposals/ghc-proposals/pull/32 Shepherd: Simon PJS (proposed acceptance) Status: Simon’s proposal was met with silence. Ergo accept? Mutable constructor fields https://github.com/ghc-proposals/ghc-proposals/pull/8 Shepherd: Ryan Newton Status: There was more discussion. Does this need to go back to the discussion phase? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please Review: Or patterns, Shepherd: Manuel
by Joachim Breitner 03 Mar '18

03 Mar '18

Dear Committee, this is your secretary speaking: Or patterns were proposed by Ömer https://github.com/ghc-proposals/ghc-proposals/pull/43 I propose Manuel Chakravarty as the shepherd. Manuel, 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 0

Plugin recompilation avoidance
by Ben Gamari 02 Mar '18

02 Mar '18

Hi everyone, I'm writing you in reference to GHC Proposal #108 [1], which introduces a mechanism allowing plugins greater control over GHC's recompilation behavior. The committee is currently considering this proposal for acceptance and while most of you have already expressed general support for the proposal during the discussion period, we wanted to check once more with you to ensure that no issues have gone unnoticed. If any of you have any final thoughts regarding the proposal, do let us know in the next few days. Otherwise we will accept the proposal as-is. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/108

2 1

Type-level type applications (#80): Recommend accept
by Richard Eisenberg 01 Mar '18

01 Mar '18

This proposal (https://github.com/ghc-proposals/ghc-proposals/pull/80 <https://github.com/ghc-proposals/ghc-proposals/pull/80>) introduces type-level type applications, extending the existing TypeApplications syntax to work in types. - With -XTypeApplications, you will be able to instantiate kind variables in types. For example, you could talk about `Proxy @(Type -> Type) Maybe` and `Category @(TYPE IntRep) (->)` or even `(->) @(TYPE LiftedRep) @(TYPE DoubleRep)`. And that's it! GHC *already* has the required/specified/inferred distinction in terms, which is unchanged in types. I believe strongly we should accept. There was no substantive dissenting commentary, just clarifying questions. Thanks, Richard

6 5

Please review: Int8/Word8, Shepherd: Simon Marlow
by Joachim Breitner 01 Mar '18

01 Mar '18

Dear Committee, this is your secretary speaking: Small types like `Int8#`/`Word8#` were proposed https://github.com/ghc-proposals/ghc-proposals/pull/74 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 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/

8 8

Please Review: Scoped Type variables for existentials, Shepherd: Roman
by Joachim Breitner 01 Mar '18

01 Mar '18

Dear Committee, this is your secretary speaking: Scoped Type variables for existentials by Emmanuel “Emma” Suarez, with help from Richard Eisenberg and Stephanie Weirich. https://github.com/ghc-proposals/ghc-proposals/pull/96 I propose Roman Leshchinskiy as the shepherd. 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 0