- ghc-steering-committee

Please Review: Resurrect PatternSignatures, Shepherd: Christopher Allen
by Joachim Breitner 16 Apr '18

16 Apr '18

Dear Committee, this is your secretary speaking: Resurrect PatternSignatures has been proposed by me: https://github.com/ghc-proposals/ghc-proposals/pull/119 I propose Chris Allen as the shepherd. 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, 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

DH quantifiers (#102), Recommendation: accept
by Joachim Breitner 16 Apr '18

16 Apr '18

Dear Committee, this is your secretary speaking: Dependent Haskell quantifiers were proposed, by Richard. https://github.com/ghc-proposals/ghc-proposals/pull/102 rendered at https://github.com/goldfirere/ghc-proposals/blob/pi/proposals/0000-pi.rst I’ll shepherd that myself. This proposal defines and reserves the syntax for the quantifiers that eventually Dependent Haskell will need, and allows their use where it makes sense already (e.g. in Kinds). The quantifier are: forall a. forall a '. forall a -> forall a '-> foreach a. foreach a '. foreach a -> foreach a '-> ty => ty '=> ty -> ty '-> It addresses the interaction with warning (e.g. -Wcompat). It looks well-thought-through, one might infer that the authors wrote a thesis about this stuff. There is some syntactic bikeshedding possible; for example the proposal proposes "foreach" instead of "pi" (the latter would make "pi" a keyword, which would be unfortunate for those who deal with circles). If someone has better ideas, in particular about the use of ' to denote matchable arrows, we still have time to suggest them. I recommend to accept this proposal in the current form or with further refinements to the syntax, if we can come up with them. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 10

Plugin recompilation avoidance interface (#108)
by Ben Gamari 16 Apr '18

16 Apr '18

Hello everyone, I have been assigned as the shepard for proposal #108. This proposes a change in GHC's plugin interface allowing plugins greater control over recompilation, significantly improving compilation times for projects relying on compiler plugins. Summary: The proposal suggests that the existing fields of the `ghc` package's Plugin.Plugin type be wrapped with a type capturing a function computing the plugin's recompilation desired behavior, data PluginRecompile = ForceRecompile | NoForceRecompile | MaybeRecompile Fingerprint GHC can then use this recompilation information to decide whether evaluating the plugin (and consequently invalidating any existing compilation artifacts) is necessary. Opinion & recommendation: The proposal addresses a long-standing limitation (#7414) of the GHC plugin interface which has become increasingly visible to users in recent years. While the particular approach proposed breaks existing plugin users, it is expressive enough to allow GHC to perform more aggressive recompilation avoidance in the future [1]. Moreover, the smart constructors proposed should make for a reasonably smooth migration path. Given that the plugins appears to have buy-in from a few notable plugin authors, I recommend that we accept this proposal. Cheers, - Ben

5 12

Source plugins (#107), Recommendation: accept
by Christopher Allen 13 Apr '18

13 Apr '18

Dear Committee, Chris Allen here! GHC source plugins were proposed by Boldizsár Németh. The PR discussing the proposal is here: https://github.com/ghc-proposals/ghc-proposals/pull/107 Rendered at: https://github.com/nboldi/ghc-proposals/blob/patch-4/proposal-source-plugin… This proposal suggests the extension of the existing tlugin support in GHC with plugins that are able to access and modify the representation of the Haskell syntax tree and its environment. This would allow tool developers to base their tools on GHC plugins. A version of the proposal is already implemented at: https://phabricator.haskell.org/D4342 My present main concern would be the issues with recompilation that the current patch introduces but that seems like a problem with an implementation rather than the proposal. That's an issue for the GHC devs themselves to sort out, as I understand it. It's not obvious to me that the unresolved questions could be answered with deliberation rather than implementation and exploration. I am far from an expert on GHC plugins but from what I've been able to read about them I don't see any blockers in this proposal as-written. I reached out to a couple of people that have hacked on or around GHC in the past and it seemed like they were most keen to find out what problems of theirs this proposal would solve. I didn't see any actual objections raised. I recommend we accept this proposal in the current form or with further elaboration at the author's option. However, my recommendation here defers to the experience of others on the committee who know more about the plugins API and the substance of this proposal. -- Chris Allen

4 3

Proposal #79 "Add a :kind!! command to ghci" — propose yes
by Manuel M T Chakravarty 09 Apr '18

09 Apr '18

We need to decide on the Proposal #79 ”Add a :kind!! command to ghci, to expand type families and type synonyms”: (rendered) https://github.com/alpmestan/ghc-proposals/blob/master/proposals/0000-kind-… (discussion) https://github.com/ghc-proposals/ghc-proposals/pull/79 I agree that this is useful functionality and it is a simple change to GHCi. There has been some discussion about the naming of this command, but TBH I didn’t find any of the alternatives more convincing than ”:kind!!”, so I’d suggest to stick with that. I favour accepting this proposal. Are there any dissenting opinions? Cheers, Manuel

4 5

Please Review: Qualified Constraints, Shepherd: Richard Eisenberg
by Joachim Breitner 06 Apr '18

06 Apr '18

Dear Committee, this is your secretary speaking: Qualified Constraints by Gert-Jan Bottu and SPJ https://github.com/ghc-proposals/ghc-proposals/pull/109 I propose Richard Eisenberg as the shepherd. Richard, 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

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