April 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

Please review #409: Exportable named defaults, Shepherd: Eric
by Joachim Breitner 30 Sep '21

30 Sep '21

Dear Committe, Exportable named defaults has been proposed by Mario https://github.com/ghc-proposals/ghc-proposals/pull/409 https://github.com/blamario/ghc-proposals/blob/exportable-named-default/pro… I propose Eric as the Shepherd. This did not gather a lot of attention on Github, or rather none, so Eric, maybe also consider whether this needs to be advertised more, or maybe who should be pointed to it. 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 36

#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

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

26 May '21

Dear GHC steering committee OK Richard has now revised the "Design for Dependent Types" proposal, and has resubmitted it. As we asked, it now includes the design sketch that constitutes the direction of travel advocated in the proposal, rather than merely referring to it. Here it is once more<https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/…> I propose acceptance. Remember: * We would not be accepting every detail of the design in Section 4 - rather, we expect further specific proposals as we move in the direction described in the proposal. So we should not debate the fine print of Section 4. * We would be accepting that the proposal describes a direction of travel that we are happy with. That in turn gives people the confidence to invest efforts in those more detailed proposals. As the "Proposed change specification" says: "When evaluating new proposals, the GHC committee would consider compatibility with the design sketch below. 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." Any views? Questions of clarification or technical questions belong on the comment stream. Thanks Simon From: ghc-steering-committee <ghc-steering-committee-bounces(a)haskell.org> On Behalf Of Simon Peyton Jones via ghc-steering-committee Sent: 06 April 2021 13:58 To: ghc-steering-committee(a)haskell.org Subject: Re: [ghc-steering-committee] Recommendation for #378: support the design for dependent types Richard and I have discussed this. We concluded that we'd put it back into "Needs revision" status. He's going to expand it (substantially) to include the proposed design sketch of dependent types on the GHC wiki<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>. Then he'll resubmit in the hope of getting approval of the design in principle, subject to subsequent discussion of the fine detail. Simon From: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Sent: 29 March 2021 13:17 To: ghc-steering-committee(a)haskell.org<mailto:ghc-steering-committee@haskell.org> Cc: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Subject: Recommendation for #378: support the design for dependent types Dear GHC Steering Committee I'm recommending acceptance of Proposal #378: Support the design for dependent types<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha…>. 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>: 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

8 16

Please review #415: OPAQUE pragma, Shepherd: Tom
by Joachim Breitner 17 May '21

17 May '21

Dear Committe, OPAQUE pragma has been proposed by Christiaan Baaij https://github.com/ghc-proposals/ghc-proposals/pull/415 https://github.com/christiaanb/ghc-proposals/blob/master/proposals/0000-opa… I’ll propose Tom 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 8

#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

Please review #412: splice imports, Shepherd: Vladislav
by Joachim Breitner 30 Apr '21

30 Apr '21

Dear Committe, Explicit Splice Imports has been proposed by Matthew Pickering https://github.com/ghc-proposals/ghc-proposals/pull/412 https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/0… I’ll propose Vladislav 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/

1 0

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