October 2019 - ghc-steering-committee

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

Winapi pseudo calling conv (#277) --- recommendation: accept
by Sandy Maguire 02 Oct '19

02 Oct '19

Hi all, Proposal 277 is on the topic of a psuedo calling convention for windows, where on x86 you need to use `stdcall`, but on x86_64 it should be `ccall`. The base and Win32 packages both use extensive amounts of CPP to work around this. This proposal is to add a `winapi` calling convention that does the right thing regardless of the platform architecture. With the caveat that I am not well versed in FFI or Windows, *my recommendation is to accept. *This is a very small proposal that can immediately be used to clean up over 650 CPP invocations throughout the ecosystem. It's clearly a problem that people are running into, and we should focus on easy quality of life improvements. As usual, silence will be considered assent! Best, Sandy -- I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/

2 3