July 2020 - 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

Bang patterns: 343
by Simon Peyton Jones 29 Aug '20

29 Aug '20

Friends Despite asking, I'm not seeing any support for proposal 343 "Enable bang patterns by default<https://github.com/ghc-proposals/ghc-proposals/pull/343>", except from the author. He makes a good case, but I think it's a case that you could make for quite a few extensions. I propose that we reject the proposal as written. Any objections? That leaves the wider question, best summarised by Joachim's post<https://github.com/ghc-proposals/ghc-proposals/pull/343#issuecomment-664631…>: we could occasionally add a new synonym for a bunch of extensions. I suppose we'd have to (a) debate and decide that process and (b) execute on the process. Perhaps that'd be useful but it's all work. Let's first see if there is real support for doing it. If so, probably the best thing would be for someone who wants it to happen to write a proposal (as Joachim has started) describing the process. Simon

5 5

#344: Negative Literals Improved, rec: accept
by Joachim Breitner 22 Jul '20

22 Jul '20

Dear Committee, a refinement to the NegativeLiterals extension has been proposed by Vladislav Zavialov (int-index). https://github.com/ghc-proposals/ghc-proposals/pull/344 https://github.com/int-index/ghc-proposals/blob/negative-literals-improved/… He noticed that x-1 parses as x (-1) which is probably not what people expect. With this change it would be parsed as x - 1 by requiring that a negative literal may not be preceded by a “closing toking”. Nice side effect: This makes NegativeLiterals a subset of LexicalNegation (according to the author). The proposal has been received positively by the crowd on Github. I suggest we accept that proposal. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 8

Please review #343: BangPatterns by default, Shepherd: Simon PJ
by Joachim Breitner 21 Jul '20

21 Jul '20

Dear Committee, this is your secretary speaking: BangPatterns by default has been proposed by AndreasPK https://github.com/ghc-proposals/ghc-proposals/pull/343 https://github.com/AndreasPK/ghc-proposals/blob/bang_by_default/proposals/0… I propose Simon PJ as the shepherd, as this affects a relatively fundamental principle of our work so far (all changes are guarded by language extensions), and accepting/rejecting this proposal likely has precedence character. 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/

3 2

Haddock
by Richard Eisenberg 13 Jul '20

13 Jul '20

Hi committee, With a steady level of activity adding new features to GHC, I fear we may be forgetting one important downstream client: Haddock. For a nice example of how our decisions can cause trouble, see https://github.com/goldfirere/singletons/issues/466#issuecomment-646117067. Despite appearing on the singletons bug tracker, that comment is all about Haddock support for https://github.com/ghc-proposals/ghc-proposals/blob/3dfec03b11e8829d7febbb7…, the -XStandaloneKindSignatures extension. This makes me wonder: should we invite a maintainer of Haddock to be an ex-officio (and voting) member of the committee? This would have two salutary effects: - It would force us to consider an important aspect of the user experience -- reading documentation -- of newly proposed features. - It would force us to give Haddock a heads-up about new features they may want to incorporate. If we don't think we need an ex-officio committee member, then perhaps we should instead require future proposals to describe a plausible impact on Haddock. I say "plausible impact" to suggest that the proposal text would not be binding on Haddock (which would be awfully dictatorial of us), but that it gives Haddock a starting place to consider their own design, while forcing proposers to think about this important-but-easily-neglected aspect of language evolution. What do we think? Richard

8 15