May 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

Please review #292: ByteArray Literals, Shepherd: Vitaly
by Joachim Breitner 24 Jun '20

24 Jun '20

Dear Committee, this is your secretary speaking: ByteArray Literals has been proposed by Andrew Martin (based on a proposal by Oleg Grenus) https://github.com/ghc-proposals/ghc-proposals/pull/292 https://github.com/andrewthad/ghc-proposals/blob/bytearray-literals/proposa… I propose Vitaly 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/

3 3

Please review #303: Constraint based arrow notation, Shepherd: Chis Done
by Joachim Breitner 05 Jun '20

05 Jun '20

Dear Committee, this is your secretary speaking: Constraint based arrow notation has been proposed by Aleix King https://github.com/ghc-proposals/ghc-proposals/pull/303 https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-no… I propose Chris Done as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

5 14

#195
by Simon Peyton Jones 26 May '20

26 May '20

Iavor Matthew says > Please can we move on from this proposal! You are the shepherd. Iavor. Bringing the discussion to a conclusion is your role. I'm not arguing against acceptance. I have reservations about our overall TH story, but we should not let the best be the enemy of the good. Let's keep moving. Simon

3 2

Please review again: Make Q (TExp a) into a newtype #195
by Iavor Diatchki 22 May '20

22 May '20

Hello, I am the shepherd for #195, about a small change to TH, to wrap `Q (TExp a)` into a newtype. This would be quite handy for a variety of reasons described in the proposal and the comments on the proposal thread: https://github.com/ghc-proposals/ghc-proposals/pull/195 During the last discussion we requested the proposal to be modified to clarify some points. Matt has done that, so it is time for another review. The previous discussion thread is here: https://mail.haskell.org/pipermail/ghc-steering-committee/2019-November/001… I still think this is a good idea, and recommend acceptance. Since we've already discussed this once, I'll assume acceptance in about a week, if I don't hear from anyone, although I'll wait until at least Simon PJ and Richard confirm that the issues they raised last time have been addressed. -Iavor

2 2

#216: Qualified Do again, recommendation: accept the alternative
by Joachim Breitner 21 May '20

21 May '20

Dear Committe, Proposal: https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-d… Discussion (long, sorry): https://github.com/ghc-proposals/ghc-proposals/pull/216 Summary: Over a year ago (on my birthday then) Arnaud created a “local do” proposal that would be a more targetted variant of RebindableSyntax, just for “do”. In June, we sent it back because a simple syntactic desugaring to records didn’t quite seem right (bad type inference). In March, the authors can back with an alternative, which was using a Module name instead of a value of record type to indicate that monadic operations to use. This nicely solved the type system issues and meant that the translation can happen (in principle) in the parser or renamer stage. But some of us noticed that a builder record is nicer after all, and we can fix the type system issues, mostly by introducing a new concept of “fully settled type”; with analogies to TH stage restrictions. The authors updated the proposal accordingly, but also list the alternatives in the documents. Based on the GitHub thread we have varying opinions among the committee. Nevertheless, I think the authors have done a great and patient job so far, so we owe them a hopefully conclusive discussion. The main question we have to decide is: record-based or module based Record based: ➕ A single entity one can import, reexport, even rebind ➕ A single entity that can carry the documentation ➕ One module can export multiple builders ➕ Looking forward, the builder could be dynamically constructed (i.e. a local value) ➕ Concept of fully settled may be useful elsewhere in the future and can be expanded ➖ Needs a new concept of “fully settled” that we don’t have elsewhere ➖ Initially, “fully settled” introduces staging restrictions; builder values may not be usable everywhere where they are in scope. ➖ Lots of fluff on the defining side (define a likely one-off record + a value) ➖ May require extensions (e.g. RankNTypes, ImpredicativeTypes) on the defining side, even for a builder for the “normal” Monad (see https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-600746… for an example for the previous two points) ➕ Some compositionality (functions modifying builders), but ➖ not as universal as one would hope, as there is not a single builder type (different qualified monads likely use different record type) ➕ Can support “passing arguments to do” via `(monadBuilder @Maybe).do` or `(b cfg).do` (once the notion of “fully settled” is powerful enough) Module based: ➕ Simpler to specify and understand: Only affects parsing, possibly renaming. No interactions with the type system. ➕ Works out of the box with, say, `Prelude.` as the qualifier ➕ Benefits from future improvements to the module system ➖ Would need separate syntax for “passing arguments to do”, should we want that ➕ But if we had that, it can implement the record-based approach, by passing a recoord to a suitable qualified do monad, as Iavor observes: https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-598859… The module-based approach would additionally raises the question whether * the desugaring to M.(>>) means (>>) as provided by (some) M”, akin to how plain do notation works. * the desugaring to M.(>>) means just that (and requires (>>) to be imported as well), akin to how RebindableSyntax works There was also a brief discussion of whether this should extend the set of operations involved to a `last` function that is used in the translation rule for a single-statement do notation, but it did not catch on. Recommendation: While both approaches are reasonable and have their merits, I recommend to accept the Module based approach. It supports most use-cases presented so far, in particular the Linear.do as envisioned by the authors, so it seems good enough™. Furthermore, it certainly is significantly simpler, given that it can be specified purely in terms of naming things, so we have a higher chance that this will work well with other existing and future language features. Should the committee follow that decision, I recommend to pick the variant where the value does not need to be in scope, so that its mechanism is close to the normal do notation, and that you can write import Linear (runLinear, other, stuff) … Linear.do { … } without mucking with qualified imports or shadowing (>>). It seems odd to require the user to add ((>>), (>>=), fail) to an import list when you don’t actually mention that name anywhere. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

11 59

Please review #275: Rebindable Application, Shepherd: Richard Eisenberg
by Joachim Breitner 19 May '20

19 May '20

Dear Committee, this is your secretary speaking: Rebindable Application has been proposed by tydeu (Mac Malone) https://github.com/ghc-proposals/ghc-proposals/pull/275 https://github.com/tydeu/ghc-proposals/blob/overloaded-application/proposal… I propose Richard Eisenberg 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 #320: recommendation: accept
by Richard Eisenberg 13 May '20

13 May '20

Hi committee, I am the shepherd for #320, about a tweak to the handling of associated-type defaults in hs-boot and signature files. I recommend acceptance. Proposal: https://github.com/obsidiansystems/ghc-proposals/blob/signature-type-instan… <https://github.com/obsidiansystems/ghc-proposals/blob/signature-type-instan…> Recommendation (in GitHub thread): https://github.com/ghc-proposals/ghc-proposals/pull/320#issuecomment-623346… <https://github.com/ghc-proposals/ghc-proposals/pull/320#issuecomment-623346…> As stated in our published process (https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>), technical conversation should go on the GitHub thread, while evaluative comments can go on this thread in the mailing list. I expect this will be boring and uncontroversial to many of us. I will accept this in one week unless debate has sprung up. Thanks! Richard

2 1

Chris Allen standing down
by Simon Peyton Jones 06 May '20

06 May '20

Friends Chris Allen has asked to step down from the GHC Steering Committee - he just has too much else to do. Thank you Chris for your contributions! I hope that you will still keep a watching eye on GHC proposals as they go by - your perspective as a Haskell user is very important. We always risk being supplier-dominated. Joachim, will you update the committee list? I'm not sure if this is the right moment to seek new nominations. Any opinions? Thanks again, Chris. Simon

3 2

Please review #285: -XNoImplicitForAll, Shepherd: Simon Marlow
by Joachim Breitner 04 May '20

04 May '20

Dear Committee, this is your secretary speaking: -XNoImplicitForAll has been proposed by John Ericson https://github.com/ghc-proposals/ghc-proposals/pull/285 https://github.com/Ericson2314/ghc-proposals/blob/no-implicit-forall/propos… I propose Simon Marlow as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 9