March 2022 - ghc-steering-committee

Modern Scoped Type Variables #448: recommendation (mostly) accept
by Spiwack, Arnaud 11 Jul '22

11 Jul '22

Dear all, Let me bring to your attention the Modern Scoped Type Variables proposal, by our own Richard https://github.com/ghc-proposals/ghc-proposals/pull/448 . The proposal is a touch intimidating, because the text is large. But most of it comes from other, already accepted, proposals that this proposal is tidying up and tying together. What this proposal tries to achieve is to make a consistent text about all the recent changes to binding type variables. The proposal adds new principles to the `principles.rst` files which inform the changes proposed, of these, I have the following comments: - The Visibility Orthogonality Principle doesn't seem to have a very clear definition. It may be a sign that it's not something that is so important - The Explicit Binding Principle says that we need to be able to enforce that all type variables have a binding site. I think it's a bit strong: I would like Haskell to let me write a binding site for every type variable, but not necessarily to error out when that doesn't happen. That being said, I'm happy with warnings to help me along the way, but I don't think that this Explicit Binding Principle should be phrased in a way that requires adding extensions to control this behaviour. - The Contiguous Scoping Principle, which states that a binder binds in one contiguous region sounds dubious to me. I don't see a particular reason for this to be. --- In the proposed changes themselves: up to Section 5, the proposed changes are mostly existing accepted proposals, cleaned up with what was learnt since they were written, as well as to adhere to the new principles. These are mostly uncontroversial and the specification makes sense to me. I'm in favour of accepting all that. With the caveat that this proposal introduces quite a few extensions. And at this point, I'm still not quite sure what Richard recommends is the set of extensions that I should use (and I'm slightly dismayed that I believe that it will be a set of cardinal more than 1). I think this reflects a vision of extensions as switches to customise the behaviour of GHC. This vision, as I've stated before, is very alien to me: I see extensions as staging areas for features to become an integral part of Haskell. So I don't know what to think of all these extensions. I'm definitely not against splitting -XScopedTypeVariables into smaller components, if it is done so that they are reassembled in a different way in an alternative extension that would now be the recommended default (or at least is to become the next recommended default). Finally, there are Sections 6 to 8. These are entirely new. Though they are working towards the new principles (well, as far as I can tell, Section 6 doesn't contribute to the principles, but it is a stepping stone for both Sections 7 and 8). These sections are concerned with adding local let-bindings of type variables, in particular inside types and patterns. By the way, Section 7 proposes two syntaxes for let binders in patterns, and I *strongly* prefer the second syntax, which reads something like `f (let b = Bool) (True :: Bool) = …`. Anyway, these are new, I feel that they are a bit out of place in a proposal that is about tidying up the existing designs. That being said, they are here, and they seem like fairly uncontroversial to me, (except, probably the syntax `(let b = _)` to bind a variable to a type to be filled by the compiler). I'm fine with accepting these, though they may require a bit more scrutiny than the rest. Best, Arnaud

6 20

Please review: #454 Custom type warnings
by Tom Harding 25 Jun '22

25 Jun '22

Hi all, As Joachim noted, #454 <https://github.com/ghc-proposals/ghc-proposals/pull/454> is extracted from Adam’s previous efforts with the Unsatisfiable constraint <https://github.com/ghc-proposals/ghc-proposals/pull/433> proposal (which has since been accepted). In short, it covers an interface for custom warnings, and I can already think of plenty of ways I’d use it. I’d therefore like to recommend acceptance, and discuss any issues or changes. Thanks, Tom

6 9

Please review #451: Sized literals proposal; Shepherd: Simon M
by Richard Eisenberg 23 Apr '22

23 Apr '22

Dear Committee, This is your interim secretary speaking: Sized literals proposal, proposing syntax for literals for the new sized primitive numeric types, has been proposed by Sylvain Henry. https://github.com/ghc-proposals/ghc-proposals/pull/451 https://github.com/hsyl20/ghc-proposals/blob/sized-literals/proposals/0000-… I propose Simon M as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Richard

4 4

#425: invisible binders in type declarations; rec: accept
by Richard Eisenberg 07 Apr '22

07 Apr '22

Hi all, I am the shepherd for proposal #425, https://github.com/ghc-proposals/ghc-proposals/pull/425, proposing to add invisible binders in type declarations. The main payload of the proposal is to allow definitions like > data Proxy @k (a :: k) = Proxy instead of today's > data Proxy (a :: k) = Proxy which has no explicit binding site for k. This new syntax solves a number of smallish syntax conundra, as very well outlined in the proposal. In addition, the proposal includes two small unrelated tweaks to the syntax of type family instances; these are points (6) and (7) in the proposal. Both changes will break some obscure (but still realistic, knowing Haskell) programs, but both fixes are backward compatible. --- I recommend acceptance. The proposal is motivated nicely (do check out the examples) and solves a real problem. The new syntax fits in with other similar features. The small cleanups to existing syntax will lead to better error messages. The one drawback, as I see it, is that this proposal includes point (5), which is a breaking change to the way type synonyms work. Right now, we can say > type P = (Proxy :: k -> Type) and GHC will infer P :: forall k. k -> Type. Under this proposal, you would have to write > type P @k = (Proxy :: k -> Type) bringing k into scope explicitly. The fix is not backward compatible, and so I think this proposal should come with a migration strategy, where we warn about the former version for some releases before banning it. (Continuing to support it is possible, but it's very awkward to have a variable mentioned only in a synonym's right-hand side.) Sorry for the delay in producing this recommendation! Richard

5 8

#477: Unicode ellipsis, recommendation: accept
by Joachim Breitner 30 Mar '22

30 Mar '22

Dear Committee, Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov, and I’m shepherding it myself. https://github.com/ghc-proposals/ghc-proposals/pull/477 https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/47… This is a very small proposal that lets GHC understand the nice Unicode syntax `…` in places where in ASCII world we have .., under -XUnicodeSyntax. I am fond of Unicode in general, and I expect that users of - XUnicodeSyntax expect this to work, and therefore recommend acceptance of this proposal. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 14

Please review #475: New tuple and list syntax, Shepherd: Vlad
by Joachim Breitner 24 Mar '22

24 Mar '22

Dear Committee, New syntax for tuples and lists to remove punning has been resubmitted by Richard https://github.com/ghc-proposals/ghc-proposals/pull/475 https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/000… Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 18

Welcome Baldur and Chris, welcome again Eric, and Farewell Vitaly
by Joachim Breitner 11 Mar '22

11 Mar '22

Dear Committee and wider community, thanks to everyone who has put forward their nominations this round, and we are happy to welcome Chris Dornan, Baldur Blöndal and Eric Seidel as new or, in the case of Eric, re-joining members of the GHC Steering Committee! Chris and Baldur, if you haven’t already, please subscribe to our mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee and familiarize yourself with our processes at https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst You’ll find a list of proposals under discussion at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+la… and your opinion is welcome on all of them. The committee wants to thank Vitaly Bragilevsky for his full term of service on the committe. Your contributions were valued, and I certainly would be happy to see your nomination again at some point in the future. The next regular call for nominations (early resignations notwithstanding) will likely be in January 2023. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 6