March 2021 - ghc-steering-committee

Please review #283: Local modules, Shepherd: Arnaud
by Joachim Breitner 17 Mar '21

17 Mar '21

[Corrected message] Dear Committe, Local modules has been proposed by Richard Eisenberg https://github.com/ghc-proposals/ghc-proposals/pull/283 https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/00… This is actually a re-submission, so the Shepherd was and still is Arnaud. (Sorry, Vladislav, but you’ll get something to do soon I am sure :-)) 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 #283: Local modules, Shepherd: Vladislav
by Joachim Breitner 17 Mar '21

17 Mar '21

Dear Committe, Local modules has been proposed by Richard Eisenberg https://github.com/ghc-proposals/ghc-proposals/pull/283 https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/00… I propose Vladislav, as our newest member, to be the shepherd for this gem. 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

Status #281
by Iavor Diatchki 17 Mar '21

17 Mar '21

Hello, Just FYI, as I have updated the status of #281 to "revision needed" as we discussed. -Iavor

1 0

#403: Cleanup lexical structure, recommendation: accept
by Spiwack, Arnaud 17 Mar '21

17 Mar '21

Dear all, As the shepherd for proposal #403 Cleanup lexical structure of numbers and identifiers <https://github.com/ghc-proposals/ghc-proposals/pull/403>, let me recommend acceptance. This proposal does two things related to unicode characters - Codify the actual current lexing of unicode symbols, which is actually different from the Haskell 2010 report (in particular, only ascii digits are allowed in number literals) - Adds the possibility to use unicode letters which are neither upper case nor lower case (such as many asian scripts) as trailing symbols for identifier (as well as in String and Char literals) It doesn't make it possible (nor close the door) to use letter-like numbers (such as latin numerals) as identifiers, nor use non-ascii digits in number literals. As the title entails, it's essentially a clean up of the documentation, to match reality. It seems quite uncontroversial.

7 8

Please review #378: Support ergonomic dependent types, Shepherd: Simon PJ
by Joachim Breitner 11 Mar '21

11 Mar '21

Dear Committe, Support ergonomic dependent types has been proposed by Richard Eisenberg https://github.com/ghc-proposals/ghc-proposals/pull/378 https://github.com/goldfirere/ghc-proposals/blob/dependent-types/proposals/… This is a meta-proposal, aimed at refining our criteria when evaluating proposals, and wants us to confirm that we take compatibility with a future world where Haskell gains more dependently typed features into account, and welcome changes that we would likely reject if we did not expect to move towards that future. (My rephrasing, please have a look at least at “Motivation” and “Proposed Change Specification”). We might need more of a Moderator than a Shepherd here… I propose that Simon PJ leads us to a decision here. I know that Simon has a strong opinion on this already and might not be a “neutral moderator”. But opinions are not a bad thing per se, and I think this questions requires Chair-level involvement. 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/

4 4

New (and old) members of the Committee
by Alejandro Serrano Mena 11 Mar '21

11 Mar '21

Dear Committee, It’s my pleasure that announce that the three members with an expired term (Joachim, Iavor, and Richard) have renewed their membership. In addition, we have a new member in the Committee: Vladislav Zavialov. We found all four applications to be really strong! Could anybody help me adding Vladislav to the mailing list and giving him the proper permissions? That way I could give him a proper welcome to the Committee :) Alejandro

5 6

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

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Support ergonomic dependent types (#378)
by Simon Peyton Jones 09 Mar '21

09 Mar '21

(Writing to the committee rather than polluting the DT proposal thread.) We have a bullet "Does not create a language fork" in the review criteria<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. I treat it like the other criteria, a fork-like proposal is a red flag, but not an automatic reject. This relates back to our earlier conversation about proposal properties. Eric suggested: * Backward compatibility. Does an extension *expand* the language or *change* it? In other words, does an extension strictly accept more programs than before, or can it change the meaning of existing programs, or even reject previously valid programs? * Plausible default. Do we expect the extension to eventually be on-by-default (in GHCxxxx) and effectively disappear, or will it continue to be opt-in? -XStrict or -XRebindableSyntax are examples of an extension that we want, but that are not plausible defaults. * Localised. Is an extension *contained* within a module or is it *infectious*? Does my choice of extensions when writing a module affect which extensions downstream clients must enable? (I would say most extensions are contained, e.g. you can apply a type family without enabling TypeFamilies or match on a pattern synonym without enabling PatternSynonyms. However, you cannot call a function that takes an implicit parameter without enabling ImplicitParams.) Reading our "fork-like" criterion, it seems to be saying "it's fork-like if it is not a plausible default (in the above sense), and fork-like is bad". But as -XStrict and -XRebindableSyntax show, not being a plausible default isn't necessarily bad. Do we want to revise our language in the criteria? Simon From: Eric Seidel <notifications(a)github.com> Sent: 09 March 2021 14:05 To: ghc-proposals/ghc-proposals <ghc-proposals(a)noreply.github.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; Assign <assign(a)noreply.github.com> Subject: Re: [ghc-proposals/ghc-proposals] Support ergonomic dependent types (#378) Do we have a write up of what it means to be fork-like? Or what role the fork-like property plays in our deliberations? We have a bullet "Does not create a language fork" in the review criteria<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. I treat it like the other criteria, a fork-like proposal is a red flag, but not an automatic reject. - You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.

1 0

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