February 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

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

Status
by Joachim Breitner 10 Mar '21

10 Mar '21

Dear Committee, another status update, because why not. A small reminder: These mails have two sections, one that’s a delta since last status, but below is a summary of all proposals we have to act on. Please at least scroll through that on each status mail to see if you are listed, maybe you forgot something (or I made a mistake). So here’s the delta since last month. * GHC2021 defined! Yay! * Bylaws merged! Yay * Simon², Iavor, Richard and me had thus their terms expired. The Simons, as key members, wanted to continue and were voted back in. The others are now “expiring”, until the next nomination round concludes. Alejandro is going to run that process. * we were asked to review these proposals: #390: Fine-grained pragmas, Shepherd: Vitaly * we have a recommendation from the shepherd about: #368: Warn on prefix/suffix operators (accept) * we have sent the following proposals back to revision - none - * we decided about the following proposals #313: Delimited continuation primops (accept) #387: The Char kind (accept) #368: Warn on prefix/suffix operators (accept) We currently have to act on the following 5 proposals, down by 2. ## Waiting for committee decision #381: Visible 'forall' in types of terms, Shepherd: Iavor Recommendation was to reject, but discussion went into the more abstract “whither dependent Haskell”. But what does this mean for this proposal? Iavor, can you pick this up again? #369: Add sumToTag# primop, Shepherd: Eric Essentially accepted, waiting for feedback from the author on final tweaks. Eric, care to nudge the author, or just do it? #302: \of, Shepherd: Cale No new discussion yet. It seems there was some confusion, which was cleared up by Tom, and Cale said he’ll pick it up now again. ## Waiting for Shepherd action #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Simon said he’d reject it on the Github PR. Still waiting for the discussion to start on the mailing list. #390: Fine-grained pragmas, Shepherd: Vitaly Still kinda new, but a recommendation would be good soon. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 18

Modification to record dot syntax propsal
by Simon Peyton Jones 06 Mar '21

06 Mar '21

Friends Please see this proposal #405 to split RecordDotSyntax into two extensions<https://github.com/ghc-proposals/ghc-proposals/pull/405> It is a small modification of #282 on record dot syntax. The top comment gives links to the versions of the proposal before and after the change. The main payload is: * Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates. I recommend acceptance of this proposal, but invite the committee's view on one point (the final bullet below). Here is the thinking * RecordDotSyntax is the extension that we will eventually want programmers to user. It will probably ultimately imply NoFieldSelectors. But we aren't quite ready make that choice yet. So we don't want to specify exactly what RecordDotSyntax does yet. * So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates. * This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions, OverloadedRecordDot and OverloadedRecordUpdates. * An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords). Please express your opinion. This should not take us long. (Technical and clarification questions would be best done on the Githhub thread, as always.) Simon

7 43

Please review #402: Stable GADT constructor syntax, Shepherd: Richard
by Joachim Breitner 23 Feb '21

23 Feb '21

Dear Committe, Stable GADT constructor syntax has been proposed by Vladislav Zavialov https://github.com/ghc-proposals/ghc-proposals/pull/402 https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-g… I propose Richard 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

Please review #403: lexical structure of numbers and identifiers, Shepherd: Arnaud
by Joachim Breitner 20 Feb '21

20 Feb '21

Dear Committee, this is your secretary speaking: Cleanup lexical structure of numbers and identifiers has been proposed by Oleg Grenus https://github.com/ghc-proposals/ghc-proposals/pull/403 https://github.com/phadej/ghc-proposals/blob/cleanup-lexical-structure/prop… I propose Arnaud 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

Please review #405: Split RecordDotSyntax, Shepherd: Simon PJ
by Joachim Breitner 20 Feb '21

20 Feb '21

Dear Committe, Split RecordDotSyntax into two extensions has been proposed by Shayne Fletcher https://github.com/ghc-proposals/ghc-proposals/pull/405 This is an amendment to #282, proposing to introduce separate extensions OverloadedRecordDot and OverloadedRecordUpdate instead. I’ll propose Simon PJ as the shepherd, given that he has shepherded #282. 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