From trupill at gmail.com Wed Apr 1 06:00:54 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Wed, 1 Apr 2020 08:00:54 +0200 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> <6A51EA29-40C9-4388-8024-4C00F25467DE@richarde.dev> Message-ID: El mié., 1 abr. 2020 a las 0:09, Iavor Diatchki () escribió: > Hello, > > - Indeed, you could write some expressions that might look confusing at > first, but I don't see why would you? After all, one could use the exact > same argument for many other notations in pretty much any programming > language (e.g., operator precedences can be used to write confusing > code---it doesn't mean that they are not very useful sometime). > But I think it's important to think also of potentially confusing type errors which may arise if we allow such freedom. I find easier to simply say "f r .x" cannot be parsed, and then asking the user to disambiguate between "(f r).x" or "f r.x" than to allow it in the parser and then obtain a huge error message. Part of the reason why I'm so concerned about it is that my prediction is that this is not "just" any other extension. Many people, including beginners, will enable this by default, since it makes one slightly alien part of Haskell (field access) look like what they might be used to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed Apr 1 09:44:04 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 1 Apr 2020 10:44:04 +0100 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> <6A51EA29-40C9-4388-8024-4C00F25467DE@richarde.dev> Message-ID: <05D77FB9-24D1-4B99-BEBC-4F05725F790A@richarde.dev> Small note: It sounds like we're getting ready to wrap this up with that post of Simon's on GitHub. Might I humbly suggest we wait one more day? Declaring the committee's vote today, April 1, might only sow confusion. :) Richard > On Apr 1, 2020, at 7:00 AM, Alejandro Serrano Mena wrote: > > > > El mié., 1 abr. 2020 a las 0:09, Iavor Diatchki (>) escribió: > Hello, > > - Indeed, you could write some expressions that might look confusing at first, but I don't see why would you? After all, one could use the exact same argument for many other notations in pretty much any programming language (e.g., operator precedences can be used to write confusing code---it doesn't mean that they are not very useful sometime). > > But I think it's important to think also of potentially confusing type errors which may arise if we allow such freedom. I find easier to simply say "f r .x" cannot be parsed, and then asking the user to disambiguate between "(f r).x" or "f r.x" than to allow it in the parser and then obtain a huge error message. > > Part of the reason why I'm so concerned about it is that my prediction is that this is not "just" any other extension. Many people, including beginners, will enable this by default, since it makes one slightly alien part of Haskell (field access) look like what they might be used to. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Apr 1 11:48:13 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 1 Apr 2020 13:48:13 +0200 Subject: [ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default In-Reply-To: <1810F4C4-3566-4349-BCC8-70B1064F8126@live.co.uk> References: <1810F4C4-3566-4349-BCC8-70B1064F8126@live.co.uk> Message-ID: Dear all, Can someone enlighten me as to the current status of the Monad-of-no-return proposal? Which is the motivation for this proposal. Best, Arnaud On Wed, Apr 1, 2020 at 12:50 AM Tom Harding wrote: > 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 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bravit111 at gmail.com Wed Apr 1 16:48:55 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Wed, 1 Apr 2020 19:48:55 +0300 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: <05D77FB9-24D1-4B99-BEBC-4F05725F790A@richarde.dev> References: <0D3D6F19-933F-4ED9-BDF7-E294D8C3751A@richarde.dev> <6A51EA29-40C9-4388-8024-4C00F25467DE@richarde.dev> <05D77FB9-24D1-4B99-BEBC-4F05725F790A@richarde.dev> Message-ID: Well, this was not a problem 30 years ago: [image: 2020-04-01 19.45.59.jpg] Vitaly ср, 1 апр. 2020 г. в 12:44, Richard Eisenberg : > Small note: It sounds like we're getting ready to wrap this up with that > post of Simon's on GitHub. Might I humbly suggest we wait one more day? > Declaring the committee's vote today, April 1, might only sow confusion. :) > > Richard > > On Apr 1, 2020, at 7:00 AM, Alejandro Serrano Mena > wrote: > > > > El mié., 1 abr. 2020 a las 0:09, Iavor Diatchki () > escribió: > >> Hello, >> >> - Indeed, you could write some expressions that might look confusing >> at first, but I don't see why would you? After all, one could use the >> exact same argument for many other notations in pretty much any programming >> language (e.g., operator precedences can be used to write confusing >> code---it doesn't mean that they are not very useful sometime). >> > > But I think it's important to think also of potentially confusing type > errors which may arise if we allow such freedom. I find easier to simply > say "f r .x" cannot be parsed, and then asking the user to disambiguate > between "(f r).x" or "f r.x" than to allow it in the parser and then obtain > a huge error message. > > Part of the reason why I'm so concerned about it is that my prediction is > that this is not "just" any other extension. Many people, including > beginners, will enable this by default, since it makes one slightly alien > part of Haskell (field access) look like what they might be used to. > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 2020-04-01 19.45.59.jpg Type: image/jpeg Size: 24209 bytes Desc: not available URL: From simonpj at microsoft.com Wed Apr 1 22:28:18 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 1 Apr 2020 22:28:18 +0000 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: Message-ID: All: only a couple of people have commented on the draft post -- see "Draft post" section of https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit Usually I prefer explicit assent, but here I'm going to take silence for assent. Is everyone content for me to post tomorrow? Simon | -----Original Message----- | From: Simon Peyton Jones | Sent: 31 March 2020 11:09 | To: Joachim Breitner ; ghc-steering-committee | | Cc: Simon Peyton Jones ; Neil Mitchell | ; Shayne Fletcher | Subject: RE: [ghc-steering-committee] Record dot syntax: vote results | | Thanks Joachim. | | Everyone: I have extended our choices document with a draft post to the | Github thread. | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goo | gle.com%2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fed | it%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com%7Cc8647a2c84 | e5492710ab08d7d55b7d5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212 | 461226216730&sdata=ix%2FweGNzFIokAcesdcwqM4dufVpxputAQZH5DNv7ouc%3D&am | p;reserved=0 | | Can you review it, for both tone and content? You have edit permission, | so by all means improve the wording. Look for omissions. I want to bring | the discussion to a close, not re-ignite further debate, but be respectful | of those who disagree. | | Could you do so this week, by end Friday? I propose to leave the votes | recorded there, but when posting I'll move the post from the document | (deleting it from there) to GitHub. | | I'm cc'ing Neil and Shayne, the authors. Neil, Shayne: I think (and | desperately hope!) you'll be content with this outcome. Can you review my | draft post too? | | Simon | | | -----Original Message----- | | From: ghc-steering-committee | | On Behalf Of Joachim Breitner | | Sent: 30 March 2020 17:48 | | To: ghc-steering-committee | | Subject: Re: [ghc-steering-committee] Record dot syntax: vote results | | | | Dear Committe, | | | | thanks all for voting. The ranking of votes is now | | | | C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5 | | | | In particular C2a beats every other options by 7:4 or more, and is | | therefore the result of this poll. | | | | You can see more statistics at | | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cond | | | orcet.vote%2FVote%2FAB23CE70AC%2F&data=02%7C01%7Csimonpj%40microsoft.c | | | om%7Ce27e9c8f455b436e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7 | | | C1%7C0%7C637211837260982595&sdata=LLWCxVjXxyLqcJUZ9iMgB%2B5QYGMuHFzJga | | u9agTakiQ%3D&reserved=0 | | | | So, does this conclude this saga? | | | | Cheers, | | Joachim | | | | -- | | Joachim Breitner | | mail at joachim-breitner.de | | | | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | | im- | | | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b43 | | | 6e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372118372 | | | 60982595&sdata=GE%2BBYN7rA7zWgwuKlArv4PR%2Fm3IlmZ7PqWbGpgXUyms%3D& | | reserved=0 | | | | | | _______________________________________________ | | ghc-steering-committee mailing list | | ghc-steering-committee at haskell.org | | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | | | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce27e9c8f455b436e2be | | | e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 | | | 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= | | 0 From arnaud.spiwack at tweag.io Thu Apr 2 06:33:23 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 2 Apr 2020 08:33:23 +0200 Subject: [ghc-steering-committee] Record dot syntax: vote results In-Reply-To: References: Message-ID: I'm content. On Thu, Apr 2, 2020 at 12:28 AM Simon Peyton Jones via ghc-steering-committee wrote: > All: only a couple of people have commented on the draft post -- see > "Draft post" section of > > https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74/edit > > Usually I prefer explicit assent, but here I'm going to take silence for > assent. Is everyone content for me to post tomorrow? > > Simon > > | -----Original Message----- > | From: Simon Peyton Jones > | Sent: 31 March 2020 11:09 > | To: Joachim Breitner ; ghc-steering-committee > | > | Cc: Simon Peyton Jones ; Neil Mitchell > | ; Shayne Fletcher > | Subject: RE: [ghc-steering-committee] Record dot syntax: vote results > | > | Thanks Joachim. > | > | Everyone: I have extended our choices document with a draft post to the > | Github thread. > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goo > | gle.com > %2Fdocument%2Fd%2F1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7iY74%2Fed > | it%3Fusp%3Dsharing&data=02%7C01%7Csimonpj%40microsoft.com > %7Cc8647a2c84 > | > e5492710ab08d7d55b7d5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637212 > | > 461226216730&sdata=ix%2FweGNzFIokAcesdcwqM4dufVpxputAQZH5DNv7ouc%3D&am > | p;reserved=0 > | > | Can you review it, for both tone and content? You have edit permission, > | so by all means improve the wording. Look for omissions. I want to > bring > | the discussion to a close, not re-ignite further debate, but be > respectful > | of those who disagree. > | > | Could you do so this week, by end Friday? I propose to leave the votes > | recorded there, but when posting I'll move the post from the document > | (deleting it from there) to GitHub. > | > | I'm cc'ing Neil and Shayne, the authors. Neil, Shayne: I think (and > | desperately hope!) you'll be content with this outcome. Can you review > my > | draft post too? > | > | Simon > | > | | -----Original Message----- > | | From: ghc-steering-committee | bounces at haskell.org> > | | On Behalf Of Joachim Breitner > | | Sent: 30 March 2020 17:48 > | | To: ghc-steering-committee > | | Subject: Re: [ghc-steering-committee] Record dot syntax: vote results > | | > | | Dear Committe, > | | > | | thanks all for voting. The ranking of votes is now > | | > | | C2a > C2b > C4 > C1 > C7 > C6 > C3 > C5 > | | > | | In particular C2a beats every other options by 7:4 or more, and is > | | therefore the result of this poll. > | | > | | You can see more statistics at > | | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cond > | | > | orcet.vote > %2FVote%2FAB23CE70AC%2F&data=02%7C01%7Csimonpj%40microsoft.c > | | > | > om%7Ce27e9c8f455b436e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7 > | | > | > C1%7C0%7C637211837260982595&sdata=LLWCxVjXxyLqcJUZ9iMgB%2B5QYGMuHFzJga > | | u9agTakiQ%3D&reserved=0 > | | > | | So, does this conclude this saga? > | | > | | Cheers, > | | Joachim > | | > | | -- > | | Joachim Breitner > | | mail at joachim-breitner.de > | | > | | > | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach > | | im- > | | > | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com > %7Ce27e9c8f455b43 > | | > | > 6e2bee08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372118372 > | | > | > 60982595&sdata=GE%2BBYN7rA7zWgwuKlArv4PR%2Fm3IlmZ7PqWbGpgXUyms%3D& > | | reserved=0 > | | > | | > | | _______________________________________________ > | | ghc-steering-committee mailing list > | | ghc-steering-committee at haskell.org > | | > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | | > | committee&data=02%7C01%7Csimonpj%40microsoft.com > %7Ce27e9c8f455b436e2be > | | > | > e08d7d4ca3538%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637211837260982 > | | > | > 595&sdata=nEx7qjYqnST1TA74HRkgK4O1zW3tvqpM4Dx4ECCig7I%3D&reserved= > | | 0 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomjharding at live.co.uk Fri Apr 3 10:19:02 2020 From: tomjharding at live.co.uk (Tom Harding) Date: Fri, 3 Apr 2020 10:19:02 +0000 Subject: [ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default In-Reply-To: References: <1810F4C4-3566-4349-BCC8-70B1064F8126@live.co.uk> Message-ID: <3434F835-B8EF-4EFB-A358-8434605268FF@live.co.uk> Hi Arnaud, My understanding is we’re past phase 1, en route to phase 2, and may be here for quite a while. For reference, phase 1: Implement new warning in GHC which gets triggered when Monad instances explicitly override the default return and (>>) method implementations with non-lawful definitions (see compatible instance definition example in previous section). The warning was implemented in GHC 8.0 and is called -Wnoncanonical-monad-instances (there are variants of this warning flag for Monoid and Fail) but it is not included in either -Wall or -Wcompat. With that completed, phase 2 will be: When we're confident that the majority of Hackage has reacted to the warning (with the help of Stackage actively purs uing maintainers to update their packages) we turn the return and (>>) methods into a top-level binding and let GHC ignore lawful method definitions of return and (>>). https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/monad-of-no-return As Ben was the last to edit the page (albeit a year ago), perhaps he has some further insight? I’ve CC’d him, just in case. Thanks, Tom On 1 Apr 2020, at 12:48, Spiwack, Arnaud > wrote: Dear all, Can someone enlighten me as to the current status of the Monad-of-no-return proposal? Which is the motivation for this proposal. Best, Arnaud On Wed, Apr 1, 2020 at 12:50 AM Tom Harding > wrote: 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 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Fri Apr 3 11:15:49 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 3 Apr 2020 12:15:49 +0100 Subject: [ghc-steering-committee] merging #111: Linear Types Message-ID: 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-linear-types.rst Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/111 Conditional acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-431944078 (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-519175000 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Fri Apr 3 14:48:44 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 3 Apr 2020 16:48:44 +0200 Subject: [ghc-steering-committee] merging #111: Linear Types In-Reply-To: References: Message-ID: I'm OK with merging this since all loose threads seem to have been worked out. El vie., 3 abr. 2020 a las 13:16, Richard Eisenberg () escribió: > 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-linear-types.rst > Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/111 > Conditional acceptance: > https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-431944078 (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-519175000 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 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bravit111 at gmail.com Sun Apr 5 05:14:08 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Sun, 5 Apr 2020 08:14:08 +0300 Subject: [ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default In-Reply-To: <1810F4C4-3566-4349-BCC8-70B1064F8126@live.co.uk> References: <1810F4C4-3566-4349-BCC8-70B1064F8126@live.co.uk> Message-ID: Hi, I support this proposal. Vitaly ср, 1 апр. 2020 г. в 01:50, Tom Harding : > 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 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Sun Apr 5 09:23:43 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Sun, 5 Apr 2020 11:23:43 +0200 Subject: [ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default In-Reply-To: References: <1810F4C4-3566-4349-BCC8-70B1064F8126@live.co.uk> Message-ID: I'm also happy with the proposal as it stands. Alejandro El dom., 5 abr. 2020 a las 7:14, Vitaly Bragilevsky () escribió: > Hi, > > I support this proposal. > > Vitaly > > ср, 1 апр. 2020 г. в 01:50, Tom Harding : > >> 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 >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Sun Apr 5 15:29:37 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun, 5 Apr 2020 08:29:37 -0700 Subject: [ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default In-Reply-To: References: <1810F4C4-3566-4349-BCC8-70B1064F8126@live.co.uk> Message-ID: I think doing this only makes sense if the "Monad of no return" proposal is accepted. I know we have not discussed it here, so I imagine it is a libraries proposal, but I all I can find is some discussion from 2015, and not any kind of status page... Looks like Cale is a on that committee as well, so maybe he knows the status? Having said that, I personally already write my instances in the "new" style, so I am not opposed to enabling the warnings by default. -Iavor On Sun, Apr 5, 2020 at 2:24 AM Alejandro Serrano Mena wrote: > I'm also happy with the proposal as it stands. > > Alejandro > > El dom., 5 abr. 2020 a las 7:14, Vitaly Bragilevsky () > escribió: > >> Hi, >> >> I support this proposal. >> >> Vitaly >> >> ср, 1 апр. 2020 г. в 01:50, Tom Harding : >> >>> 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 >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Apr 9 17:16:51 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 09 Apr 2020 19:16:51 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative Message-ID: Dear Committe, Proposal: https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst 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-600746723 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-598859245 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 at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Fri Apr 10 07:58:41 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 10 Apr 2020 09:58:41 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: As one of the authors, I'm going to engage only lightly in this conversation. Just a few comments, for the moment ➖ 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-600746723 > for an example for the previous two points) > I don't believe this to hold. Impredicative record fields are plain Haskell 2010. 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. > I am, to be honest, very uncomfortable with the idea: if I explicitly didn't import something, I don't want it to be used in my program. A counter-argument is that types appear in desugared programs which were not imported, so maybe I'm overreacting. But I'm still uncomfortable. And it doesn't look like it's less of a complication than the fully-settled business. Overall, I personally quite prefer the record-based alternative. On Thu, Apr 9, 2020 at 7:17 PM Joachim Breitner wrote: > Dear Committe, > > Proposal: > > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst > 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-600746723 > 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-598859245 > > 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 at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Apr 10 08:43:32 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 10 Apr 2020 10:43:32 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> Hi, Am Freitag, den 10.04.2020, 09:58 +0200 schrieb Spiwack, Arnaud: > I am, to be honest, very uncomfortable with the idea: if I explicitly > didn't import something, I don't want it to be used in my program. A > counter-argument is that types appear in desugared programs which > were not imported, so maybe I'm overreacting. But I'm still > uncomfortable. I am surprised this is so controversial. There are many things in Haskell that are used that are not imported: * The desugaring of plain do notation (!) * The desugaring of if-then-else (no need to have True/False in scope) * The desugaring of boolean guards (again, no need to have True/False in scope) * Instances * And because of that, `foo.bar` according to RecordDotSyntax will not require `bar` to be in scope, as this is just an instance accessed via HasField "bar" (if I am not mistaken) In contrast, there is nothing where you have to import some `foo` when you don't actually mention `foo` in your source code. Which seems a pretty reasonable rule: Import the things you write; no more, no less! (Ok, there is one thing that was added recently: With Coercible you need to import the data constructor to coerce under a type constructors. Which I am not fond of.) And note that you’d still be explicitly importing the module name, which is the only thing you’d write in your program. So you can’t claim you “didn’t import something”. And: The same question actually applies to the record variant as well!, If we’d go for the record variant, would you expect the user to write import Linear (builder) or import Linear (builder, BuilderRecord(..)) in order to use `Linear.builder.do {…}`? > And it doesn't look like it's less of a complication than the fully- > settled business. To me, it does. Significantly so. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From rae at richarde.dev Fri Apr 10 13:51:32 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 10 Apr 2020 14:51:32 +0100 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: <91B323B3-B104-45CD-ADED-22C8DE4E95C3@richarde.dev> Despite being the one to articulate "fully settled" and how to make builders with it, I now favor the module-based approach. Thanks, Joachim, for writing out pros and cons. I agree with the pros and con you listed with the module-based approach. Let's also look at some pros of the record-based approach: > ➕ A single entity one can import, reexport, even rebind > ➕ A single entity that can carry the documentation > ➕ One module can export multiple builders With either of two module-system-improvement proposals (https://github.com/ghc-proposals/ghc-proposals/pull/283 or https://github.com/ghc-proposals/ghc-proposals/pull/295 ), these pros carry over to the module-based approach. The reason I switched camps, from favoring record-based to favoring module-based, is this argument, by John Ericson: https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-606109628 Here, John is reacting to my complaint that the module-based solution will, to be ergonomic, require either #283 or #295. But John points out that we don't need to wait for #283 or #295: we can implement the module-based system right away. It will be usable (but sometimes clunky) right away. It will satisfy the problems in the motivation right away. All #283/#295 would do is make it less clunky. Put another way: let's imagine a Haskell with either of #283 or #295 implemented. Then, I think, the module-based approach would be a very clear win, over a record-based approach with its one-off "fully settled" and strange restrictions on types. (The builder must have *some* record type, but any record type would do. There's nothing else like that anywhere.) So by choosing the record-based approach, we're cutting off access to the right design in the limit. Of course, #283/#295 are large proposals, still technically under discussion (but very quiet), and either one has a sizable implementation burden. I would never want to accept this current proposal in a way that would depend on #283/#295. But, as argued above, the module-based approach does not depend on these large proposals. My thoughts on the finer points: - I think the selectors should be in scope. It's simpler and less ambiguous this way, given the fact that one module can alias several modules to, say, M. I don't feel strongly on this point, though, and I see the arguments in the other direction. - I think this extension would be considerably more ergonomic if the new operators were not named (>>=), etc., but instead something like qualifiedBind, qualifiedThen, etc. This means that defining modules needn't be delicate around importing the Prelude, and importing modules don't need to worry about record selectors causing name clashes, etc., if they are not using this new extension. As we decide on this proposal, I would also like us to think about how this scales to other applications of rebindable syntax. For example, maybe we want M.if or M.[ x, y, z ] someday. I think the design *does* scale in such a way, which perhaps paves the way to deprecating -XRebindableSyntax. Richard > On Apr 9, 2020, at 6:16 PM, Joachim Breitner wrote: > > Dear Committe, > > Proposal: > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst > 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-600746723 > 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-598859245 > > 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 at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri Apr 10 15:28:02 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 10 Apr 2020 08:28:02 -0700 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <91B323B3-B104-45CD-ADED-22C8DE4E95C3@richarde.dev> References: <91B323B3-B104-45CD-ADED-22C8DE4E95C3@richarde.dev> Message-ID: Hello, My thoughts on this are on the git-hub thread, as I've been involved in the discussion for quite a while. I am in alignment with Joachim, that we should accept the module-based variant of the proposal. I don't have strong feelings on if the implicit names used by the transformation should be in scope or just accessible via an import. However, I think he makes a convincing argument that it would be pretty weird to require names to be in scope that are not visible anywhere in the source code, so following the choice we already made for ordinary `do` does make sense to me. -Iavor PS: Arnaud, not that it matters very much, but RankNTypes are not part of Haskell 2010. On Fri, Apr 10, 2020 at 6:51 AM Richard Eisenberg wrote: > Despite being the one to articulate "fully settled" and how to make > builders with it, I now favor the module-based approach. Thanks, Joachim, > for writing out pros and cons. I agree with the pros and con you listed > with the module-based approach. Let's also look at some pros of the > record-based approach: > > ➕ A single entity one can import, reexport, even rebind > ➕ A single entity that can carry the documentation > ➕ One module can export multiple builders > > > With either of two module-system-improvement proposals ( > https://github.com/ghc-proposals/ghc-proposals/pull/283 or > https://github.com/ghc-proposals/ghc-proposals/pull/295), these pros > carry over to the module-based approach. > > The reason I switched camps, from favoring record-based to favoring > module-based, is this argument, by John Ericson: > https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-606109628 > Here, John is reacting to my complaint that the module-based solution will, > to be ergonomic, require either #283 or #295. But John points out that we > don't need to wait for #283 or #295: we can implement the module-based > system right away. It will be usable (but sometimes clunky) right away. It > will satisfy the problems in the motivation right away. All #283/#295 would > do is make it less clunky. > > Put another way: let's imagine a Haskell with either of #283 or #295 > implemented. Then, I think, the module-based approach would be a very clear > win, over a record-based approach with its one-off "fully settled" and > strange restrictions on types. (The builder must have *some* record type, > but any record type would do. There's nothing else like that anywhere.) So > by choosing the record-based approach, we're cutting off access to the > right design in the limit. Of course, #283/#295 are large proposals, still > technically under discussion (but very quiet), and either one has a sizable > implementation burden. I would never want to accept this current proposal > in a way that would depend on #283/#295. But, as argued above, the > module-based approach does not depend on these large proposals. > > My thoughts on the finer points: > > - I think the selectors should be in scope. It's simpler and less > ambiguous this way, given the fact that one module can alias several > modules to, say, M. I don't feel strongly on this point, though, and I see > the arguments in the other direction. > - I think this extension would be considerably more ergonomic if the new > operators were not named (>>=), etc., but instead something like > qualifiedBind, qualifiedThen, etc. This means that defining modules needn't > be delicate around importing the Prelude, and importing modules don't need > to worry about record selectors causing name clashes, etc., if they are not > using this new extension. > > As we decide on this proposal, I would also like us to think about how > this scales to other applications of rebindable syntax. For example, maybe > we want M.if or M.[ x, y, z ] someday. I think the design *does* scale in > such a way, which perhaps paves the way to deprecating -XRebindableSyntax. > > Richard > > On Apr 9, 2020, at 6:16 PM, Joachim Breitner > wrote: > > Dear Committe, > > Proposal: > > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst > 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-600746723 > 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-598859245 > > 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 at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bravit111 at gmail.com Sun Apr 12 06:01:36 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Sun, 12 Apr 2020 09:01:36 +0300 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <91B323B3-B104-45CD-ADED-22C8DE4E95C3@richarde.dev> Message-ID: HI, I prefer the module-based approach too. I agree that names such as (>>=) should not be explicitly imported if they are not used in the code explicitly. I also support the following Richard's idea: > - I think this extension would be considerably more ergonomic if the new operators were not named (>>=), etc., but instead something like qualifiedBind, qualifiedThen, etc. This means that defining modules needn't be delicate around importing the Prelude, and importing modules don't need to worry about record selectors causing name clashes, etc., if they are not using this new extension. This makes it easier to define such modules and use them if the new extension is not enabled. Vitaly пт, 10 апр. 2020 г. в 18:28, Iavor Diatchki : > Hello, > > My thoughts on this are on the git-hub thread, as I've been involved in > the discussion for quite a while. > > I am in alignment with Joachim, that we should accept the module-based > variant of the proposal. > > I don't have strong feelings on if the implicit names used by the > transformation should be in scope or just accessible via an import. > However, I think he makes a convincing argument that it would be pretty > weird to require names to be in scope that are not visible anywhere in the > source code, so following the choice we already made for ordinary `do` does > make sense to me. > > -Iavor > PS: Arnaud, not that it matters very much, but RankNTypes are not part of > Haskell 2010. > > > > > > On Fri, Apr 10, 2020 at 6:51 AM Richard Eisenberg > wrote: > >> Despite being the one to articulate "fully settled" and how to make >> builders with it, I now favor the module-based approach. Thanks, Joachim, >> for writing out pros and cons. I agree with the pros and con you listed >> with the module-based approach. Let's also look at some pros of the >> record-based approach: >> >> ➕ A single entity one can import, reexport, even rebind >> ➕ A single entity that can carry the documentation >> ➕ One module can export multiple builders >> >> >> With either of two module-system-improvement proposals ( >> https://github.com/ghc-proposals/ghc-proposals/pull/283 or >> https://github.com/ghc-proposals/ghc-proposals/pull/295), these pros >> carry over to the module-based approach. >> >> The reason I switched camps, from favoring record-based to favoring >> module-based, is this argument, by John Ericson: >> https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-606109628 >> Here, John is reacting to my complaint that the module-based solution will, >> to be ergonomic, require either #283 or #295. But John points out that we >> don't need to wait for #283 or #295: we can implement the module-based >> system right away. It will be usable (but sometimes clunky) right away. It >> will satisfy the problems in the motivation right away. All #283/#295 would >> do is make it less clunky. >> >> Put another way: let's imagine a Haskell with either of #283 or #295 >> implemented. Then, I think, the module-based approach would be a very clear >> win, over a record-based approach with its one-off "fully settled" and >> strange restrictions on types. (The builder must have *some* record type, >> but any record type would do. There's nothing else like that anywhere.) So >> by choosing the record-based approach, we're cutting off access to the >> right design in the limit. Of course, #283/#295 are large proposals, still >> technically under discussion (but very quiet), and either one has a sizable >> implementation burden. I would never want to accept this current proposal >> in a way that would depend on #283/#295. But, as argued above, the >> module-based approach does not depend on these large proposals. >> >> My thoughts on the finer points: >> >> - I think the selectors should be in scope. It's simpler and less >> ambiguous this way, given the fact that one module can alias several >> modules to, say, M. I don't feel strongly on this point, though, and I see >> the arguments in the other direction. >> - I think this extension would be considerably more ergonomic if the new >> operators were not named (>>=), etc., but instead something like >> qualifiedBind, qualifiedThen, etc. This means that defining modules needn't >> be delicate around importing the Prelude, and importing modules don't need >> to worry about record selectors causing name clashes, etc., if they are not >> using this new extension. >> >> As we decide on this proposal, I would also like us to think about how >> this scales to other applications of rebindable syntax. For example, maybe >> we want M.if or M.[ x, y, z ] someday. I think the design *does* scale in >> such a way, which perhaps paves the way to deprecating -XRebindableSyntax. >> >> Richard >> >> On Apr 9, 2020, at 6:16 PM, Joachim Breitner >> wrote: >> >> Dear Committe, >> >> Proposal: >> >> https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst >> 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-600746723 >> 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-598859245 >> >> 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 at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Sun Apr 12 19:31:28 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Sun, 12 Apr 2020 21:31:28 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <91B323B3-B104-45CD-ADED-22C8DE4E95C3@richarde.dev> Message-ID: Hi, I also lean towards the module-based approach. Regards, Alejandro El dom., 12 abr. 2020 a las 8:02, Vitaly Bragilevsky () escribió: > HI, > > I prefer the module-based approach too. I agree that names such as (>>=) > should not be explicitly imported if they are not used in the code > explicitly. > > I also support the following Richard's idea: > > > - I think this extension would be considerably more ergonomic if the new > operators were not named (>>=), etc., but instead something like > qualifiedBind, qualifiedThen, etc. This means that defining modules needn't > be delicate around importing the Prelude, and importing modules don't need > to worry about record selectors causing name clashes, etc., if they are not > using this new extension. > > This makes it easier to define such modules and use them if the new > extension is not enabled. > > Vitaly > > > пт, 10 апр. 2020 г. в 18:28, Iavor Diatchki : > >> Hello, >> >> My thoughts on this are on the git-hub thread, as I've been involved in >> the discussion for quite a while. >> >> I am in alignment with Joachim, that we should accept the module-based >> variant of the proposal. >> >> I don't have strong feelings on if the implicit names used by the >> transformation should be in scope or just accessible via an import. >> However, I think he makes a convincing argument that it would be pretty >> weird to require names to be in scope that are not visible anywhere in the >> source code, so following the choice we already made for ordinary `do` does >> make sense to me. >> >> -Iavor >> PS: Arnaud, not that it matters very much, but RankNTypes are not part >> of Haskell 2010. >> >> >> >> >> >> On Fri, Apr 10, 2020 at 6:51 AM Richard Eisenberg >> wrote: >> >>> Despite being the one to articulate "fully settled" and how to make >>> builders with it, I now favor the module-based approach. Thanks, Joachim, >>> for writing out pros and cons. I agree with the pros and con you listed >>> with the module-based approach. Let's also look at some pros of the >>> record-based approach: >>> >>> ➕ A single entity one can import, reexport, even rebind >>> ➕ A single entity that can carry the documentation >>> ➕ One module can export multiple builders >>> >>> >>> With either of two module-system-improvement proposals ( >>> https://github.com/ghc-proposals/ghc-proposals/pull/283 or >>> https://github.com/ghc-proposals/ghc-proposals/pull/295), these pros >>> carry over to the module-based approach. >>> >>> The reason I switched camps, from favoring record-based to favoring >>> module-based, is this argument, by John Ericson: >>> https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-606109628 >>> Here, John is reacting to my complaint that the module-based solution will, >>> to be ergonomic, require either #283 or #295. But John points out that we >>> don't need to wait for #283 or #295: we can implement the module-based >>> system right away. It will be usable (but sometimes clunky) right away. It >>> will satisfy the problems in the motivation right away. All #283/#295 would >>> do is make it less clunky. >>> >>> Put another way: let's imagine a Haskell with either of #283 or #295 >>> implemented. Then, I think, the module-based approach would be a very clear >>> win, over a record-based approach with its one-off "fully settled" and >>> strange restrictions on types. (The builder must have *some* record type, >>> but any record type would do. There's nothing else like that anywhere.) So >>> by choosing the record-based approach, we're cutting off access to the >>> right design in the limit. Of course, #283/#295 are large proposals, still >>> technically under discussion (but very quiet), and either one has a sizable >>> implementation burden. I would never want to accept this current proposal >>> in a way that would depend on #283/#295. But, as argued above, the >>> module-based approach does not depend on these large proposals. >>> >>> My thoughts on the finer points: >>> >>> - I think the selectors should be in scope. It's simpler and less >>> ambiguous this way, given the fact that one module can alias several >>> modules to, say, M. I don't feel strongly on this point, though, and I see >>> the arguments in the other direction. >>> - I think this extension would be considerably more ergonomic if the new >>> operators were not named (>>=), etc., but instead something like >>> qualifiedBind, qualifiedThen, etc. This means that defining modules needn't >>> be delicate around importing the Prelude, and importing modules don't need >>> to worry about record selectors causing name clashes, etc., if they are not >>> using this new extension. >>> >>> As we decide on this proposal, I would also like us to think about how >>> this scales to other applications of rebindable syntax. For example, maybe >>> we want M.if or M.[ x, y, z ] someday. I think the design *does* scale in >>> such a way, which perhaps paves the way to deprecating -XRebindableSyntax. >>> >>> Richard >>> >>> On Apr 9, 2020, at 6:16 PM, Joachim Breitner >>> wrote: >>> >>> Dear Committe, >>> >>> Proposal: >>> >>> https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst >>> 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-600746723 >>> 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-598859245 >>> >>> 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 at joachim-breitner.de >>> http://www.joachim-breitner.de/ >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Apr 13 11:40:38 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 13 Apr 2020 12:40:38 +0100 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: This seems like it could be thought of as a special case of record selection. (apologies if this has been discussed before, I haven't read the whole discussion thread.) The syntax is even reminiscent of record selection. But unlike selecting a single field, we're selecting a bunch of fields and using them to desugar a do expression.This makes me wonder: would it be possible to handle the typing by generating HasField constraints for (>>=) and friends? And would that avoid needing to talk about "fully settled" types? Cheers Simon On Thu, 9 Apr 2020 at 18:17, Joachim Breitner wrote: > Dear Committe, > > Proposal: > > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst > 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-600746723 > 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-598859245 > > 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 at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Apr 13 13:33:40 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 13 Apr 2020 14:33:40 +0100 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: > On Apr 13, 2020, at 12:40 PM, Simon Marlow wrote: > > This seems like it could be thought of as a special case of record selection. (apologies if this has been discussed before, I haven't read the whole discussion thread.) > > The syntax is even reminiscent of record selection. But unlike selecting a single field, we're selecting a bunch of fields and using them to desugar a do expression.This makes me wonder: would it be possible to handle the typing by generating HasField constraints for (>>=) and friends? And would that avoid needing to talk about "fully settled" types? Tempting, but no: the HasField mechanism fails for polymorphic record fields, which we desperately need here. :( Richard > > Cheers > Simon > > > On Thu, 9 Apr 2020 at 18:17, Joachim Breitner > wrote: > Dear Committe, > > Proposal: > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst > 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-600746723 > 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-598859245 > > 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 at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Apr 13 19:54:43 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 13 Apr 2020 21:54:43 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: Hi, Am Montag, den 13.04.2020, 12:40 +0100 schrieb Simon Marlow: > This makes me wonder: would it be possible to handle the typing by > generating HasField constraints for (>>=) and friends? And would that > avoid needing to talk about "fully settled" types? this was actually the original proposal by Arnaud from last spring, and if HasField would play well with polymorphic record fields, then we would have just happily accepted it back then… But because of the issues around polymorphic fields, we sent it back, and have now two “work-arounds” (introduce fully settled types, or use the module system) to choose from. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Tue Apr 14 06:58:40 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 14 Apr 2020 08:58:40 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> Message-ID: On Fri, Apr 10, 2020 at 10:43 AM Joachim Breitner wrote: > I am surprised this is so controversial. There are many things in > Haskell that are used that are not imported: > > * The desugaring of plain do notation (!) > * The desugaring of if-then-else (no need to have True/False in scope) > * The desugaring of boolean guards > (again, no need to have True/False in scope) > * Instances > * And because of that, `foo.bar` according to RecordDotSyntax will > not require `bar` to be in scope, as this is just an > instance accessed via HasField "bar" (if I am not mistaken) > > In contrast, there is nothing where you have to import some `foo` when > you don't actually mention `foo` in your source code. > > Which seems a pretty reasonable rule: > Import the things you write; no more, no less! > I wanted to add, for the record, that Joachim's argument convinced me that, indeed, were we to go for the module-qualified do approach, we probably shouldn't require the names to be in scope. However, it makes the module-qualified approach more counter-intuitive to me: it doesn't make sense to me to use the namespace `M` to refer to a term which is not in this namespace. Obviously, Joachim, you have a different intuition about this. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Tue Apr 14 08:47:27 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 14 Apr 2020 09:47:27 +0100 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> Message-ID: <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> About whether names must be in scope (only): What do module prefixes in code mean? I claim: they refer to a set of in-scope identifiers. That's it. Because of the way Haskell allows module aliasing, they do not refer to, say, a compilation unit, or some `module` structure. A module prefix identifies just a flat set of identifiers. This "set" view works nicely both with module aliasing and the way that Haskell specifies what "module M" means in an export list. Since a module prefix refers to a set of in-scope identifiers, it seems to make sense only to have the same meaning with M.do syntax. With the "identifiers do not need to be in scope" approach, then the M in M.do is now referring, I think, to a set of `module` structures that have been aliased to M in the import list. We then have to look in the export lists of each of those modules to see what is available. And what if multiple modules in the same set have bind operators in their export lists? That would be ambiguous, I suppose. Now, what if multiple modules in the module set export disjoint subsets of the operators? (For example, we have `import M1 as M` and `import M2 as M`, where `M1` exports `(>>)` and `M2` exports `(>>=)`.) I suppose we'd combine them. My problem is that we would have to specify all of these rules with the "out of scope" interpretation. With the in-scope interpretation, all of these answers follow directly from the specification. Much simpler! All that said, it seems the majority favor the out-of-scope interpretation. I truly don't feel strongly and am happy to go with that. I just wanted to expand my argument slightly to see if it won any of you over. Richard > On Apr 14, 2020, at 7:58 AM, Spiwack, Arnaud wrote: > > > > On Fri, Apr 10, 2020 at 10:43 AM Joachim Breitner > wrote: > I am surprised this is so controversial. There are many things in > Haskell that are used that are not imported: > > * The desugaring of plain do notation (!) > * The desugaring of if-then-else (no need to have True/False in scope) > * The desugaring of boolean guards > (again, no need to have True/False in scope) > * Instances > * And because of that, `foo.bar` according to RecordDotSyntax will > not require `bar` to be in scope, as this is just an > instance accessed via HasField "bar" (if I am not mistaken) > > In contrast, there is nothing where you have to import some `foo` when > you don't actually mention `foo` in your source code. > > Which seems a pretty reasonable rule: > Import the things you write; no more, no less! > > I wanted to add, for the record, that Joachim's argument convinced me that, indeed, were we to go for the module-qualified do approach, we probably shouldn't require the names to be in scope. > > However, it makes the module-qualified approach more counter-intuitive to me: it doesn't make sense to me to use the namespace `M` to refer to a term which is not in this namespace. Obviously, Joachim, you have a different intuition about this. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Apr 14 11:36:06 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 14 Apr 2020 11:36:06 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> Message-ID: In GHC we have two concepts: * Qualified names like M.foo, which always mean "the foo imported from module M - albeit with import-qualified you can change the local name" * Original names, also typically written M.foo, meaning "the foo defined in module M" In list comprehensions, conditionals etc, we always desugar to original names; it doesn't matter if they are in scope. You don't even have to import the Prelude. But GHC knows the defining module. With this "does not have to be in scope" business, you are inventing (and requiring someone to implement) a new scheme: * Quasi-original names: M.foo means "the foo exported by module M" I'm not at all keen this new mechanism * Presumably there is no opportunity to do the import-qualified thing? Or maybe you can say "import This.That as M ()", thus importing nothing but giving a local name M? * Presumably you must any other M.foo that is already in scope? But I can see why you want this, because you don't want to list all those operations one by one. Exactly! You want to group them into a ... record! You want import Linear( linear ), and then you can say linear.do { ... }. I'm pretty strongly against inventing quasi-original names. The module system is surprising complex already. I suppose you can always define an auxiliary module to do the grouping, thus import Linear.Monad as L -- Exports the operators for linear-do Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 14 April 2020 09:47 To: Spiwack, Arnaud Cc: Simon Peyton Jones via ghc-steering-committee ; Joachim Breitner Subject: Re: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative About whether names must be in scope (only): What do module prefixes in code mean? I claim: they refer to a set of in-scope identifiers. That's it. Because of the way Haskell allows module aliasing, they do not refer to, say, a compilation unit, or some `module` structure. A module prefix identifies just a flat set of identifiers. This "set" view works nicely both with module aliasing and the way that Haskell specifies what "module M" means in an export list. Since a module prefix refers to a set of in-scope identifiers, it seems to make sense only to have the same meaning with M.do syntax. With the "identifiers do not need to be in scope" approach, then the M in M.do is now referring, I think, to a set of `module` structures that have been aliased to M in the import list. We then have to look in the export lists of each of those modules to see what is available. And what if multiple modules in the same set have bind operators in their export lists? That would be ambiguous, I suppose. Now, what if multiple modules in the module set export disjoint subsets of the operators? (For example, we have `import M1 as M` and `import M2 as M`, where `M1` exports `(>>)` and `M2` exports `(>>=)`.) I suppose we'd combine them. My problem is that we would have to specify all of these rules with the "out of scope" interpretation. With the in-scope interpretation, all of these answers follow directly from the specification. Much simpler! All that said, it seems the majority favor the out-of-scope interpretation. I truly don't feel strongly and am happy to go with that. I just wanted to expand my argument slightly to see if it won any of you over. Richard On Apr 14, 2020, at 7:58 AM, Spiwack, Arnaud > wrote: On Fri, Apr 10, 2020 at 10:43 AM Joachim Breitner > wrote: I am surprised this is so controversial. There are many things in Haskell that are used that are not imported: * The desugaring of plain do notation (!) * The desugaring of if-then-else (no need to have True/False in scope) * The desugaring of boolean guards (again, no need to have True/False in scope) * Instances * And because of that, `foo.bar` according to RecordDotSyntax will not require `bar` to be in scope, as this is just an instance accessed via HasField "bar" (if I am not mistaken) In contrast, there is nothing where you have to import some `foo` when you don't actually mention `foo` in your source code. Which seems a pretty reasonable rule: Import the things you write; no more, no less! I wanted to add, for the record, that Joachim's argument convinced me that, indeed, were we to go for the module-qualified do approach, we probably shouldn't require the names to be in scope. However, it makes the module-qualified approach more counter-intuitive to me: it doesn't make sense to me to use the namespace `M` to refer to a term which is not in this namespace. Obviously, Joachim, you have a different intuition about this. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomjharding at live.co.uk Tue Apr 14 13:39:52 2020 From: tomjharding at live.co.uk (Tom Harding) Date: Tue, 14 Apr 2020 13:39:52 +0000 Subject: [ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default Message-ID: <5BB8D4CF-9837-478F-A0BA-B5C0BC368F11@live.co.uk> 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 From eric at seidel.io Tue Apr 14 15:00:03 2020 From: eric at seidel.io (Eric Seidel) Date: Tue, 14 Apr 2020 10:00:03 -0500 Subject: [ghc-steering-committee] =?utf-8?q?=23216=3A_Qualified_Do_again?= =?utf-8?q?=2C_recommendation=3A_accept_the_alternative?= In-Reply-To: <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> Message-ID: If we allow "M.do" without explicitly importing M, building the module dependency graph suddenly requires parsing the entire module rather than just the preamble. How much of a concern is this for compilation times? Apart from that possible concern, I support both of Joachim's recommendations. On Tue, Apr 14, 2020, at 03:47, Richard Eisenberg wrote: > About whether names must be in scope (only): > > What do module prefixes in code mean? I claim: they refer to a set of > in-scope identifiers. That's it. Because of the way Haskell allows > module aliasing, they do not refer to, say, a compilation unit, or some > `module` structure. A module prefix identifies just a flat set of > identifiers. This "set" view works nicely both with module aliasing and > the way that Haskell specifies what "module M" means in an export list. > > Since a module prefix refers to a set of in-scope identifiers, it seems > to make sense only to have the same meaning with M.do syntax. With the > "identifiers do not need to be in scope" approach, then the M in M.do > is now referring, I think, to a set of `module` structures that have > been aliased to M in the import list. We then have to look in the > export lists of each of those modules to see what is available. And > what if multiple modules in the same set have bind operators in their > export lists? That would be ambiguous, I suppose. Now, what if multiple > modules in the module set export disjoint subsets of the operators? > (For example, we have `import M1 as M` and `import M2 as M`, where `M1` > exports `(>>)` and `M2` exports `(>>=)`.) I suppose we'd combine them. > My problem is that we would have to specify all of these rules with the > "out of scope" interpretation. With the in-scope interpretation, all of > these answers follow directly from the specification. Much simpler! > > All that said, it seems the majority favor the out-of-scope > interpretation. I truly don't feel strongly and am happy to go with > that. I just wanted to expand my argument slightly to see if it won any > of you over. > > Richard > > > On Apr 14, 2020, at 7:58 AM, Spiwack, Arnaud wrote: > > > > > > > > On Fri, Apr 10, 2020 at 10:43 AM Joachim Breitner wrote: > >> I am surprised this is so controversial. There are many things in > >> Haskell that are used that are not imported: > >> > >> * The desugaring of plain do notation (!) > >> * The desugaring of if-then-else (no need to have True/False in scope) > >> * The desugaring of boolean guards > >> (again, no need to have True/False in scope) > >> * Instances > >> * And because of that, `foo.bar` according to RecordDotSyntax will > >> not require `bar` to be in scope, as this is just an > >> instance accessed via HasField "bar" (if I am not mistaken) > >> > >> In contrast, there is nothing where you have to import some `foo` when > >> you don't actually mention `foo` in your source code. > >> > >> Which seems a pretty reasonable rule: > >> Import the things you write; no more, no less! > > > > I wanted to add, for the record, that Joachim's argument convinced me that, indeed, were we to go for the module-qualified do approach, we probably shouldn't require the names to be in scope. > > > > However, it makes the module-qualified approach more counter-intuitive to me: it doesn't make sense to me to use the namespace `M` to refer to a term which is not in this namespace. Obviously, Joachim, you have a different intuition about this. > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From mail at joachim-breitner.de Tue Apr 14 15:19:46 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 14 Apr 2020 17:19:46 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> Message-ID: HI, Am Dienstag, den 14.04.2020, 10:00 -0500 schrieb Eric Seidel: > If we allow "M.do" without explicitly importing M, building the > module dependency graph suddenly requires parsing the entire module > rather than just the preamble. How much of a concern is this for > compilation times? that isn’t the plan. You still have to import a module called M! The question is whether you _also_ have to import M.(>>), or whether it’s import to import a _module_ and give it a name. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Tue Apr 14 15:27:51 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 14 Apr 2020 17:27:51 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> Message-ID: <0f4e4ed6cf54d3bebac8f0c0f552e4a9aaffe89d.camel@joachim-breitner.de> Hi, Am Dienstag, den 14.04.2020, 11:36 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > Qualified names like M.foo, which always mean “the foo imported from > module M – albeit with import-qualified you can change the local > name” but it’s not that simple: What if I write import qualified M1 as M import qualified M2 as M and then use M.foo? Well, it resolves the foo imported from M1, if M1 exports it. Or from M2, if M2 exports it. But what if both export it? Then we get an “ambiguity error”… Unless M1.foo and M2.foo, via re-exports, point to the same original name. What is proposed for M.(>>) here is the same logic, with the addition that it doesn’t matter whether you used “hiding ((>>))” somewhere in these imports, or imported (), to keep the nice existing rule “You only import what you explicitly mention” In terms of implementation I don’t think the burden is high; GHC already has that logic for the “M.foo is not in scope, did you want to add foo to the export list in line x” error message. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Tue Apr 14 15:36:53 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 14 Apr 2020 17:36:53 +0200 Subject: [ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default In-Reply-To: <5BB8D4CF-9837-478F-A0BA-B5C0BC368F11@live.co.uk> References: <5BB8D4CF-9837-478F-A0BA-B5C0BC368F11@live.co.uk> Message-ID: I am absolutely not opposed to this proposal. In current code, it's probably not a good idea to define `return` or `mappend` anyway. So I should certainly not be counted as blocking acceptance. I just would have liked a bit of clarity about the context, which I feel I'm very much missing. /Arnaud On Tue, Apr 14, 2020 at 3:40 PM Tom Harding wrote: > 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 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Tue Apr 14 16:09:58 2020 From: eric at seidel.io (Eric Seidel) Date: Tue, 14 Apr 2020 11:09:58 -0500 Subject: [ghc-steering-committee] =?utf-8?q?=23216=3A_Qualified_Do_again?= =?utf-8?q?=2C_recommendation=3A_accept_the_alternative?= In-Reply-To: References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> Message-ID: <4aba8541-1c52-47f5-b715-f669168ee2ec@www.fastmail.com> I see, I misunderstood the point of contention. I still support your recommendations, but it seems like a rather minor issue. My guess is that (in particular if we keep the standard names for the operations) most people will opt to use qualified imports, which means the identifiers will all be in scope anyway. On Tue, Apr 14, 2020, at 10:19, Joachim Breitner wrote: > HI, > > Am Dienstag, den 14.04.2020, 10:00 -0500 schrieb Eric Seidel: > > If we allow "M.do" without explicitly importing M, building the > > module dependency graph suddenly requires parsing the entire module > > rather than just the preamble. How much of a concern is this for > > compilation times? > > that isn’t the plan. You still have to import a module called M! The > question is whether you _also_ have to import M.(>>), or whether it’s > import to import a _module_ and give it a name. > > Cheers, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From iavor.diatchki at gmail.com Tue Apr 14 16:15:26 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 14 Apr 2020 09:15:26 -0700 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <0f4e4ed6cf54d3bebac8f0c0f552e4a9aaffe89d.camel@joachim-breitner.de> References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> <0f4e4ed6cf54d3bebac8f0c0f552e4a9aaffe89d.camel@joachim-breitner.de> Message-ID: Hello, as the Github discussion is pretty long, I thought it might be useful to have a summary of the observations to the issue being discussed, namely how to resolve the names in `M.do`. Without the special syntax suggested by Joachim, a programmer has the following options to make `M.do` work, and I've marked some (potential) pros/cons: 1. import MyMonad as M (+) other operations do not need to be qualified (-) unqualified `>>=` may be ambiguous 2. import qualified MyMonad as M (-) other operations need to be qualified (+) unqualified `>>=` is not ambiguous 3. import qualified MyMonas as M import MyMonad (other,operations) (+) other operations do not need to be qualified (+) unqualifed `>>=` is not ambiguous (-) requires two imports Joachim's proposal aims to improve on (3) by allowing programmers to write: 4. import MyMonad as M (other,operations) (+) other operations do not need to be qualified (+) unqualified `>>=` are not ambiguous The idea is that the renamer would compute the original name to use in the desugaring by seeing if `>>=` is exported by one of the modules imported with alias `M`. GHC certainly has the required information, and I doubt this would be hard to implement. As I said in my previous e-mail, I don't have a strong feeling about the choice we make, but I wanted to make sure that we are all discussing the same thing. -Iavor On Tue, Apr 14, 2020 at 8:28 AM Joachim Breitner wrote: > Hi, > > Am Dienstag, den 14.04.2020, 11:36 +0000 schrieb Simon Peyton Jones via > ghc-steering-committee: > > Qualified names like M.foo, which always mean “the foo imported from > > module M – albeit with import-qualified you can change the local > > name” > > but it’s not that simple: What if I write > > import qualified M1 as M > import qualified M2 as M > > and then use M.foo? > Well, it resolves the foo imported from M1, if M1 exports it. > Or from M2, if M2 exports it. > But what if both export it? Then we get an “ambiguity error”… > Unless M1.foo and M2.foo, via re-exports, point to the same original > name. > > What is proposed for M.(>>) here is the same logic, with the addition > that it doesn’t matter whether you used “hiding ((>>))” somewhere in > these imports, or imported (), to keep the nice existing rule > “You only import what you explicitly mention” > > In terms of implementation I don’t think the burden is high; GHC > already has that logic for the “M.foo is not in scope, did you want to > add foo to the export list in line x” error message. > > Cheers, > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Thu Apr 16 12:12:32 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 16 Apr 2020 13:12:32 +0100 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> Message-ID: On Tue, 14 Apr 2020 at 16:00, Eric Seidel wrote: > If we allow "M.do" without explicitly importing M, building the module > dependency graph suddenly requires parsing the entire module rather than > just the preamble. How much of a concern is this for compilation times? > That would be a big deal for GHC, which currently relies on being able to parse just the header to determine the module dependency graph. Cheers Simon > Apart from that possible concern, I support both of Joachim's > recommendations. > > On Tue, Apr 14, 2020, at 03:47, Richard Eisenberg wrote: > > About whether names must be in scope (only): > > > > What do module prefixes in code mean? I claim: they refer to a set of > > in-scope identifiers. That's it. Because of the way Haskell allows > > module aliasing, they do not refer to, say, a compilation unit, or some > > `module` structure. A module prefix identifies just a flat set of > > identifiers. This "set" view works nicely both with module aliasing and > > the way that Haskell specifies what "module M" means in an export list. > > > > Since a module prefix refers to a set of in-scope identifiers, it seems > > to make sense only to have the same meaning with M.do syntax. With the > > "identifiers do not need to be in scope" approach, then the M in M.do > > is now referring, I think, to a set of `module` structures that have > > been aliased to M in the import list. We then have to look in the > > export lists of each of those modules to see what is available. And > > what if multiple modules in the same set have bind operators in their > > export lists? That would be ambiguous, I suppose. Now, what if multiple > > modules in the module set export disjoint subsets of the operators? > > (For example, we have `import M1 as M` and `import M2 as M`, where `M1` > > exports `(>>)` and `M2` exports `(>>=)`.) I suppose we'd combine them. > > My problem is that we would have to specify all of these rules with the > > "out of scope" interpretation. With the in-scope interpretation, all of > > these answers follow directly from the specification. Much simpler! > > > > All that said, it seems the majority favor the out-of-scope > > interpretation. I truly don't feel strongly and am happy to go with > > that. I just wanted to expand my argument slightly to see if it won any > > of you over. > > > > Richard > > > > > On Apr 14, 2020, at 7:58 AM, Spiwack, Arnaud > wrote: > > > > > > > > > > > > On Fri, Apr 10, 2020 at 10:43 AM Joachim Breitner < > mail at joachim-breitner.de> wrote: > > >> I am surprised this is so controversial. There are many things in > > >> Haskell that are used that are not imported: > > >> > > >> * The desugaring of plain do notation (!) > > >> * The desugaring of if-then-else (no need to have True/False in > scope) > > >> * The desugaring of boolean guards > > >> (again, no need to have True/False in scope) > > >> * Instances > > >> * And because of that, `foo.bar` according to RecordDotSyntax will > > >> not require `bar` to be in scope, as this is just an > > >> instance accessed via HasField "bar" (if I am not mistaken) > > >> > > >> In contrast, there is nothing where you have to import some `foo` > when > > >> you don't actually mention `foo` in your source code. > > >> > > >> Which seems a pretty reasonable rule: > > >> Import the things you write; no more, no less! > > > > > > I wanted to add, for the record, that Joachim's argument convinced me > that, indeed, were we to go for the module-qualified do approach, we > probably shouldn't require the names to be in scope. > > > > > > However, it makes the module-qualified approach more counter-intuitive > to me: it doesn't make sense to me to use the namespace `M` to refer to a > term which is not in this namespace. Obviously, Joachim, you have a > different intuition about this. > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Apr 16 12:15:07 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 16 Apr 2020 14:15:07 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> Message-ID: <2637de505a679225d2ba5d8975016893f94b7621.camel@joachim-breitner.de> Hi, Am Donnerstag, den 16.04.2020, 13:12 +0100 schrieb Simon Marlow: > On Tue, 14 Apr 2020 at 16:00, Eric Seidel wrote: > > If we allow "M.do" without explicitly importing M, building the module dependency graph suddenly requires parsing the entire module rather than just the preamble. How much of a concern is this for compilation times? > > That would be a big deal for GHC, which currently relies on being able to parse just the header to determine the module dependency graph. But nobody is suggesting this, right? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From eric at seidel.io Thu Apr 16 12:27:31 2020 From: eric at seidel.io (Eric Seidel) Date: Thu, 16 Apr 2020 07:27:31 -0500 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: That’s what I thought, but thankfully Joachim has clarified that the module has to be explicitly imported, the only question is whether the identifiers have to be brought in scope as part of the import. Sent from my iPhone > On Apr 16, 2020, at 07:12, Simon Marlow wrote: > >  >> On Tue, 14 Apr 2020 at 16:00, Eric Seidel wrote: >> If we allow "M.do" without explicitly importing M, building the module dependency graph suddenly requires parsing the entire module rather than just the preamble. How much of a concern is this for compilation times? > > That would be a big deal for GHC, which currently relies on being able to parse just the header to determine the module dependency graph. > > Cheers > Simon > >> >> Apart from that possible concern, I support both of Joachim's recommendations. >> >> On Tue, Apr 14, 2020, at 03:47, Richard Eisenberg wrote: >> > About whether names must be in scope (only): >> > >> > What do module prefixes in code mean? I claim: they refer to a set of >> > in-scope identifiers. That's it. Because of the way Haskell allows >> > module aliasing, they do not refer to, say, a compilation unit, or some >> > `module` structure. A module prefix identifies just a flat set of >> > identifiers. This "set" view works nicely both with module aliasing and >> > the way that Haskell specifies what "module M" means in an export list. >> > >> > Since a module prefix refers to a set of in-scope identifiers, it seems >> > to make sense only to have the same meaning with M.do syntax. With the >> > "identifiers do not need to be in scope" approach, then the M in M.do >> > is now referring, I think, to a set of `module` structures that have >> > been aliased to M in the import list. We then have to look in the >> > export lists of each of those modules to see what is available. And >> > what if multiple modules in the same set have bind operators in their >> > export lists? That would be ambiguous, I suppose. Now, what if multiple >> > modules in the module set export disjoint subsets of the operators? >> > (For example, we have `import M1 as M` and `import M2 as M`, where `M1` >> > exports `(>>)` and `M2` exports `(>>=)`.) I suppose we'd combine them. >> > My problem is that we would have to specify all of these rules with the >> > "out of scope" interpretation. With the in-scope interpretation, all of >> > these answers follow directly from the specification. Much simpler! >> > >> > All that said, it seems the majority favor the out-of-scope >> > interpretation. I truly don't feel strongly and am happy to go with >> > that. I just wanted to expand my argument slightly to see if it won any >> > of you over. >> > >> > Richard >> > >> > > On Apr 14, 2020, at 7:58 AM, Spiwack, Arnaud wrote: >> > > >> > > >> > > >> > > On Fri, Apr 10, 2020 at 10:43 AM Joachim Breitner wrote: >> > >> I am surprised this is so controversial. There are many things in >> > >> Haskell that are used that are not imported: >> > >> >> > >> * The desugaring of plain do notation (!) >> > >> * The desugaring of if-then-else (no need to have True/False in scope) >> > >> * The desugaring of boolean guards >> > >> (again, no need to have True/False in scope) >> > >> * Instances >> > >> * And because of that, `foo.bar` according to RecordDotSyntax will >> > >> not require `bar` to be in scope, as this is just an >> > >> instance accessed via HasField "bar" (if I am not mistaken) >> > >> >> > >> In contrast, there is nothing where you have to import some `foo` when >> > >> you don't actually mention `foo` in your source code. >> > >> >> > >> Which seems a pretty reasonable rule: >> > >> Import the things you write; no more, no less! >> > > >> > > I wanted to add, for the record, that Joachim's argument convinced me that, indeed, were we to go for the module-qualified do approach, we probably shouldn't require the names to be in scope. >> > > >> > > However, it makes the module-qualified approach more counter-intuitive to me: it doesn't make sense to me to use the namespace `M` to refer to a term which is not in this namespace. Obviously, Joachim, you have a different intuition about this. >> > > _______________________________________________ >> > > ghc-steering-committee mailing list >> > > ghc-steering-committee at haskell.org >> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Thu Apr 16 14:32:37 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 16 Apr 2020 15:32:37 +0100 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: On Thu, 16 Apr 2020 at 13:27, Eric Seidel wrote: > That’s what I thought, but thankfully Joachim has clarified that the > module has to be explicitly imported, the only question is whether the > identifiers have to be brought in scope as part of the import. > Sorry I should have read the rest of the thread before responding. Thanks! Simon > Sent from my iPhone > > On Apr 16, 2020, at 07:12, Simon Marlow wrote: > >  > On Tue, 14 Apr 2020 at 16:00, Eric Seidel wrote: > >> If we allow "M.do" without explicitly importing M, building the module >> dependency graph suddenly requires parsing the entire module rather than >> just the preamble. How much of a concern is this for compilation times? >> > > That would be a big deal for GHC, which currently relies on being able to > parse just the header to determine the module dependency graph. > > Cheers > Simon > > >> Apart from that possible concern, I support both of Joachim's >> recommendations. >> >> On Tue, Apr 14, 2020, at 03:47, Richard Eisenberg wrote: >> > About whether names must be in scope (only): >> > >> > What do module prefixes in code mean? I claim: they refer to a set of >> > in-scope identifiers. That's it. Because of the way Haskell allows >> > module aliasing, they do not refer to, say, a compilation unit, or some >> > `module` structure. A module prefix identifies just a flat set of >> > identifiers. This "set" view works nicely both with module aliasing and >> > the way that Haskell specifies what "module M" means in an export list. >> > >> > Since a module prefix refers to a set of in-scope identifiers, it seems >> > to make sense only to have the same meaning with M.do syntax. With the >> > "identifiers do not need to be in scope" approach, then the M in M.do >> > is now referring, I think, to a set of `module` structures that have >> > been aliased to M in the import list. We then have to look in the >> > export lists of each of those modules to see what is available. And >> > what if multiple modules in the same set have bind operators in their >> > export lists? That would be ambiguous, I suppose. Now, what if multiple >> > modules in the module set export disjoint subsets of the operators? >> > (For example, we have `import M1 as M` and `import M2 as M`, where `M1` >> > exports `(>>)` and `M2` exports `(>>=)`.) I suppose we'd combine them. >> > My problem is that we would have to specify all of these rules with the >> > "out of scope" interpretation. With the in-scope interpretation, all of >> > these answers follow directly from the specification. Much simpler! >> > >> > All that said, it seems the majority favor the out-of-scope >> > interpretation. I truly don't feel strongly and am happy to go with >> > that. I just wanted to expand my argument slightly to see if it won any >> > of you over. >> > >> > Richard >> > >> > > On Apr 14, 2020, at 7:58 AM, Spiwack, Arnaud >> wrote: >> > > >> > > >> > > >> > > On Fri, Apr 10, 2020 at 10:43 AM Joachim Breitner < >> mail at joachim-breitner.de> wrote: >> > >> I am surprised this is so controversial. There are many things in >> > >> Haskell that are used that are not imported: >> > >> >> > >> * The desugaring of plain do notation (!) >> > >> * The desugaring of if-then-else (no need to have True/False in >> scope) >> > >> * The desugaring of boolean guards >> > >> (again, no need to have True/False in scope) >> > >> * Instances >> > >> * And because of that, `foo.bar` according to RecordDotSyntax will >> > >> not require `bar` to be in scope, as this is just an >> > >> instance accessed via HasField "bar" (if I am not mistaken) >> > >> >> > >> In contrast, there is nothing where you have to import some `foo` >> when >> > >> you don't actually mention `foo` in your source code. >> > >> >> > >> Which seems a pretty reasonable rule: >> > >> Import the things you write; no more, no less! >> > > >> > > I wanted to add, for the record, that Joachim's argument convinced me >> that, indeed, were we to go for the module-qualified do approach, we >> probably shouldn't require the names to be in scope. >> > > >> > > However, it makes the module-qualified approach more >> counter-intuitive to me: it doesn't make sense to me to use the namespace >> `M` to refer to a term which is not in this namespace. Obviously, Joachim, >> you have a different intuition about this. >> > > _______________________________________________ >> > > ghc-steering-committee mailing list >> > > ghc-steering-committee at haskell.org >> > > >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Apr 16 14:48:53 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 16 Apr 2020 14:48:53 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> <0f4e4ed6cf54d3bebac8f0c0f552e4a9aaffe89d.camel@joachim-breitner.de> Message-ID: I’m sorry I’m slow, but I just don’t yet understand what is being proposed. Joachim launched the discussion here. I believe that he is advocating section 6.1 in the proposal. Moreover he has some variant of it in mind. I asked some questions about the variant that may or may not have been answered. It would be really helpful to have a single source of truth. Perhaps someone (Joachim or anyone else) can write a Google doc that describes, as precisely as possible, the proposal that he is advocating. Or get the proposal authors to do so. Just saying “a variant where the value does not need to be in scope” does not count as a specification (to me). Iavor’s writeup below is helpful, but I fall over immediately. First, I believe that his (1-4) things are not *design* alternatives; they are all things the programmer can write, all under Section 6.1 of the proposal (unmodified). Is that right. Then. 1. import MyMonad as M (+) other operations do not need to be qualified (-) unqualified `>>=` may be ambiguous What are “other operations”? Why might “>>=” be ambiguous? I think the answer is: because MyMonad must export it (to use in M.do), but it may already be in scope from the Prelude. I’m strongly inclined against inventing new complexity in the module system, unless it is absolutely unavoidable. More to specify, more to explain, more to understand, more to implement. Simon From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 14 April 2020 17:15 To: Joachim Breitner Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative Hello, as the Github discussion is pretty long, I thought it might be useful to have a summary of the observations to the issue being discussed, namely how to resolve the names in `M.do`. Without the special syntax suggested by Joachim, a programmer has the following options to make `M.do` work, and I've marked some (potential) pros/cons: 1. import MyMonad as M (+) other operations do not need to be qualified (-) unqualified `>>=` may be ambiguous 2. import qualified MyMonad as M (-) other operations need to be qualified (+) unqualified `>>=` is not ambiguous 3. import qualified MyMonas as M import MyMonad (other,operations) (+) other operations do not need to be qualified (+) unqualifed `>>=` is not ambiguous (-) requires two imports Joachim's proposal aims to improve on (3) by allowing programmers to write: 4. import MyMonad as M (other,operations) (+) other operations do not need to be qualified (+) unqualified `>>=` are not ambiguous The idea is that the renamer would compute the original name to use in the desugaring by seeing if `>>=` is exported by one of the modules imported with alias `M`. GHC certainly has the required information, and I doubt this would be hard to implement. As I said in my previous e-mail, I don't have a strong feeling about the choice we make, but I wanted to make sure that we are all discussing the same thing. -Iavor On Tue, Apr 14, 2020 at 8:28 AM Joachim Breitner > wrote: Hi, Am Dienstag, den 14.04.2020, 11:36 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > Qualified names like M.foo, which always mean “the foo imported from > module M – albeit with import-qualified you can change the local > name” but it’s not that simple: What if I write import qualified M1 as M import qualified M2 as M and then use M.foo? Well, it resolves the foo imported from M1, if M1 exports it. Or from M2, if M2 exports it. But what if both export it? Then we get an “ambiguity error”… Unless M1.foo and M2.foo, via re-exports, point to the same original name. What is proposed for M.(>>) here is the same logic, with the addition that it doesn’t matter whether you used “hiding ((>>))” somewhere in these imports, or imported (), to keep the nice existing rule “You only import what you explicitly mention” In terms of implementation I don’t think the burden is high; GHC already has that logic for the “M.foo is not in scope, did you want to add foo to the export list in line x” error message. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Apr 16 14:56:33 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 16 Apr 2020 16:56:33 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> <0f4e4ed6cf54d3bebac8f0c0f552e4a9aaffe89d.camel@joachim-breitner.de> Message-ID: <4364885e6972b0161b52e4030a272d0f7a4c4276.camel@joachim-breitner.de> Hi, Am Donnerstag, den 16.04.2020, 14:48 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > It would be really helpful to have a single source of truth. Perhaps > someone (Joachim or anyone else) can write a Google doc that > describes, as precisely as possible, the proposal that he is > advocating. Or get the proposal authors to do so. Just saying “a > variant where the value does not need to be in scope” does not count > as a specification (to me). the variant is described in 6.1.2 of the proposal: https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst#612qualifieddo-with-operations-that-are-not-in-scope has a spec (“resolves to any (>>=) that is exported by any module aliased by the name M, independently of whether it is in scope (i.e. imported).” and an I think enlightening example (albeit with an odd duplication of imports). > Then. > 1. import MyMonad as M > (+) other operations do not need to be qualified > (-) unqualified `>>=` may be ambiguous > > What are “other operations”? Anything else exported from MyMonad that the user might want to use. > Why might “>>=” be ambiguous? I think the answer is: because MyMonad > must export it (to use in M.do), but it may already be in scope from > the Prelude. Correct. > I’m strongly inclined against inventing new complexity in the module > system, unless it is absolutely unavoidable. More to specify, more to > explain, more to understand, more to implement. And you are sure that the complexity of this is more than that of “fully settled” types? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Thu Apr 16 15:01:28 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 16 Apr 2020 15:01:28 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <4364885e6972b0161b52e4030a272d0f7a4c4276.camel@joachim-breitner.de> References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> <0f4e4ed6cf54d3bebac8f0c0f552e4a9aaffe89d.camel@joachim-breitner.de> <4364885e6972b0161b52e4030a272d0f7a4c4276.camel@joachim-breitner.de> Message-ID: | And you are sure that the complexity of this is more than that of | “fully settled” types? I didn't say that. But I am sure that it's more complicated than 6.1 without 6.1.2! If I understand aright, the *only* gain is that one can omit three words: import qualified MyMonad Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 16 April 2020 15:57 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] #216: Qualified Do again, | recommendation: accept the alternative | | Hi, | | Am Donnerstag, den 16.04.2020, 14:48 +0000 schrieb Simon Peyton Jones | via ghc-steering-committee: | > It would be really helpful to have a single source of truth. Perhaps | > someone (Joachim or anyone else) can write a Google doc that | > describes, as precisely as possible, the proposal that he is | > advocating. Or get the proposal authors to do so. Just saying “a | > variant where the value does not need to be in scope” does not count | > as a specification (to me). | | the variant is described in 6.1.2 of the proposal: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Ftweag%2Fghc-proposals%2Fblob%2Flocal-do%2Fproposals%2F0000-local- | do.rst%23612qualifieddo-with-operations-that-are-not-in- | scope&data=02%7C01%7Csimonpj%40microsoft.com%7Ccfc3548461cb4f9c537b08d | 7e21665ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637226458138396283& | amp;sdata=fiV%2B37%2BsCuijDL1dx7iyryEkiPWoRC1ZKGtxq4xf9K4%3D&reserved= | 0 | has a spec (“resolves to any (>>=) that is exported by any module | aliased by the name M, independently of whether it is in scope (i.e. | imported).” and an I think enlightening example (albeit with an odd | duplication of imports). | | > Then. | > 1. import MyMonad as M | > (+) other operations do not need to be qualified | > (-) unqualified `>>=` may be ambiguous | > | > What are “other operations”? | | Anything else exported from MyMonad that the user might want to use. | | > Why might “>>=” be ambiguous? I think the answer is: because MyMonad | > must export it (to use in M.do), but it may already be in scope from | > the Prelude. | | Correct. | | > I’m strongly inclined against inventing new complexity in the module | > system, unless it is absolutely unavoidable. More to specify, more to | > explain, more to understand, more to implement. | | And you are sure that the complexity of this is more than that of | “fully settled” types? | | Cheers, | Joachim | -- | Joachim Breitner | mail at joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccfc3548461cb4f | 9c537b08d7e21665ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372264581 | 38396283&sdata=%2FkfYvu9u3aPelYnSxYW3k%2BiDEVzNXi5vA2vkQKxUQ68%3D& | reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ccfc3548461cb4f9c537 | b08d7e21665ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637226458138396 | 283&sdata=3ylk%2Fh9DP0un9%2Fw%2FVKcrWnzlvmR8rflb8Ju17Zv5yu4%3D&res | erved=0 From simonpj at microsoft.com Thu Apr 16 15:02:28 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 16 Apr 2020 15:02:28 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <4364885e6972b0161b52e4030a272d0f7a4c4276.camel@joachim-breitner.de> References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> <0f4e4ed6cf54d3bebac8f0c0f552e4a9aaffe89d.camel@joachim-breitner.de> <4364885e6972b0161b52e4030a272d0f7a4c4276.camel@joachim-breitner.de> Message-ID: | the variant is described in 6.1.2 of the proposal: PS: Sorry for missing that. (It has not been mentioned in any of the discussion.) Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 16 April 2020 15:57 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] #216: Qualified Do again, | recommendation: accept the alternative | | Hi, | | Am Donnerstag, den 16.04.2020, 14:48 +0000 schrieb Simon Peyton Jones | via ghc-steering-committee: | > It would be really helpful to have a single source of truth. | Perhaps | > someone (Joachim or anyone else) can write a Google doc that | > describes, as precisely as possible, the proposal that he is | > advocating. Or get the proposal authors to do so. Just saying “a | > variant where the value does not need to be in scope” does not count | > as a specification (to me). | | the variant is described in 6.1.2 of the proposal: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Ftweag%2Fghc-proposals%2Fblob%2Flocal-do%2Fproposals%2F0000- | local-do.rst%23612qualifieddo-with-operations-that-are-not-in- | scope&data=02%7C01%7Csimonpj%40microsoft.com%7Ccfc3548461cb4f9c537 | b08d7e21665ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63722645813 | 8396283&sdata=fiV%2B37%2BsCuijDL1dx7iyryEkiPWoRC1ZKGtxq4xf9K4%3D&a | mp;reserved=0 | has a spec (“resolves to any (>>=) that is exported by any module | aliased by the name M, independently of whether it is in scope (i.e. | imported).” and an I think enlightening example (albeit with an odd | duplication of imports). | | > Then. | > 1. import MyMonad as M | > (+) other operations do not need to be qualified | > (-) unqualified `>>=` may be ambiguous | > | > What are “other operations”? | | Anything else exported from MyMonad that the user might want to use. | | > Why might “>>=” be ambiguous? I think the answer is: because | MyMonad | > must export it (to use in M.do), but it may already be in scope from | > the Prelude. | | Correct. | | > I’m strongly inclined against inventing new complexity in the module | > system, unless it is absolutely unavoidable. More to specify, more | to | > explain, more to understand, more to implement. | | And you are sure that the complexity of this is more than that of | “fully settled” types? | | Cheers, | Joachim | -- | Joachim Breitner | mail at joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccfc3548461 | cb4f9c537b08d7e21665ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7226458138396283&sdata=%2FkfYvu9u3aPelYnSxYW3k%2BiDEVzNXi5vA2vkQKx | UQ68%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ccfc3548461cb4f9 | c537b08d7e21665ba%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372264 | 58138396283&sdata=3ylk%2Fh9DP0un9%2Fw%2FVKcrWnzlvmR8rflb8Ju17Zv5yu | 4%3D&reserved=0 From mail at joachim-breitner.de Thu Apr 16 15:11:12 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 16 Apr 2020 17:11:12 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <66156e8e78d951cc38518ffe84924ea4cb07eaeb.camel@joachim-breitner.de> <608CE7F4-8A04-4866-81D9-0B1BA45CE215@richarde.dev> <0f4e4ed6cf54d3bebac8f0c0f552e4a9aaffe89d.camel@joachim-breitner.de> <4364885e6972b0161b52e4030a272d0f7a4c4276.camel@joachim-breitner.de> Message-ID: <1370b4dc7257f4727dd81ac790251c3afb02673d.camel@joachim-breitner.de> Hi, Am Donnerstag, den 16.04.2020, 15:01 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > > And you are sure that the complexity of this is more than that of > > “fully settled” types? > > I didn't say that. But I am sure that it's more complicated than 6.1 > without 6.1.2! If I understand aright, the *only* gain is that one > can omit three words: > > import qualified MyMonad that’s fair… I guess with 6.1 we would imply To use qualified do, the recommended idiom is to import the module (1) qualified and (2) without an explicit import list. Put like this, I think I can live it with it. I still find it odd that those people who like to list all imports explicitly would be forced to write import qualified MyMonad ((>>)) foo = MyMonad.do { a; b } and then even have to adjust the import list when they write foo = MyMonad.do { _ <- a; b } instead. But yeah, saying “just don’t list your imports when you qualify your module import” works indeed. With that, I am happy to support 6.1 as well (but still prefer 6.1.2) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Fri Apr 17 22:16:06 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 17 Apr 2020 22:16:06 +0000 Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals] RecordDotSyntax language extension proposal (#282) In-Reply-To: References: Message-ID: 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 Sent: 11 April 2020 17:59 To: ghc-proposals/ghc-proposals Cc: Simon Peyton Jones ; Mention Subject: Re: [ghc-proposals/ghc-proposals] RecordDotSyntax language extension proposal (#282) @simonpj 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. * To address the question of what happens if a field name is an operator (see Note 6) See section 2.1.3. 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, or unsubscribe. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Apr 22 10:10:00 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 22 Apr 2020 12:10:00 +0200 Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals] RecordDotSyntax language extension proposal (#282) In-Reply-To: References: Message-ID: It's a very well written proposal, indeed. I've already paged out the details of the syntax we agreed upon. But I'm not sure that the parenthesis-based example in Section 5 (Costs and Drawbacks) is correct in the current specification. Simon, you should probably check this. That's pretty minor at the end, just a consistency thing. It's all good for me. On Sat, Apr 18, 2020 at 12:16 AM Simon Peyton Jones via ghc-steering-committee wrote: > 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 > *Sent:* 11 April 2020 17:59 > *To:* ghc-proposals/ghc-proposals > *Cc:* Simon Peyton Jones ; Mention < > mention at noreply.github.com> > *Subject:* Re: [ghc-proposals/ghc-proposals] RecordDotSyntax language > extension proposal (#282) > > > > @simonpj > > > 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 > > . > > > - To address the question of what happens if a field name is an > operator (see Note 6) > > See section 2.1.3 > > . > > 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 > , > or unsubscribe > > . > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Apr 22 10:26:16 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 22 Apr 2020 12:26:16 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: Dear Committe, trying to summarize the discussion here. The main decision seems to be: Record based or module based. Record based is preferred by: Arnaud (one of the authors), SPJ Module based is preferred by: Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro, me This is not a vote, merely a summary of sentimenss. But it seems that maybe the onus to make stronger arguments for the record-based approach is on Simon and Arnaud? Related to the module based variant, there was some discussion about whether the * desugaring should go to a “qualified name”, that is then resolved like any manually written name (i.e. could conceptually be done in the parser) * or if it should go directly a suitable “original name” of a suitable function, even if not explicitly imported (i.e. could conceptually be done in the renamer, but not the parser) I initially advocated for the latter, arguing with a “you shall not have to import stuff you do not write explicitly” rule. But Simon’s recent argument that import qualified Monad as M (i.e. _with_ qualification, but _without_ an import list) will give the developer a good user experience, and if they try to do things like import Monad as M (runMonad) … M.do … then, well, they shouldn’t. So I am happy to advocate for the module based approach with the “must be in scope” rule. But maybe we should keep the focus more on the fundamental question above. We could keep in mind that eventually, people will ask for M.if; M.[ and other “qualified syntax”. But it seems that that will work equally well with either choice here. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From tomjharding at live.co.uk Sun Apr 26 17:21:49 2020 From: tomjharding at live.co.uk (Tom Harding) Date: Sun, 26 Apr 2020 17:21:49 +0000 Subject: [ghc-steering-committee] Acceptance of proposal #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default Message-ID: <9197BB22-FA1D-4E5A-BC61-E2572DD31DCF@live.co.uk> 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-619588184 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Apr 27 18:12:04 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 27 Apr 2020 20:12:04 +0200 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Chis Allen In-Reply-To: References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <8b4a5b83cfcf2f1fcbe30ff25dd51ca968a9eedc.camel@joachim-breitner.de> Message-ID: <6be461e3ac2031f3c1871ea30921d2c0e6d33fc9.camel@joachim-breitner.de> Dear Chris, what is the status of this? In https://github.com/ghc-proposals/ghc-proposals/pull/303#issuecomment-620122718 the authors are getting a bit impatient, and it seems you never commented on the github thread (not even a “I’m looking into this”. Can you maybe make some noise over there? Cheers, Joachim Am Freitag, den 03.01.2020, 11:43 -0600 schrieb Christopher Allen: > This is an interesting proposal. The merits of the proposal are one > thing, but it also feels like someone is proposing to renovate an > abandoned corner of GHC. I'll try to weigh these orthogonal benefits > as best I can. > > I'll take a deeper look after work. > > Cheers, > Chris > > On Fri, Jan 3, 2020 at 11:30 AM Joachim Breitner > wrote: > > Of course I mean Chris Allen. Sorry for the confusion. > > > > Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: > > > 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-notation/proposals/0000-constraint-based-arrow-notation.md > > > > > > 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 Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/