March 2021 - ghc-steering-committee

Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel
by Joachim Breitner 08 Jan '22

08 Jan '22

Dear Committee, this is your secretary speaking: NoFallibleDo proposal has been proposed by Cale https://github.com/ghc-proposals/ghc-proposals/pull/319 https://github.com/obsidiansystems/ghc-proposals/blob/no-fallible-do/propos… I propose Eric Seidel as the shepherd. 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/

6 18

#390: Fine-grained pragmas, recommendation: accept
by Vitaly Bragilevsky 18 Sep '21

18 Sep '21

Dear Committee, Our own Alejandro has been proposed Fine-grained pragmas for classes, families, and instances https://github.com/ghc-proposals/ghc-proposals/pull/390 https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/000… His idea is to bring the flexibility of overlaps/overlapping/overlappable pragmas to termination checking, type inference, and constraint solving. Alejandro proposes to introduce the following %-modifiers (as in already accepted #370, https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-m… ): %NoTerminationCheck %LiberalCoverage %LiberalInjectivity %Overlapping %Overlappable %Overlaps to liberate conditions for classes and instances, type families, forall-types, etc. The first three modifiers can be used instead of the scary-sounding UndecidableInstances extension. The last three modifiers are supposed to be used instead of the overlap*-pragmas for instances we already have. Note that this proposal doesn't suggest deprecating those extensions and pragmas. I think that this proposal goes in the right direction and recommend accepting it. As far as I understand, all the committee members, including those with terms about to expire, have the right to either support this proposal or to raise a voice against it either here or at https://github.com/ghc-proposals/ghc-proposals/pull/390. Regards, Vitaly

5 7

Please review #400: Constrained COMPLETE sets, Shepherd: Cale
by Joachim Breitner 14 Sep '21

14 Sep '21

Dear Committee, this is your secretary speaking: Constrained COMPLETE sets has been proposed by Sebastian Graph https://github.com/ghc-proposals/ghc-proposals/pull/400 https://github.com/sgraf812/ghc-proposals/blob/constrained-complete-sigs/pr… This proposal tries to solve the same issue as Cale’s #399, and essentially has slightly different syntax. I therefore suggest that Cale is the shepherd, and hashes out with Sebastian the details of syntax so that they can both get behind it, and then makes a recommendation. 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/

2 3

Proposal #302: `\of`
by Richard Eisenberg 01 Jul '21

01 Jul '21

Hi all, Proposal #302 was submitted to the committee and assigned to Cale. He has made a recommendation on the GitHub trail, but I don't believe the committee has discussed this among ourselves. PR: https://github.com/ghc-proposals/ghc-proposals/pull/302 Proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-… Cale's recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/302#issuecomment-666075… The idea, in brief, is to introduce a new syntax (guarded behind -XMultiWayLambda) \of. Here is an example, which gives you the idea: mplus :: Maybe Int -> Maybe Int -> Maybe Int mplus = \of Nothing _ -> Nothing _ Nothing -> Nothing (Just x) (Just y) -> Just (x + y) The new keyword allows us to use a syntax similar to function definitions, but without repeating the name of the function. It is also like \case, but it allows multiple arguments. Guards are allowed, as usual. I really like this new syntax -- mostly because I find it very strange that we have to repeat the function name on every line. And then change the spacing when we change the function name. And I like the mnemonic "lambda of". And it allows me to write a where clause that is accessible in multiple different patterns, or an indented where clause that is usable in just one. If it didn't confuse readers, I would use this syntax all the time. Even so, I agree with Cale's recommendation to reject. We just have too much syntax! If someone were to come along and draft a concrete proposal of how we could, for example, use this syntax to replace both \case and if|, with a migration strategy, etc., then I might be in favor. Until then, I think we've spent our budget for cute, obscure bits of syntax. Richard

10 29

#371: Stop treating ~ magically. Rec: weak accept
by Richard Eisenberg 10 May '21

10 May '21

Hi all, I am shepherding proposal #371. Proposal: https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/00… Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/371 Summary: Currently, the type equality operator (~) is always in scope, but you can use it only if -XGADTs or -XTypeFamilies is enabled. The proposal instead changes this arrangement to export (~) from Data.Type.Equality (an existing module in `base`), and requiring -XTypeOperators to use it (as we do for all other infix operators in types). There is an 8-release migration plan, where for 6 releases, all uses of (~) that do not import it from Data.Type.Equality will get a warning telling the user to import Data.Type.Equality. The motivation for the proposal is uniformity: the goal is to treat (~) just like other type operators. Recommendation: I'm very much on the fence on this one, but in the end fall into the "accept" camp. The goal here is to achieve a simple cleanup in the language design (and implementation). It's a worthy goal, but it's disruptive. However, I think the disruption is small enough that it motivates the change. The fix for affected users is quite quick, and large-scale Haskell users probably already have a custom prelude that could make the change even easier to accommodate. Note also that TypeOperators is part of GHC2021, and so the change will likely only be a new import. What do others think? Without dissent, I will mark this proposal as accepted in two weeks. Thanks, Richard

6 16

Proposal #402 (changes to GADT syntax); rec: accept
by Richard Eisenberg 21 Apr '21

21 Apr '21

Hi GHCSC, I am the shepherd for Proposal #402, which has been submitted for our consideration. Proposal text: https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-g… PR discussion: https://github.com/ghc-proposals/ghc-proposals/pull/402 ----------------- Proposal Summary: The proposal changes a few aspects of GADT constructor syntax, in part to make them simpler, and in part to make them more expressive. Only non-record syntax is treated by this proposal; GADT record constructors are entirely unaffected. The two changes are: 1. Drop support for parentheses around result types in GADT constructor signatures. 2. Add support for nested quantifiers in GADT constructor signatures. Examples & motivation: 1. This would now be rejected: data T where MkT :: Int -> (Bool -> T) Those parentheses are not allowed. On the other hand data S where MkS :: Int -> Bool -> (S) remains accepted. This change is mainly to simplify the implementation, but it also helps users understand that the thing after `MkS ::` really is not a type: it's a list of constructor arguments written in a concrete syntax that looks like a type. See the proposal for more explanation of how this is not a type. 2. This would now be accepted: data Q a where MkQ :: forall e. Int -> e -> forall a -> forall b. a -> b -> Show a => Q (a,b) Note the appearance of `forall a ->`, `forall b.`, and `Show a =>` after visible arguments. Constructors with forall ... -> syntax (such as our MkQ) will not be allowed in expressions or patterns (that would require #281), but will be allowed in types. This change is a generalization of the syntax we have today, and it allows library authors more flexibility in designing interfaces, as they can now choose where type arguments should be written in a constructor. ------------------------ Recommendation: I recommend acceptance. 1. Dropping the parentheses sounds trivial, but keeping them means we have to do extra work in the design of our data structures to remember the parentheses. Because constructor "types" aren't types, this information isn't otherwise needed. 2. This generalization increases our expressiveness and removes what may feel like an artificial limitation. Furthermore, it is necessary in the case where we might have later arguments depend on earlier ones (possible for promoted constructors). Please share opinions on acceptance/rejection here, or technical thoughts on the ticket itself. I will accept in two weeks if there are no objections. Thanks! Richard

7 18

Recommendation for #378: support the design for dependent types
by Simon Peyton Jones 06 Apr '21

06 Apr '21

Dear GHC Steering Committee I'm recommending acceptance of Proposal #378: Support the design for dependent types<https://github.com/ghc-proposals/ghc-proposals/pull/378> As you'll see, there is a lot of useful context, but the payload is pretty simple When evaluating new proposals, the GHC committee would consider compatibility with the proposed design sketch of dependent types on the GHC wiki<https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell>. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type features. Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly. See also the committee's Review Criteria<https://github.com/ghc-proposals/ghc-proposals/#review-criteria>: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language. Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just as ever. Any views? Let's try to converge rapidly.... the proposal has been substantially refined by a lot of debate. Simon

6 6

Please review #371: Exporting ~ from Data.Type.Equality, Shepherd: Richard
by Joachim Breitner 27 Mar '21

27 Mar '21

Dear Committe, Exporting ~ from Data.Type.Equality has been proposed by Vladislav Zavialov https://github.com/ghc-proposals/ghc-proposals/pull/371 https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/00… This looks rather small, and Richard has already vetted and refined this, in particular about the migration story, so I think he could just as well shepherd this through. 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/

1 0

Please review #396: Defaulting plugins, Shepherd: Vladislav
by Joachim Breitner 19 Mar '21

19 Mar '21

Dear Committe, Defaulting Plugins has been proposed by Andrei Barbu https://github.com/ghc-proposals/ghc-proposals/pull/396 https://github.com/abarbu/ghc-proposals/blob/master/proposals/0000-defaulti… I propose Vladislav, as our newest member, to shepherd this. 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/

1 0

Please review #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
by Joachim Breitner 19 Mar '21

19 Mar '21

Dear Committee, this is your secretary speaking: Clarify primops using unboxed sum has been proposed by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/367 https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals… I’ll propose Simon Marlow as the shepherd. 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 9