- ghc-steering-committee

Updated partial type signatures (#194) - recommendation: accept
by Vitaly Bragilevsky 25 Nov '19

25 Nov '19

Hi everyone, Being the shepherd to the Updated partial type signatures proposal (#194, https://github.com/ghc-proposals/ghc-proposals/pull/194) I recommend acceptance. I've posted the rationale behind this recommendation on Github thread ( https://github.com/ghc-proposals/ghc-proposals/pull/194#issuecomment-554751… ). In short: the proposal unifies the treatment of underscores and identifiers beginning with underscores everywhere outside patterns. It also brings more control to partial type signatures. Please, raise your voices here or there. As usual, silence is understood as an agreement. Vitaly

4 3

Please review #246: Overloaded Quotations, Shepherd: Simon PJ
by Joachim Breitner 22 Nov '19

22 Nov '19

Dear Committee, this is your secretary speaking: Overloaded Quotations has been proposed by Matthew Pickering https://github.com/ghc-proposals/ghc-proposals/pull/246 https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/propos… I propose Simon PJ as the shepherd, as it seems he already had some in depth discussion about this proposal. 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/

8 8

Amendment #293; recommendation: accept
by Richard Eisenberg 20 Nov '19

20 Nov '19

3 2

#195 recommendation: accept
by Iavor Diatchki 15 Nov '19

15 Nov '19

Hello everyone, I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a newtype synonym `Code a`. The main change to the language is that the special Template Haskell notation for typed splices will will work with `Code a` rather than `Q (TExtp a)`. The benefit of having the newtype is that it makes it possible to abstract over `Code`. For example, you can work with typed name environments like `MapF Name Code`, where `MapF` is an "indexed" variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in package `parameterized-utils` on hackage). Making typed TH work with `Code` directly avoids the need to constantly switch between `Code` and `Q (TExp a)` and with the new system users of typed TH are not likely to deal with the latter much at all. For these reasons I recommend that we accept this proposal. Please let me know if you think otherwise. -Iavor

5 13

Please review again #177: Simple constrained type families, Shepherd: Richard
by Joachim Breitner 05 Nov '19

05 Nov '19

Dear Committee, this is your secretary speaking: Simple constrained type families has been revised by Alexis Williams https://github.com/ghc-proposals/ghc-proposals/pull/117 https://github.com/typedrat/ghc-proposals/blob/constrained-type-families/pr… I propose Richard as the Shepherd. 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/

2 1

Status
by Joachim Breitner 03 Nov '19

03 Nov '19

Dear committee, Sany is smearing honey around my mouth on reddit, so I better leap into action and fulfill expectations. Since the last status, we * SPJ refined our processes in #271 * were asked to review these proposals: #274: Quick Look Impredicativity (Shepherd: Arnaud) #277: WinAPI cconv (Shepherd: Tamar) #270: Unified Namespace (Shepherd: Iavor) #254: Scale back "Function Result Type Signatures" (Shepherd: SPJ) #195: newtype Q (Texp a) (Shepherd: Iavor) * have a recommendation form the shepherd about: #277: WinAPI cconv (rec: accept) #274: Quick Look Impredicativity (rec: accept) #254: Scale back "Function Result Type Signatures" (rec: accept) * decided about the following proposals #259: No kind signatures on associated types (accept) #220: QualifiedImports (reject) #277: WinAPI cconv (accept) #254: Scale back "Function Result Type Signatures" (accept) #270: Unified Namespace (needs revision) We currently have to act on the following 3 proposals, keeping our backlog nicely stable. Good job! ## Waiting for Shepherd action Updated partial type signatures Shepherd: Vitaly https://github.com/ghc-proposals/ghc-proposals/pull/194 newtype Q (Texp a) Shepherd: Iavor https://github.com/ghc-proposals/ghc-proposals/pull/195 ## Waiting for committee decision Quick Look Impredicativity Shepherd: Arnaud https://github.com/ghc-proposals/ghc-proposals/pull/274 Cheers, Joachim -- 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

1 0

Please review #254: Scale back "Function Result Type Signatures" Shepherd: SPJ
by Joachim Breitner 03 Nov '19

03 Nov '19

Dear Committee, this is your secretary speaking: Scale back "Function Result Type Signatures" to keep pattern sigs as-is has been proposed by John Ericson https://github.com/ghc-proposals/ghc-proposals/pull/254 This proposal amends #228, so I propose Simon PJ as the shepherd, because he also shepherded #228. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 4

Please review #195: newtype Q (TExp a), Shepherd: Iavor
by Joachim Breitner 20 Oct '19

20 Oct '19

Dear Committee, this is your secretary speaking: Make Q (TExp a) into a newtype has been updated by Matthew Pickering https://github.com/ghc-proposals/ghc-proposals/pull/195 https://github.com/mpickering/ghc-proposals/blob/code-texp/proposals/0000-c… I propose Iavor as the shepherd, as he indicated support. 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

Quick look impredicativity (#274) — recommendation: accept
by Spiwack, Arnaud 17 Oct '19

17 Oct '19

Dear all, As the title implies: I'm hereby recommending accepting the Quick look impredicativity proposal. Summary: The proposal modifies the `-XImpredicativeTypes` extension with a well defined semantics which consists in considering n-ary applications, rather than binary. And look, in such an application, for arguments which absolutely require impredicative instantiation (either universally quantified type applications, or arguments where a universal type is guarded by an invariant type constructor). In order to have the expected behaviour for `($)` and `(.)`, the proposal also makes the left-hand argument of the arrow invariant with respect to instantiation (currently: contravariant). The proposal is to make this change effective, even if `-XRankNTypes` is turned on, but not `-XImpredicativeTypes`. The proposal also introduces an extension `-XContravariantFunctions` to restore the old behaviour, for compatibility. Rational: `-XImpredicativeTypes` is a useful extension which is currently in a rather sad state. I'm happy to see it stabilise to a clear semantics. The semantics in the proposal covers a ton of use cases. It strikes a very good balance between usefulness and predictability. The use of n-ary application in the type system also has good theoretical roots: sequent calculi have n-ary applications. (in manyrespects, bidirectional type systems are also about n-ary application). So I don't consider it a wart at all. The propsal's semantics, including the absence of contravariant functions, goes in the direction of _guessing less things_. This is a direction that many GHC features have taken lately. I think it's a very very good direction! Guessing can be damaging for predictability, but. more importantly, guessing has a tendency to compose badly with other typing features. (it is to be noted, too, that the implementation of contravariant functions. in GHC, eta-expands the function, which can casually change its semantics, if the function was bottom). So, everything in this proposal does look good to me, except that, I think, I would like a deprecation route for the `-XContravariantFunctions` extension. Otherwise, we will be stuck with legacy code forever. Best, Arnaud

5 10

Question about "Add Unified Namespace" (#270)
by Iavor Diatchki 17 Oct '19

17 Oct '19

Hello, I am the shepherd for #270, "Add Unified Namesapce", which was submitted for us to review around September 25. I read the proposal when it was submitted, but pretty much since then there has been continuing discussion with various new ideas being fleshed out. So, I've been waiting for things to stabilize a bit, before I re-read it, and ask for feedback from the committee. Given that it has been about 3 weeks, and there are still more comments and suggestions, I was wondering if it would be appropriate to move it back to the "discussion" phase, or if we should leave things as they are and keep waiting. Thoughts? -Iavor

5 7