April 2020 - ghc-steering-committee

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

#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 #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

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] RecordDotSyntax language extension proposal (#282)
by Simon Peyton Jones 03 May '20

03 May '20

Dear GHC steering committee Shayne and Neil have updated the RecordDotSyntax proposal in the light of our conclusions. We have debated this extensively, so the question is now not so much about content as presentation: is the proposal complete, clear, and precise? I think it’s pretty good, and I propose that we now accept it as-is. I’ll take silence as assent. Please yell by close of play Weds 22 April if you’d like any further changes. Thanks! Simon From: Shayne Fletcher <notifications(a)github.com> Sent: 11 April 2020 17:59 To: ghc-proposals/ghc-proposals <ghc-proposals(a)noreply.github.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; Mention <mention(a)noreply.github.com> Subject: Re: [ghc-proposals/ghc-proposals] RecordDotSyntax language extension proposal (#282) @simonpj<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> I'd like to invite the authors to update their proposal to incorporate (C2a) We are happy to report that the proposal has been updated as per the committee's requests. * To write out the changes to the grammar, especially how to deal with specifying aexp2.x (see Note 5) See section 2.3<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. * To address the question of what happens if a field name is an operator (see Note 6) See section 2.1.3<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. Then the committee can do a final review and sign it off. We should now like to formally request the committee's final review and sign off. We thank once again yourself and the committee for your time and consideration! — You are receiving this because you were mentioned. 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…>.

3 2

Acceptance of proposal #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default
by Tom Harding 26 Apr '20

26 Apr '20

Hi all, I’ve announced the acceptance of this proposal on the GitHub thread. I had meant to do this last week, but world events have interrupted my scheduling quite a lot more than I’d like... https://github.com/ghc-proposals/ghc-proposals/pull/314#issuecomment-619588… The one outstanding question, which I think is definitely worth answering, is whether the Monad of No Return proposal currently has a shepherd. SPJ: do you know whether there’s any “active shepherding” around this proposal? Or is the current action just simply waiting for a few releases until the majority of Hackage is writing Applicative/Semigroup instances? My understanding is the latter, but I think it’s worth making it explicit somewhere. Thanks, Tom

1 0

Re: [ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default
by Tom Harding 14 Apr '20

14 Apr '20

Hi all, My feeling is that, having incorporated Richard’s suggestions around clarity of the error, we’re broadly happy with this. This proposal was put forward two weeks ago, and it seems that those who have responded are in favour of it. It does raise questions around the current state of the “Monad of No Return” plan, but I think that’s an ongoing effort that currently calls for patience (as the majority of libraries adopt the proposed changes), and I maintain that this proposal would help that effort. Does anyone have anything further that they’d like to add? Otherwise, if no one has any objection, perhaps this proposal can be accepted at the end of the week. Thanks, Tom

2 1

Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default
by Tom Harding 05 Apr '20

05 Apr '20

Friends, This proposal seems very reasonable to me, and the ramifications are minimal. Consequently, I recommend that we accept. I’d now like to open the proposal up to committee discussion. My belief is that the issue be fairly uncontentious (particularly as prior behaviour can be fully restored by explicitly passing the relevant `-Wno-...` flags to the compiler), but I welcome any thoughts either way. Thanks, Tom

5 5

merging #111: Linear Types
by Richard Eisenberg 03 Apr '20

03 Apr '20

Hi committee, On Oct 22, 2018, we conditionally accepted the linear-types proposal, which I have been shepherding. Proposal: https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li… <https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li…> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/111 <https://github.com/ghc-proposals/ghc-proposals/pull/111> Conditional acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-431944… <https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-431944…> (you may need to "load more items" many times to view this, sadly) Since the acceptance, there has been continued debate. Some of this has been about the syntax, which was left as a loose thread in the conditional acceptance. That debate has now been resolved, and the proposal reflects the final outcome of that. There is no comment declaring the new syntax accepted, but https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-519175… <https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-519175…> describes my recommendations, which were unopposed in the committee discussion. Recently, there has been some talk of rejecting the proposal. Considering we have already accepted the proposal, discussion of rejection seems out of scope. (Of course, anyone is free to make a separate, new proposal trying to revoke this one.) I I think it would clarify the status of this proposal if we merged the proposal text, labeling it clearly as conditionally accepted -- especially now that all remaining issues are around implementation issues, not design issues. (I'm including the specification of type inference as an implementation issue, because there is, as yet, no attempt to specify type inference beyond the implementation. It is hoped that we will rectify this, in time.) In anticipation of this, I've updated the proposal text to include the acceptance conditions. So: may we merge? I almost just did it on my own, taking rights as shepherd, but I did not want to make a unilateral move that might be seen as controversial. (Given that we have accepted the proposal, I don't think it is controversial. But then unilateralists often don't consider themselves to be controversial.) If this email gets silence, I'll likely just merge on my own early next week. Thanks! Richard

2 1

Record dot syntax: time to vote
by Simon Peyton Jones 02 Apr '20

02 Apr '20

Colleagues Now that we have agreed a set of alternatives on using dot notation for records, let's vote. We all recognise and respect that syntactic choices are a judgement call, and that reasonable people may diff in their judgements. But we need to come to as resolution and voting is a good way to do that. Please put your votes on the Google doc. I've make a section for that at the end. The document is here<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goog…>. Just write down your preferences, in order, preferred ones first. Joachim runs an election algorithm that makes it worth specifying a total order on all options, including ones you don't like. For any you omit, you are saying "if these ones are the top contenders I have no preference between them". You can specify ties, again meaning "no preference between these". For the over-interested, the algorithm is Condorcet<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipe…>; in the unlikely case that it does not produce a winner, we revert to Schultze<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipe…> Please read the document, including the Notes, carefully! We have ended up with a lot of variations, and their numbering is historical not logical. (I considered renumbering but thought that would be more confusing than helpful.) As the shepherd I am supposed to make a recommendation; it is below. Simon Shepherd's recommendations Here is my recommendation: C6 > C2b > C3 > C2a > C7 > C4 > C5 > C1 I recommend acceptance Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). I have been unhappy with GHC's story for records for two decades. (E.g. Lightweight extensible records for Haskell, Haskell Workshop, Paris 1999.) But the design space is so complicated that we never found something that felt "obviously right". So we did nothing drastic, and I think that was right. But there was incremental progress, sketched here<%5d(https:/gitlab.haskell.org/ghc/ghc/wikis/records/overloaded-record-fields>: * DuplicateRecordFields lets you have multiple records with the same field name. * The HasField class lets us define overloaded record selection and update functions. The proposal we are now discussing has no type-system component; it is only about syntactic sugar, allowing you to use dot-notation for field selection. (Various extensions about syntax for update were discussed, but no longer form part of the proposal; what is left is the core.) I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough. Alternatives I like: * I urge us to adopt (C6). I really really want (f M.N.x) to parse the same as (f M.n.x), where the only difference is the capitalisation of the second-last element of M.n.x. I'm leaning strongly on the connection with qualified names. We already have qualified names, and they are incredibly useful. Qualified names already treat "." specially. Moreover the proposal uses "." in precisely the same way as qualified names: a qualified name M.x allows you to pick x from the module M; this proposal allows r.x to pick a field x from a value r. I like this uniformity of both concept and syntax. * (C2b) is a weakened form of (C6) that does not allow naked selectors, thus (f .x) where there is a space before the ".". I don't see any difficulty with the postfix operator story, so I prefer (C6). But (C2b) is a little more conservative. Alternatives I actively dislike: * I urge against (C1) as I say above. * I dislike (C5) strongly, because it makes (f M.N.x) parse completely differently from (f M.n.x). The authors of the proposal say that they would withdraw the proposal outright (or at least disassociate themselves) if we adopted (C5). * I dislike (C7) for the same reason: (f M.N.x) is legal but (f M.n.x) is not. * I dislike (C4) because nothing should bind more tightly than function application. I hate that (f r .x s .y) would mean (f (r.x) (s.y)). Yes, we already have that (f r {x=2}) means (f (r {x=2})), but I think that's terrible, and we should not perpetuate it. Alternatives in the middle * (C2a) and (C3) are just like (C2b) and (C6), but additionally allow a tightly-binding record selection after a parenthesised expression. Thus (f (g x).y) means (f ((g x).y)). Allowing this is a bit tricky to specify, and the link to qualified names is much weaker. I don't think it pays its way.

10 38