From marlowsd at gmail.com Sun Nov 1 10:41:57 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 1 Nov 2020 10:41:57 +0000 Subject: [ghc-steering-committee] #283: Local modules, recommendation: accept In-Reply-To: References: <46858f58fc6a1f95b13b5cc6bf5a5756edf31aec.camel@joachim-breitner.de> Message-ID: On Wed, 21 Oct 2020 at 07:40, Spiwack, Arnaud wrote: > Simon (Marlow): > > Do I understand correctly that what you are objecting to is the following > syntax in the proposal > > module M where > import module M where > > And would rather have > > qualified module M where > module M where > > To mimic the import declaration behaviour? > Yes. And instead of import M (module N) import M (import module N) we would write import M (qualified module N) import M (module N) It seems to me to be desirable to use the same convention for all of: * importing modules at the top level ([import M [qualified]) * importing a local module (import M ([qualified] module N)) * declaring a local module ([qualified] module M where ..) * exporting a local module (module M ([qualified] module M) where) and perhaps it would be a source of confusion if these were different, as in the proposal. (but it's hard to tell, since we don't have any experience with using the extension yet.) Richard, what do you think? Cheers Simon > On Sat, Oct 17, 2020 at 9:33 PM Alejandro Serrano Mena > wrote: > >> I like the proposal as it stands. >> >> El jue., 15 oct. 2020 a las 20:09, Spiwack, Arnaud (< >> arnaud.spiwack at tweag.io>) escribió: >> >>> >>> In >>>> particular excited about the ability to locally open a module >>>> (something that I began to like when writing Ocaml). >>>> >>> >>> It is also one of my favourite features in Ocaml. It's a fairly recent >>> addition to Ocaml (10ish years ago, I would say?), and I believe it's fair >>> to say that it had a profound impact on coding style throughout the >>> community. For the better in my opinion. >>> _______________________________________________ >>> 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 Nov 2 08:57:51 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 02 Nov 2020 09:57:51 +0100 Subject: [ghc-steering-committee] Please review #372: The GHC20xx process, Shepherd: Simon PJ Message-ID: <0dd3a6725cc789874774c24157d1a2cbefb993f9.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: Alejandro and I have drafted a process for GHC20xx https://github.com/ghc-proposals/ghc-proposals/pull/372 https://github.com/ghc-proposals/ghc-proposals/blob/ghc20xx-process/proposals/0000-ghc-extensions.rstI’ll propose Eric Seidel as the shepherd.b I’ll propose Simon PJ as the shepherd, as this is a procedural metaprocess that benefits from chair involvement. This is mostly the outcome of discussions we already had, so I don’t expect we need a lot of further discussion, and could maybe vote soon. Note that there are two alternatives in “2.2 Process“. They differ in the form the community is invited to be involved, and also in the overall weight of the process. The main difference is Do we want to _encourage_ broad discussion of individual extensions (the point of Alternative 2), because we believe it is useful and healthy, or do we want to avoid stirring such discussions (Alternative 1), because we don’t believe they would add much, would be distracting and time consuming, and because there is enough existing signal (the poll, reddit, the PR comment section, …). There are procedural differences that follow from that, e.g. using a separate repository (Alternative 2) or using our existing one (Alternative 1), but in a way the overall aim is the core of this alternative. Simon, once you think all interesting points have been raised (which may already be the case) I suggest you call for a ranked vote with the options “Reject”, “Alternative 1”, “Alternative 2”. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Mon Nov 2 09:08:11 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 02 Nov 2020 10:08:11 +0100 Subject: [ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding Message-ID: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: DuplicateRecordFields without ambiguous field access was proposed by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/366 https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst I’ll propose Tom Harding 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/ From mail at joachim-breitner.de Mon Nov 2 13:07:18 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 02 Nov 2020 14:07:18 +0100 Subject: [ghc-steering-committee] Haskell 2020 Survey Message-ID: <558baa3890458eb3afae8bc2fc7d9d65922374dd.camel@joachim-breitner.de> Hi Committee, in case you didn’t see it: The yearly “State of Haskell Survey” at https://haskellweekly.news/survey/2020.html traditionally asked for “Which language extensions would you like to be enabled by default”. In pro-active anticipation of our GHC2020 process, they have changed the survey to let the community vote in favor, against, or abstain each extension. This should be sufficient for us to gauge whether there is interest in an extension being on by default, and whether there is contention about it. Just as Simon Marlow, I see no point in doing a very similar poll shortly after, and would just use the data coming out of that for GHC2021 (assuming we do the GHC2021 thing). I’ll say so (“If there is a GHC2021 language set, then the committee will very likely take the outcome of this poll into account.”) publicly, to encourage the community to take part in the survey. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From marlowsd at gmail.com Mon Nov 2 13:34:54 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 2 Nov 2020 13:34:54 +0000 Subject: [ghc-steering-committee] Haskell 2020 Survey In-Reply-To: <558baa3890458eb3afae8bc2fc7d9d65922374dd.camel@joachim-breitner.de> References: <558baa3890458eb3afae8bc2fc7d9d65922374dd.camel@joachim-breitner.de> Message-ID: On Mon, 2 Nov 2020 at 13:07, Joachim Breitner wrote: > Hi Committee, > > in case you didn’t see it: The yearly “State of Haskell Survey” > at https://haskellweekly.news/survey/2020.html traditionally asked for > “Which language extensions would you like to be enabled by default”. > > In pro-active anticipation of our GHC2020 process, they have changed > the survey to let the community vote in favor, against, or abstain each > extension. This should be sufficient for us to gauge whether there is > interest in an extension being on by default, and whether there is > contention about it. > > Just as Simon Marlow, I see no point in doing a very similar poll > shortly after, and would just use the data coming out of that for > GHC2021 (assuming we do the GHC2021 thing). I’ll say so (“If there is a > GHC2021 language set, then the committee will very likely take the > outcome of this poll into account.”) publicly, to encourage the > community to take part in the survey. > Suggestion: "... the committee will use that data to help decide which extensions should be part of GHC2021". Just trying to avoid any accidental impression that the result of the poll will be directly used without any further consideration. Cheers Simon > > 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 Mon Nov 2 13:42:28 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 02 Nov 2020 14:42:28 +0100 Subject: [ghc-steering-committee] Haskell 2020 Survey In-Reply-To: References: <558baa3890458eb3afae8bc2fc7d9d65922374dd.camel@joachim-breitner.de> Message-ID: <0d5fc1170f2a69d3a2aedb4e12ab57439165c617.camel@joachim-breitner.de> Hi, Am Montag, den 02.11.2020, 13:34 +0000 schrieb Simon Marlow: > Suggestion: "... the committee will use that data to help decide > which extensions should be part of GHC2021". Just trying to avoid > any accidental impression that the result of the poll will be > directly used without any further consideration. doesn't “take into account” express precisely that? Anyways, too late now :-) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From rae at richarde.dev Mon Nov 2 19:34:17 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 2 Nov 2020 19:34:17 +0000 Subject: [ghc-steering-committee] #283: Local modules, recommendation: accept In-Reply-To: References: <46858f58fc6a1f95b13b5cc6bf5a5756edf31aec.camel@joachim-breitner.de> Message-ID: <010f01758a73f851-54bb8d9c-c002-4cf0-a2f7-914d6bcb4472-000000@us-east-2.amazonses.com> > On Nov 1, 2020, at 5:41 AM, Simon Marlow wrote: > > Richard, what do you think? I tend to agree that keeping defaults consistent is a good idea. I think that, subconsciously, the reason I designed the proposal the way I did was because I think the default of unqualified is wrong. But that's not a battle I wish to fight, and this kind of consistency has real merit. When I take a pass through the proposal to update it, I'll either add this (making unqualified the default for the new features) as a fleshed out alternative or incorporate it directly, depending on which would read more easily. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 4 13:38:56 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 4 Nov 2020 13:38:56 +0000 Subject: [ghc-steering-committee] GHC 20xx process Message-ID: Friends We are asked to consider Proposal 371: the GHC 20xx process We have discussed it quite a bit already and I recommend acceptance. It includes "Alternative1" and "Alternative2" at one point. I found Alternative 2 hard to parse (seemed very process-heavy), so I favour Alternative 1 which seemed simpler. Please respond within the next week or two, either on the discussion thread, or to this email. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed Nov 4 14:39:35 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 4 Nov 2020 14:39:35 +0000 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: References: Message-ID: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> As the proponent for Alternative 2: the main goal of Alternative 2 is to create an organized place for debating individual extensions. In a perfect world, I'd prefer Alternative 1, for its simplicity. However, I have a hard time believing we'll get through this process without significant debate, and I worry that Alternative 1 provides no organization for that debate, and so it will end up sprawling over other discussions. I'm not wedded to any details in Alternative 2, just advocating for some imposed organization. Thanks, Richard > On Nov 4, 2020, at 8:38 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > Friends > > We are asked to consider Proposal 371: the GHC 20xx process > We have discussed it quite a bit already and I recommend acceptance. > > It includes “Alternative1” and “Alternative2” at one point. I found Alternative 2 hard to parse (seemed very process-heavy), so I favour Alternative 1 which seemed simpler. > > Please respond within the next week or two, either on the discussion thread, or to this email. > > Thanks > > Simon > > > > > > _______________________________________________ > 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 Nov 4 15:18:40 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Wed, 4 Nov 2020 18:18:40 +0300 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> References: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> Message-ID: I think that the ability to discuss every proposed extension within the broad community may become not a very effective thing actually. It seems that many extensions could become controversial under Alternative 2 thus making the overall result too shallow. By the way, does anyone expect abuse of the process? I prefer Alternative 1 for this reason though organizing a place for an in-committee debate in the spirit of Alternative 2 looks appealing. Regards, Vitaly ср, 4 нояб. 2020 г. в 17:39, Richard Eisenberg : > As the proponent for Alternative 2: the main goal of Alternative 2 is to > create an organized place for debating individual extensions. In a perfect > world, I'd prefer Alternative 1, for its simplicity. However, I have a hard > time believing we'll get through this process without significant debate, > and I worry that Alternative 1 provides no organization for that debate, > and so it will end up sprawling over other discussions. > > I'm not wedded to any details in Alternative 2, just advocating for some > imposed organization. > > Thanks, > Richard > > On Nov 4, 2020, at 8:38 AM, Simon Peyton Jones via ghc-steering-committee < > ghc-steering-committee at haskell.org> wrote: > > Friends > > We are asked to consider Proposal 371: the GHC 20xx process > > > We have discussed it quite a bit already and I recommend acceptance. > > It includes “Alternative1” and “Alternative2” at one point. I found > Alternative 2 hard to parse (seemed very process-heavy), so I favour > Alternative 1 which seemed simpler. > > Please respond within the next week or two, either on the discussion > thread, or to this email. > > Thanks > > Simon > > > > > _______________________________________________ > 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 tomjharding at live.co.uk Wed Nov 4 15:22:14 2020 From: tomjharding at live.co.uk (Tom Harding) Date: Wed, 4 Nov 2020 15:22:14 +0000 Subject: [ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding In-Reply-To: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> References: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> Message-ID: Hi all, I’d like to open committee discussion for DuplicateRecordFields without ambiguous field access. Other committee members have already commented, and I’ll say I’m strongly in favour of this proposal. I definitely see the suggestion here as “tidying up” an unintuitive - perhaps even counterintuitive - behaviour. https://github.com/ghc-proposals/ghc-proposals/pull/366 Thanks, Tom PS. Sorry for my recent absence; I think it has been a very strange few months for all us! On 2 Nov 2020, at 09:08, Joachim Breitner > wrote: Dear Committee, this is your secretary speaking: DuplicateRecordFields without ambiguous field access was proposed by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/366 https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst I’ll propose Tom Harding 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 4 15:27:23 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 4 Nov 2020 15:27:23 +0000 Subject: [ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding In-Reply-To: References: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> Message-ID: As I say on the discussion thread, I’m strongly in favour. Simon From: ghc-steering-committee On Behalf Of Tom Harding Sent: 04 November 2020 15:22 To: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding Hi all, I’d like to open committee discussion for DuplicateRecordFields without ambiguous field access. Other committee members have already commented, and I’ll say I’m strongly in favour of this proposal. I definitely see the suggestion here as “tidying up” an unintuitive - perhaps even counterintuitive - behaviour. https://github.com/ghc-proposals/ghc-proposals/pull/366 Thanks, Tom PS. Sorry for my recent absence; I think it has been a very strange few months for all us! On 2 Nov 2020, at 09:08, Joachim Breitner > wrote: Dear Committee, this is your secretary speaking: DuplicateRecordFields without ambiguous field access was proposed by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/366 https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst I’ll propose Tom Harding 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Wed Nov 4 16:08:51 2020 From: eric at seidel.io (Eric Seidel) Date: Wed, 04 Nov 2020 11:08:51 -0500 Subject: [ghc-steering-committee] =?utf-8?q?Please_review_=23366=3A_Duplic?= =?utf-8?q?ateRecordFields_without_ambiguous_field_access=2C_Shepherd=3A_T?= =?utf-8?q?om_Harding?= In-Reply-To: References: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> Message-ID: I agree that the current behavior is often unintuitive and would be better supported by RecordDotSyntax. On Wed, Nov 4, 2020, at 10:27, Simon Peyton Jones via ghc-steering-committee wrote: > > As I say on the discussion thread, I’m strongly in favour. > > > Simon > > > > *From:* ghc-steering-committee > *On Behalf Of *Tom Harding > *Sent:* 04 November 2020 15:22 > *To:* ghc-steering-committee at haskell.org > *Subject:* Re: [ghc-steering-committee] Please review #366: > DuplicateRecordFields without ambiguous field access, Shepherd: Tom > Harding > > > > Hi all, > > I’d like to open committee discussion for *DuplicateRecordFields > without ambiguous field access*. Other committee members have already > commented, and I’ll say I’m strongly in favour of this proposal. I > definitely see the suggestion here as “tidying up” an unintuitive - > perhaps even counterintuitive - behaviour. > > > > https://github.com/ghc-proposals/ghc-proposals/pull/366 > > > > > Thanks, > > Tom > > > PS. Sorry for my recent absence; I think it has been a very strange few > months for all us! > > > > > On 2 Nov 2020, at 09:08, Joachim Breitner wrote: > > > > Dear Committee, > > > > this is your secretary speaking: > > > > DuplicateRecordFields without ambiguous field access > > was proposed by Adam Gundry > > https://github.com/ghc-proposals/ghc-proposals/pull/366 > > https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst > > > > I’ll propose Tom Harding 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 > > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From arnaud.spiwack at tweag.io Wed Nov 4 16:49:55 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 4 Nov 2020 17:49:55 +0100 Subject: [ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding In-Reply-To: References: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> Message-ID: I have no strong opinion about this proposal, although removing code is always good. I find the argument about pattern synonyms convincing, however. And the idea of using `RecordDotSyntax` and type classes to sort type-oriented disambiguation out is certainly appealing. So take my vote as a soft yes. /Arnaud On Wed, Nov 4, 2020 at 5:09 PM Eric Seidel wrote: > I agree that the current behavior is often unintuitive and would be better > supported by RecordDotSyntax. > > On Wed, Nov 4, 2020, at 10:27, Simon Peyton Jones via > ghc-steering-committee wrote: > > > > As I say on the discussion thread, I’m strongly in favour. > > > > > > Simon > > > > > > > > *From:* ghc-steering-committee > > *On Behalf Of *Tom Harding > > *Sent:* 04 November 2020 15:22 > > *To:* ghc-steering-committee at haskell.org > > *Subject:* Re: [ghc-steering-committee] Please review #366: > > DuplicateRecordFields without ambiguous field access, Shepherd: Tom > > Harding > > > > > > > > Hi all, > > > > I’d like to open committee discussion for *DuplicateRecordFields > > without ambiguous field access*. Other committee members have already > > commented, and I’ll say I’m strongly in favour of this proposal. I > > definitely see the suggestion here as “tidying up” an unintuitive - > > perhaps even counterintuitive - behaviour. > > > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/366 > > < > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F366&data=04%7C01%7Csimonpj%40microsoft.com%7C943716dad34746aa01dd08d880d57d9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401003095757046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8T%2FxKBAkwtJgmCeg0%2BIr8IuOURniTXvGd%2F7%2FbIgbcGg%3D&reserved=0> > > > > > > > > > Thanks, > > > > Tom > > > > > > PS. Sorry for my recent absence; I think it has been a very strange few > > months for all us! > > > > > > > > > On 2 Nov 2020, at 09:08, Joachim Breitner > wrote: > > > > > > Dear Committee, > > > > > > this is your secretary speaking: > > > > > > DuplicateRecordFields without ambiguous field access > > > was proposed by Adam Gundry > > > https://github.com/ghc-proposals/ghc-proposals/pull/366 < > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F366&data=04%7C01%7Csimonpj%40microsoft.com%7C943716dad34746aa01dd08d880d57d9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401003095767043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=O7yXaTttgOLAEC36SQF%2FK9INxrBxiUazko6iEDZOMqo%3D&reserved=0 > > > > > > https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst > > > > > > I’ll propose Tom Harding 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 > > > > > > > > _______________________________________________ > > 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 rae at richarde.dev Wed Nov 4 18:02:24 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 4 Nov 2020 18:02:24 +0000 Subject: [ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding In-Reply-To: References: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> Message-ID: <010f0175946c9144-b560d4aa-a987-42a6-b09f-853dcb4cee40-000000@us-east-2.amazonses.com> I am in favor -- I've never liked the current behavior much and will be glad to see it removed. Richard > On Nov 4, 2020, at 11:49 AM, Spiwack, Arnaud wrote: > > I have no strong opinion about this proposal, although removing code is always good. > > I find the argument about pattern synonyms convincing, however. And the idea of using `RecordDotSyntax` and type classes to sort type-oriented disambiguation out is certainly appealing. > > So take my vote as a soft yes. > > /Arnaud > > On Wed, Nov 4, 2020 at 5:09 PM Eric Seidel > wrote: > I agree that the current behavior is often unintuitive and would be better supported by RecordDotSyntax. > > On Wed, Nov 4, 2020, at 10:27, Simon Peyton Jones via ghc-steering-committee wrote: > > > > As I say on the discussion thread, I’m strongly in favour. > > > > > > Simon > > > > > > > > *From:* ghc-steering-committee > > > *On Behalf Of *Tom Harding > > *Sent:* 04 November 2020 15:22 > > *To:* ghc-steering-committee at haskell.org > > *Subject:* Re: [ghc-steering-committee] Please review #366: > > DuplicateRecordFields without ambiguous field access, Shepherd: Tom > > Harding > > > > > > > > Hi all, > > > > I’d like to open committee discussion for *DuplicateRecordFields > > without ambiguous field access*. Other committee members have already > > commented, and I’ll say I’m strongly in favour of this proposal. I > > definitely see the suggestion here as “tidying up” an unintuitive - > > perhaps even counterintuitive - behaviour. > > > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/366 > > > > > > > > > > > Thanks, > > > > Tom > > > > > > PS. Sorry for my recent absence; I think it has been a very strange few > > months for all us! > > > > > > > > > On 2 Nov 2020, at 09:08, Joachim Breitner > wrote: > > > > > > Dear Committee, > > > > > > this is your secretary speaking: > > > > > > DuplicateRecordFields without ambiguous field access > > > was proposed by Adam Gundry > > > https://github.com/ghc-proposals/ghc-proposals/pull/366 > > > > https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst > > > > > > I’ll propose Tom Harding 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 > > > > > > > > _______________________________________________ > > 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 Wed Nov 4 19:45:13 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Wed, 4 Nov 2020 20:45:13 +0100 Subject: [ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding In-Reply-To: <010f0175946c9144-b560d4aa-a987-42a6-b09f-853dcb4cee40-000000@us-east-2.amazonses.com> References: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> <010f0175946c9144-b560d4aa-a987-42a6-b09f-853dcb4cee40-000000@us-east-2.amazonses.com> Message-ID: I have never used DuplicateRecordFields, but this simplification makes sense to me. Alejandro El mié., 4 nov. 2020 a las 19:02, Richard Eisenberg () escribió: > I am in favor -- I've never liked the current behavior much and will be > glad to see it removed. > > Richard > > On Nov 4, 2020, at 11:49 AM, Spiwack, Arnaud > wrote: > > I have no strong opinion about this proposal, although removing code is > always good. > > I find the argument about pattern synonyms convincing, however. And the > idea of using `RecordDotSyntax` and type classes to sort type-oriented > disambiguation out is certainly appealing. > > So take my vote as a soft yes. > > /Arnaud > > On Wed, Nov 4, 2020 at 5:09 PM Eric Seidel wrote: > >> I agree that the current behavior is often unintuitive and would be >> better supported by RecordDotSyntax. >> >> On Wed, Nov 4, 2020, at 10:27, Simon Peyton Jones via >> ghc-steering-committee wrote: >> > >> > As I say on the discussion thread, I’m strongly in favour. >> > >> > >> > Simon >> > >> > >> > >> > *From:* ghc-steering-committee >> > *On Behalf Of *Tom Harding >> > *Sent:* 04 November 2020 15:22 >> > *To:* ghc-steering-committee at haskell.org >> > *Subject:* Re: [ghc-steering-committee] Please review #366: >> > DuplicateRecordFields without ambiguous field access, Shepherd: Tom >> > Harding >> > >> > >> > >> > Hi all, >> > >> > I’d like to open committee discussion for *DuplicateRecordFields >> > without ambiguous field access*. Other committee members have already >> > commented, and I’ll say I’m strongly in favour of this proposal. I >> > definitely see the suggestion here as “tidying up” an unintuitive - >> > perhaps even counterintuitive - behaviour. >> > >> > >> > >> > https://github.com/ghc-proposals/ghc-proposals/pull/366 >> > < >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F366&data=04%7C01%7Csimonpj%40microsoft.com%7C943716dad34746aa01dd08d880d57d9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401003095757046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8T%2FxKBAkwtJgmCeg0%2BIr8IuOURniTXvGd%2F7%2FbIgbcGg%3D&reserved=0> >> >> > >> > >> > >> > Thanks, >> > >> > Tom >> > >> > >> > PS. Sorry for my recent absence; I think it has been a very strange few >> > months for all us! >> > >> > >> > >> > > On 2 Nov 2020, at 09:08, Joachim Breitner >> wrote: >> > > >> > > Dear Committee, >> > > >> > > this is your secretary speaking: >> > > >> > > DuplicateRecordFields without ambiguous field access >> > > was proposed by Adam Gundry >> > > https://github.com/ghc-proposals/ghc-proposals/pull/366 < >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F366&data=04%7C01%7Csimonpj%40microsoft.com%7C943716dad34746aa01dd08d880d57d9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401003095767043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=O7yXaTttgOLAEC36SQF%2FK9INxrBxiUazko6iEDZOMqo%3D&reserved=0 >> > >> > > >> https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst >> > > >> > > I’ll propose Tom Harding 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 >> > >> > >> > >> > _______________________________________________ >> > 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 rae at richarde.dev Fri Nov 6 19:55:57 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 6 Nov 2020 19:55:57 +0000 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: <2d6e721dbc94e3457cbb4c866d5bac8912f8dddb.camel@joachim-breitner.de> References: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> <2d6e721dbc94e3457cbb4c866d5bac8912f8dddb.camel@joachim-breitner.de> Message-ID: <010f01759f213e2a-3aa6a574-bb64-4d1d-ad90-8f9d55a6d701-000000@us-east-2.amazonses.com> This is an effective argument; you've changed my mind. I'm now in favor of Joachim's simpler process. Thanks for writing this all out! Richard > On Nov 6, 2020, at 4:02 AM, Joachim Breitner wrote: > > Hi, > > we may be repeating points here, but I am still strongly leaning > towards a more lightweight process. At least initially, so that we can > iterate towards something more heavy in later rounds, rather than going > the other way (in general easier to add process than remove process). > > You mention that discussions will pop us elsewhere. I don’t find that > bad! We committee members are here to represent the community, and I > expect that enough of us are “in touch” with the community to pick up > useful signal, even if it happens on reddit or twitter, and will carry > that into their votes and rationales. There will be discussion in > reddit and twitter and mailing lists _anyways_! > > What I want to avoid is sending a signal to the community to say “we > are going to do about 100 individual decisions soon and, by the way, we > really encourage you to comment on all of them (why else would we give > you the explicit space). > I’d rather send the signal “we are going to > make 100 individual decisions, here you can follow the process, and if > you _really_ think we are missing something, this PR is where your > input is welcome.” > > Also, speaking as the secretary, managing a separate repo and expecting > all of us to following many different issues seems out of proportion of > what we want to achieve here. > > > Maybe popping up a bit: It’s worth noting that the first round will be > very different than all the subsequent roads. In the first round we > have a _large_ number of low-hanging fruit to pluck. In fact, it’s so > many of them, that I expect we simply don't have the capacity to do > very careful deliberation of each of them. > > This implies that the first round, we should aim _low_, and be very > conservative, knowing that the following rounds we have less to > discuss, and can then be more careful discussions about those > extensions that need those discussions. > > So what does this mean for community involvement? There are two cases > for a given extension FooBar: > > * Our vote initially doesn’t include FooBar. > > Yes, for almost every extension there will be a few people who think > that it should be in. This is not very useful signal! > > In fact, in this case, we’d likely say “thanks for your input! For > the first round, we are going to be conservative, and we didn’t > include FooBar for now. But maybe next year!” > > I don’t think we or the community benefits from first making space > for that discussion, to then only cut it off politely. > > * Our vote initially includes FooBar. > > Then, maybe, someone has a good argument why FooBar is actually less > harmless than we have thought. That _is_ useful signal! > > But I expect this to be rare: It only applies to the already > filtered list of extensions, not all 100, and if we do our job good, > only a few cases like this arise. Thus a normal discussion on the PR > on our normal repository, just like with any other proposal, > suffices to get that signal. > > I am making a few assumptions here about how we want to run this > (aiming for a conservative list of extensions in the first round, and > trying to be efficient with our own resources), and with these > assumption the more lightweight process seems more appropriate to begin > with. > > One can of course disagree with these assumption (e.g. aiming for a > very elaborate process to pick a very “complete” set right away), and > then deduce that Alternative 2 is needed. > > > 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 mail at joachim-breitner.de Mon Nov 9 16:28:19 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 09 Nov 2020 17:28:19 +0100 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: <010f01759f213e2a-3aa6a574-bb64-4d1d-ad90-8f9d55a6d701-000000@us-east-2.amazonses.com> References: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> <2d6e721dbc94e3457cbb4c866d5bac8912f8dddb.camel@joachim-breitner.de> <010f01759f213e2a-3aa6a574-bb64-4d1d-ad90-8f9d55a6d701-000000@us-east-2.amazonses.com> Message-ID: <45ef1fcc7594311da0eb119dbb189732554c41c9.camel@joachim-breitner.de> Hi, Am Freitag, den 06.11.2020, 19:55 +0000 schrieb Richard Eisenberg: > This is an effective argument; you've changed my mind. > > I'm now in favor of Joachim's simpler process. thanks, also for making me get more clarity on this as well. Is anyone still preferring Alternative 2, or should we take it off the table? Is anyone not in favor of this proposal, or has questions, or shall we declare consensus and merge it? It seems that now is a good time to then actually do the first iteration of the process – the State of Haskell survey data, once out, will be fresh, and we'd be well in time for inclusion in the Spring release of GHC, likely 9.1 (unless the 9.0 delay shifts things around… oh well, let’s just make sure we have GHC2021 defined before or near the start of 2021, not late in that year :-)) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Tue Nov 10 11:18:22 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 10 Nov 2020 11:18:22 +0000 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: <45ef1fcc7594311da0eb119dbb189732554c41c9.camel@joachim-breitner.de> References: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> <2d6e721dbc94e3457cbb4c866d5bac8912f8dddb.camel@joachim-breitner.de> <010f01759f213e2a-3aa6a574-bb64-4d1d-ad90-8f9d55a6d701-000000@us-east-2.amazonses.com> <45ef1fcc7594311da0eb119dbb189732554c41c9.camel@joachim-breitner.de> Message-ID: | Is anyone not in favor of this proposal, or has questions, or shall we | declare consensus and merge it? In my message of 4 Nov, I asked for feedback within "a week or two". Let's set a deadline of the end of this week. All: please respond before then, if you want to. I don't think this is terribly controversial, so I'll take silence as assent. All this assuming we adopt Alternative 1. Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Joachim Breitner | Sent: 09 November 2020 16:28 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] GHC 20xx process | | Hi, | | Am Freitag, den 06.11.2020, 19:55 +0000 schrieb Richard Eisenberg: | > This is an effective argument; you've changed my mind. | > | > I'm now in favor of Joachim's simpler process. | | thanks, also for making me get more clarity on this as well. | | Is anyone still preferring Alternative 2, or should we take it off the | table? | | Is anyone not in favor of this proposal, or has questions, or shall we | declare consensus and merge it? | | | It seems that now is a good time to then actually do the first iteration of | the process – the State of Haskell survey data, once out, will be fresh, and | we'd be well in time for inclusion in the Spring release of GHC, likely 9.1 | (unless the 9.0 delay shifts things around… oh well, let’s just make sure we | have GHC2021 defined before or near the start of 2021, not late in that year | :-)) | | Cheers, | Joachim | | -- | Joachim Breitner | mail at joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C125f812494db4225 | 0f4808d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63740536191896 | 4507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BfuHY7eCNyF5QlP7BfXDrNjxgWhoj%2FGI92S | esCy1gLA%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.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C125f812494db42250f480 | 8d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637405361918974502% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=TyxdMqz%2FXFY9WYgZKdUHkFSQEvqRMJdoVEajh39JNs | A%3D&reserved=0 From eric at seidel.io Tue Nov 10 19:10:10 2020 From: eric at seidel.io (Eric Seidel) Date: Tue, 10 Nov 2020 14:10:10 -0500 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: References: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> <2d6e721dbc94e3457cbb4c866d5bac8912f8dddb.camel@joachim-breitner.de> <010f01759f213e2a-3aa6a574-bb64-4d1d-ad90-8f9d55a6d701-000000@us-east-2.amazonses.com> <45ef1fcc7594311da0eb119dbb189732554c41c9.camel@joachim-breitner.de> Message-ID: <22f9e49e-c8e9-43a3-8421-fc6f3e8ca9a9@www.fastmail.com> Thanks Alejandro and Joachim for pushing this forward! I also suggested a heavier process along the lines of (2) at some point, but after reading the proposal and Joachim's argument here, I feel comfortable with (1) as well. Also, I think @AntC2 made a good point about -fglasgow-exts on the PR [1]. For the initial round it would be useful to list the extensions enabled by -fglasgow-exts as a reference point. [1]: https://github.com/ghc-proposals/ghc-proposals/pull/372#issuecomment-716066900 On Tue, Nov 10, 2020, at 06:18, Simon Peyton Jones via ghc-steering-committee wrote: > | Is anyone not in favor of this proposal, or has questions, or shall we > | declare consensus and merge it? > > In my message of 4 Nov, I asked for feedback within "a week or two". > Let's set a deadline of the end of this week. > > All: please respond before then, if you want to. > > I don't think this is terribly controversial, so I'll take silence as assent. > > All this assuming we adopt Alternative 1. > > Simon > > | -----Original Message----- > | From: ghc-steering-committee On > | Behalf Of Joachim Breitner > | Sent: 09 November 2020 16:28 > | To: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] GHC 20xx process > | > | Hi, > | > | Am Freitag, den 06.11.2020, 19:55 +0000 schrieb Richard Eisenberg: > | > This is an effective argument; you've changed my mind. > | > > | > I'm now in favor of Joachim's simpler process. > | > | thanks, also for making me get more clarity on this as well. > | > | Is anyone still preferring Alternative 2, or should we take it off the > | table? > | > | Is anyone not in favor of this proposal, or has questions, or shall we > | declare consensus and merge it? > | > | > | It seems that now is a good time to then actually do the first iteration of > | the process – the State of Haskell survey data, once out, will be fresh, and > | we'd be well in time for inclusion in the Spring release of GHC, likely 9.1 > | (unless the 9.0 delay shifts things around… oh well, let’s just make sure we > | have GHC2021 defined before or near the start of 2021, not late in that year > | :-)) > | > | Cheers, > | Joachim > | > | -- > | Joachim Breitner > | mail at joachim-breitner.de > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim > | - > | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C125f812494db4225 > | 0f4808d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63740536191896 > | 4507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BfuHY7eCNyF5QlP7BfXDrNjxgWhoj%2FGI92S > | esCy1gLA%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.haske > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C125f812494db42250f480 > | 8d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637405361918974502% > | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > | LCJXVCI6Mn0%3D%7C3000&sdata=TyxdMqz%2FXFY9WYgZKdUHkFSQEvqRMJdoVEajh39JNs > | A%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 > From iavor.diatchki at gmail.com Wed Nov 11 21:41:55 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 11 Nov 2020 13:41:55 -0800 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 Message-ID: Hello, Proposal #281 has been submitted for review by the committee again, please read through it and let's have a discussion. Here are links to the proposal's discussion section, and the proposal text: https://github.com/ghc-proposals/ghc-proposals/pull/281 https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst While I suggested acceptance on the previous version, I am leaning towards rejecting the proposal now. My reasoning is that I hadn't fully understood all the aspects of the original proposal, and the new proposal seems to lack a simple modular specification. There are *many* changes described in the document, but I found it hard to understand what is the current design, from the point of view of a user of the feature, as opposed to someone trying to implement it. I'd be curious about what others think. -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Thu Nov 12 08:23:44 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 12 Nov 2020 09:23:44 +0100 Subject: [ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding In-Reply-To: References: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> <010f0175946c9144-b560d4aa-a987-42a6-b09f-853dcb4cee40-000000@us-east-2.amazonses.com> Message-ID: For the sake of completeness, let me note that Ocaml has a type-based disambiguation of the sort. I've never heard anyone complain about it (though maybe they have); however I've never knowingly depended on it myself, so I'm not a good devil's advocate here. On Wed, Nov 4, 2020 at 8:45 PM Alejandro Serrano Mena wrote: > I have never used DuplicateRecordFields, but this simplification makes > sense to me. > > Alejandro > > El mié., 4 nov. 2020 a las 19:02, Richard Eisenberg () > escribió: > >> I am in favor -- I've never liked the current behavior much and will be >> glad to see it removed. >> >> Richard >> >> On Nov 4, 2020, at 11:49 AM, Spiwack, Arnaud >> wrote: >> >> I have no strong opinion about this proposal, although removing code is >> always good. >> >> I find the argument about pattern synonyms convincing, however. And the >> idea of using `RecordDotSyntax` and type classes to sort type-oriented >> disambiguation out is certainly appealing. >> >> So take my vote as a soft yes. >> >> /Arnaud >> >> On Wed, Nov 4, 2020 at 5:09 PM Eric Seidel wrote: >> >>> I agree that the current behavior is often unintuitive and would be >>> better supported by RecordDotSyntax. >>> >>> On Wed, Nov 4, 2020, at 10:27, Simon Peyton Jones via >>> ghc-steering-committee wrote: >>> > >>> > As I say on the discussion thread, I’m strongly in favour. >>> > >>> > >>> > Simon >>> > >>> > >>> > >>> > *From:* ghc-steering-committee >>> > *On Behalf Of *Tom >>> Harding >>> > *Sent:* 04 November 2020 15:22 >>> > *To:* ghc-steering-committee at haskell.org >>> > *Subject:* Re: [ghc-steering-committee] Please review #366: >>> > DuplicateRecordFields without ambiguous field access, Shepherd: Tom >>> > Harding >>> > >>> > >>> > >>> > Hi all, >>> > >>> > I’d like to open committee discussion for *DuplicateRecordFields >>> > without ambiguous field access*. Other committee members have already >>> > commented, and I’ll say I’m strongly in favour of this proposal. I >>> > definitely see the suggestion here as “tidying up” an unintuitive - >>> > perhaps even counterintuitive - behaviour. >>> > >>> > >>> > >>> > https://github.com/ghc-proposals/ghc-proposals/pull/366 >>> > < >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F366&data=04%7C01%7Csimonpj%40microsoft.com%7C943716dad34746aa01dd08d880d57d9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401003095757046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=8T%2FxKBAkwtJgmCeg0%2BIr8IuOURniTXvGd%2F7%2FbIgbcGg%3D&reserved=0> >>> >>> > >>> > >>> > >>> > Thanks, >>> > >>> > Tom >>> > >>> > >>> > PS. Sorry for my recent absence; I think it has been a very strange >>> few >>> > months for all us! >>> > >>> > >>> > >>> > > On 2 Nov 2020, at 09:08, Joachim Breitner >>> wrote: >>> > > >>> > > Dear Committee, >>> > > >>> > > this is your secretary speaking: >>> > > >>> > > DuplicateRecordFields without ambiguous field access >>> > > was proposed by Adam Gundry >>> > > https://github.com/ghc-proposals/ghc-proposals/pull/366 < >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F366&data=04%7C01%7Csimonpj%40microsoft.com%7C943716dad34746aa01dd08d880d57d9e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637401003095767043%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=O7yXaTttgOLAEC36SQF%2FK9INxrBxiUazko6iEDZOMqo%3D&reserved=0 >>> > >>> > > >>> https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst >>> > > >>> > > I’ll propose Tom Harding 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 >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 trupill at gmail.com Fri Nov 13 11:12:20 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 13 Nov 2020 03:12:20 -0800 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: References: Message-ID: Hi, I agree with Iavor’s points. The proposal is quite big, and there’s a lot on it about implementation, but not a simple user-facing spec. In addition to that, I would lean towards rejection because I think giving another meaning to `f Int 5` depending on the the type of `f` — if f doesn’t have a `forall a ->` then `Int` is thought as a constructor, otherwise it’s the type — makes the language too ambiguous. I thought that the language leaned more towards explicitness because DataKinds punning was removed (so I really need to write ‘Int to get the promoted Int constructor) and type applications required @ too. Another point which is discussed in the proposal not in detail, but I think it’s central to this discussion is: is @ a visibility-override or a other-namespace-symbol. Right now both are conflated by TypeApplications, but personally I think it more of it as the latter: if I am in “term-land” and I want to switch to “type-land”, then I use @. In essence, I think we should keep the two-namespaces separate (we could say I prefer a Haskell-2 instead of a Haskell-1). Alejandro On 11 Nov 2020 at 22:41:55, Iavor Diatchki wrote: > _______________________________________________ > 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 Fri Nov 13 11:29:50 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 13 Nov 2020 11:29:50 +0000 Subject: [ghc-steering-committee] Type applications in patterns Message-ID: Dear Steering Committee You may remember that we approved the Type Applications in Patterns proposal, some time ago. Cale has been implementing it (see ticket 11350 and MR 2464). It's nearly done. But in doing so, one design choice came up that we did not discuss much, and I'd like to consult you. Consider first the existing pattern-signature mechanism (not the new feature): data T a where MkT :: forall a b. a -> b -> T a f1 :: forall p. T [p] -> blah f1 (MkT (x :: a) pi) = blah f2 :: forall p. T [p] -> blah f2 (MkT (x :: p) pi) = blah In f1, the pattern (x :: a) brings 'a' into scope, binding it to the type [p]. But in f2, since p is already in scope, the pattern (x :: p) does not bring anything new into scope. Instead it requires that x have type p, but actually it has type [p], so f2 is rejected. Notice that a pattern signature brings a new variable into scope only if it isn't already in scope. Notice how this differs from the treatment of term variables; the 'pi' in the pattern brings 'pi' into scope unconditionally, shadowing the existing 'pi' (from the Prelude). OK, now let's look at the new feature. Consider g1 :: forall p. T [p] -> blah g1 (MkT @a x y) = blah g2 :: forall p. T [p] -> blah g2 (MkT @p x pi) = blah Question: should the variables free in these type arguments be treated like pattern signatures, or like term variables? 1. Like pattern signatures. In this design, in g1, 'a' is not in scope, so this brings it into scope, bound to [p]. But in g2, 'p' is in scope, so this is rejected (because MkT is instantiated at [p] not p. 2. Like term variables. In this design, all the variables free in type patterns are fresh, and brought into scope. In g2, a new 'p' is brought into scope, shadowing the existing 'p'; indeed the new 'p' is bound to [old_p]. The original paper, and hence the accepted proposal, adopts (A). But Cale likes (B). Indeed John Ericson wrote a Proposal 291: simplify scoping for type applications in pattens to advocate this change. (The proposal is not easy to understand, but advocating (B) is its payload. This is not a terribly big deal, but it would be good to settle it. The right place to have debate is on Proposal 291. This email is just to alert you to it, and ask for your opinions. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Fri Nov 13 13:40:16 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 13 Nov 2020 14:40:16 +0100 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: <22f9e49e-c8e9-43a3-8421-fc6f3e8ca9a9@www.fastmail.com> References: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> <2d6e721dbc94e3457cbb4c866d5bac8912f8dddb.camel@joachim-breitner.de> <010f01759f213e2a-3aa6a574-bb64-4d1d-ad90-8f9d55a6d701-000000@us-east-2.amazonses.com> <45ef1fcc7594311da0eb119dbb189732554c41c9.camel@joachim-breitner.de> <22f9e49e-c8e9-43a3-8421-fc6f3e8ca9a9@www.fastmail.com> Message-ID: Joachim puts his opinion quite eloquently and convincingly :-) I was initially in favour of one conversation space by proposed extension, but, at least for the first round this is likely to be overwhelming. At least, I haven't found or seen, yet, a way to make this manageable. So let me vote with the majority opinion here. Let's see how it goes really, if it doesn't work out how we expected this time around, we can change the process for the next iteration. /Arnaud On Tue, Nov 10, 2020 at 8:11 PM Eric Seidel wrote: > Thanks Alejandro and Joachim for pushing this forward! > > I also suggested a heavier process along the lines of (2) at some point, > but after reading the proposal and Joachim's argument here, I feel > comfortable with (1) as well. > > Also, I think @AntC2 made a good point about -fglasgow-exts on the PR [1]. > For the initial round it would be useful to list the extensions enabled by > -fglasgow-exts as a reference point. > > [1]: > https://github.com/ghc-proposals/ghc-proposals/pull/372#issuecomment-716066900 > > On Tue, Nov 10, 2020, at 06:18, Simon Peyton Jones via > ghc-steering-committee wrote: > > | Is anyone not in favor of this proposal, or has questions, or shall we > > | declare consensus and merge it? > > > > In my message of 4 Nov, I asked for feedback within "a week or two". > > Let's set a deadline of the end of this week. > > > > All: please respond before then, if you want to. > > > > I don't think this is terribly controversial, so I'll take silence as > assent. > > > > All this assuming we adopt Alternative 1. > > > > Simon > > > > | -----Original Message----- > > | From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> On > > | Behalf Of Joachim Breitner > > | Sent: 09 November 2020 16:28 > > | To: ghc-steering-committee at haskell.org > > | Subject: Re: [ghc-steering-committee] GHC 20xx process > > | > > | Hi, > > | > > | Am Freitag, den 06.11.2020, 19:55 +0000 schrieb Richard Eisenberg: > > | > This is an effective argument; you've changed my mind. > > | > > > | > I'm now in favor of Joachim's simpler process. > > | > > | thanks, also for making me get more clarity on this as well. > > | > > | Is anyone still preferring Alternative 2, or should we take it off the > > | table? > > | > > | Is anyone not in favor of this proposal, or has questions, or shall we > > | declare consensus and merge it? > > | > > | > > | It seems that now is a good time to then actually do the first > iteration of > > | the process – the State of Haskell survey data, once out, will be > fresh, and > > | we'd be well in time for inclusion in the Spring release of GHC, > likely 9.1 > > | (unless the 9.0 delay shifts things around… oh well, let’s just make > sure we > > | have GHC2021 defined before or near the start of 2021, not late in > that year > > | :-)) > > | > > | Cheers, > > | Joachim > > | > > | -- > > | Joachim Breitner > > | mail at joachim-breitner.de > > | > > | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim > > | - > > | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com > %7C125f812494db4225 > > | > 0f4808d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63740536191896 > > | > 4507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > > | > haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BfuHY7eCNyF5QlP7BfXDrNjxgWhoj%2FGI92S > > | esCy1gLA%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.haske > > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > > | committee&data=04%7C01%7Csimonpj%40microsoft.com > %7C125f812494db42250f480 > > | > 8d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637405361918974502% > > | > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > > | > LCJXVCI6Mn0%3D%7C3000&sdata=TyxdMqz%2FXFY9WYgZKdUHkFSQEvqRMJdoVEajh39JNs > > | A%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 > > > _______________________________________________ > 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 arnaud.spiwack at tweag.io Fri Nov 13 13:59:45 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 13 Nov 2020 14:59:45 +0100 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: References: Message-ID: I still want to suspend my judgement. The proposal is much better than the first iteration that I've read. It's clear and precise (except maybe the Alternative section which is light in details). I asked for several clarifications on the Proposal's thread. I'm still sympathetic to the motivation, and rather unconvinced by the proposed solution. I'm confident that we will eventually accept some version of this proposal (and even if this one gets rejected, a lot of the material in it will be useful for the next iteration of the proposal). I'm not sure that we have found the right approach yet. But I am not ready to discard this proposal wholesale either. This is turning into a pretty difficult conversation, I'm afraid, and I'm sorry for Vladislav who has to bear the brunt of the burden. But I think that it's a conversation worth having, and it is time well spent for the community. /Arnaud On Fri, Nov 13, 2020 at 12:12 PM Alejandro Serrano Mena wrote: > Hi, > I agree with Iavor’s points. The proposal is quite big, and there’s a lot > on it about implementation, but not a simple user-facing spec. > > In addition to that, I would lean towards rejection because I think giving > another meaning to `f Int 5` depending on the the type of `f` — if f > doesn’t have a `forall a ->` then `Int` is thought as a constructor, > otherwise it’s the type — makes the language too ambiguous. I thought that > the language leaned more towards explicitness because DataKinds punning was > removed (so I really need to write ‘Int to get the promoted Int > constructor) and type applications required @ too. > > Another point which is discussed in the proposal not in detail, but I > think it’s central to this discussion is: is @ a visibility-override or a > other-namespace-symbol. Right now both are conflated by TypeApplications, > but personally I think it more of it as the latter: if I am in “term-land” > and I want to switch to “type-land”, then I use @. In essence, I think we > should keep the two-namespaces separate (we could say I prefer a Haskell-2 > instead of a Haskell-1). > > Alejandro > > On 11 Nov 2020 at 22:41:55, Iavor Diatchki > wrote: > >> _______________________________________________ >> 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 arnaud.spiwack at tweag.io Fri Nov 13 14:10:09 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 13 Nov 2020 15:10:09 +0100 Subject: [ghc-steering-committee] Is @ a name-space override, or a visibility override? Message-ID: Dear all, There is a debate which has been held in our heads for quite some time now. But we’ve never really had the conversation. This debate has been raised again in the context of proposal #281. But I’d rather make a separate thread about it. The question is the following: When I write f @t Am I using @ as a way to change an invisible argument into a visible argument? Or am I using @ to insert a type expression into a term expression? ------------------------------ The truth is that it’s doing both at the same time. So some of us have taken to believing that the One True Meaning™ of @ is to override (in)visibility. While others have taken to believing that the One True Meaning™ of @ is to insert types in term. And, in both cases, we believe the other part to be incidental. In favour of types-in-term, there is the pretty-printer for Core, which, if I’m not mistaken, uses @t to denote type applications (and all type applications are visible in Core, so there is no visibility override to be had). Whatever we think about this, it appears that the fact that this meaning ascription is implicit has caused some anguish. So I think that we should have this discussion explicitly for once. I chose to do so in a different thread than the #281 discussion, because this discussion stands on its own. Anyway, the floor is yours. /Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Fri Nov 13 14:38:33 2020 From: eric at seidel.io (Eric Seidel) Date: Fri, 13 Nov 2020 09:38:33 -0500 Subject: [ghc-steering-committee] =?utf-8?q?Is_=40_a_name-space_override?= =?utf-8?q?=2C=09or_a_visibility_override=3F?= In-Reply-To: References: Message-ID: I've always been somewhat confused by the visible/invisible distinction, so I guess @ is a namespace override in my mind. There's another aspect of confusion around @ that came up in proposal #291, which Simon just brought up again. Is @ syntax for application or binding? Originally it was just application, then I believe we allowed it to bind existentials alone, and now there's work underway to allow it to bind any type variable in patterns. But reusing the same syntax for application and binding raises hairy questions like the one we're facing now in #291. On Fri, Nov 13, 2020, at 09:10, Spiwack, Arnaud wrote: > Dear all, > > There is a debate which has been held in our heads for quite some time > now. But we’ve never really had the conversation. This debate has been > raised again in the context of proposal #281. But I’d rather make a > separate thread about it. > > The question is the following: > > When I write > > `f @t > ` > Am I using `@` as a way to change an invisible argument into a visible > argument? Or am I using `@` to insert a type expression into a term > expression? > > The truth is that it’s doing both at the same time. So some of us have > taken to believing that the One True Meaning™ of `@` is to override > (in)visibility. While others have taken to believing that the One True > Meaning™ of `@` is to insert types in term. > > And, in both cases, we believe the other part to be incidental. > > In favour of types-in-term, there is the pretty-printer for Core, > which, if I’m not mistaken, uses `@t` to denote type applications (and > all type applications are visible in Core, so there is no visibility > override to be had). > > Whatever we think about this, it appears that the fact that this > meaning ascription is implicit has caused some anguish. So I think that > we should have this discussion explicitly for once. > > I chose to do so in a different thread than the #281 discussion, > because this discussion stands on its own. > > Anyway, the floor is yours. > > /Arnaud > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From marlowsd at gmail.com Fri Nov 13 15:44:07 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 13 Nov 2020 15:44:07 +0000 Subject: [ghc-steering-committee] Is @ a name-space override, or a visibility override? In-Reply-To: References: Message-ID: I haven't followed this debate, but the main question I have is: what are the implications of choosing one view over the other? Cheers SImon On Fri, 13 Nov 2020 at 14:10, Spiwack, Arnaud wrote: > Dear all, > > There is a debate which has been held in our heads for quite some time > now. But we’ve never really had the conversation. This debate has been > raised again in the context of proposal #281. But I’d rather make a > separate thread about it. > > The question is the following: > > When I write > > f @t > > Am I using @ as a way to change an invisible argument into a visible > argument? Or am I using @ to insert a type expression into a term > expression? > ------------------------------ > > The truth is that it’s doing both at the same time. So some of us have > taken to believing that the One True Meaning™ of @ is to override > (in)visibility. While others have taken to believing that the One True > Meaning™ of @ is to insert types in term. > > And, in both cases, we believe the other part to be incidental. > > In favour of types-in-term, there is the pretty-printer for Core, which, > if I’m not mistaken, uses @t to denote type applications (and all type > applications are visible in Core, so there is no visibility override to be > had). > > Whatever we think about this, it appears that the fact that this meaning > ascription is implicit has caused some anguish. So I think that we should > have this discussion explicitly for once. > > I chose to do so in a different thread than the #281 discussion, because > this discussion stands on its own. > > Anyway, the floor is yours. > > /Arnaud > _______________________________________________ > 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 Nov 13 15:51:58 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 13 Nov 2020 07:51:58 -0800 Subject: [ghc-steering-committee] Is @ a name-space override, or a visibility override? In-Reply-To: References: Message-ID: Hello, I believe the current design is that `@` is an application for providing "inferred" arguments (i.e., arguments that could be omitted but for whatever reason the user wants to provide explicitly). I don't really think of it in that way when I use it, and I don't think I am alone in that. This is why I wrote the following in the comments for #281: Imagine a system (different from what we have now) built out of the following components: The usual "empty space" operator means "I am applying a required argument". There is a different operator, say (`) for applying an inferred argument The prefix @ means "now I am writing an expression in the language above. In the case of values "above" means type, in the case of types, "above" would be kinds (or with TypeInType there would be no language "above" types). Here are some examples: Normal application is just like now: f x Applying a required type parameter: f @x Applying an inferred type parameter: f `@x We don't have inferred value parameters (dictionaries?), but if we did, we could apply them like this: f `x The same system can be extended with dependent types by adding a symbol to indicate "the language bellow", for example: The prefix ' means "now I am writing a term in the language below" This allows us to write dependent types like this: Here is a type that depends on a value: T '[1,2,3] This is not a design I've fully worked out, but is roughly how I think when I program. -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri Nov 13 16:10:31 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 13 Nov 2020 08:10:31 -0800 Subject: [ghc-steering-committee] Type applications in patterns In-Reply-To: References: Message-ID: Hello Simon, I think that the consistent choice would be "(A) like pattern signatures". I think this would ensure that all types in patterns handle variables in the same way. It would be confusing to me if the following two examples ended up doing different things: h1 (Nothing :: Maybe [p]) = ... h2 (Nothing @[p]) = ... -Iavor On Fri, Nov 13, 2020 at 3:30 AM Simon Peyton Jones via ghc-steering-committee wrote: > Dear Steering Committee > > You may remember that we approved the Type Applications in Patterns > > proposal, some time ago. Cale has been implementing it (see ticket 11350 > and MR 2464 > ). It’s > nearly done. > > But in doing so, one design choice came up that we did not discuss much, > and I’d like to consult you. > > Consider first the *existing* pattern-signature mechanism (not the new > feature): > > data T a where > > MkT :: forall a b. a -> b -> T a > > > > f1 :: forall p. T [p] -> blah > > f1 (MkT (x :: a) pi) = blah > > > > f2 :: forall p. T [p] -> blah > > f2 (MkT (x :: p) pi) = blah > > In f1, the pattern (x :: a) brings ‘a’ into scope, binding it to the type > [p]. But in f2, since p is already in scope, the pattern (x :: p) does not > bring anything new into scope. Instead it requires that x have type p, but > actually it has type [p], so f2 is rejected. > > Notice that a pattern signature brings a new variable into scope only if > it isn’t already in scope. Notice how this differs from the treatment of > term variables; the ‘pi’ in the pattern brings ‘pi’ into scope > unconditionally, shadowing the existing ‘pi’ (from the Prelude). > > OK, now let’s look at the new feature. Consider > > g1 :: forall p. T [p] -> blah > > g1 (MkT @a x y) = blah > > > > g2 :: forall p. T [p] -> blah > > g2 (MkT @p x pi) = blah > > > > *Question*: should the variables free in these type arguments be treated > like pattern signatures, or like term variables? > > 1. *Like pattern signatures*. In this design, in g1, ‘a’ is not in > scope, so this brings it into scope, bound to [p]. But in g2, ‘p’ is in > scope, so this is rejected (because MkT is instantiated at [p] not p. > 2. *Like term variables*. In this design, all the variables free in > type patterns are fresh, and brought into scope. In g2, a new ‘p’ is > brought into scope, shadowing the existing ‘p’; indeed the new ‘p’ is bound > to [old_p]. > > The original paper, and hence the accepted proposal, adopts (A). But > Cale likes (B). Indeed John Ericson wrote a Proposal 291: simplify > scoping for type applications in pattens > to advocate > this change. (The proposal is not easy to understand, but advocating (B) > is its payload. > > This is not a terribly big deal, but it would be good to settle it. > > The right place to have debate is on Proposal 291 > . This email is > just to alert you to it, and ask for your opinions. > > Simon > > > _______________________________________________ > 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 Nov 13 16:37:18 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 13 Nov 2020 08:37:18 -0800 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: References: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> <2d6e721dbc94e3457cbb4c866d5bac8912f8dddb.camel@joachim-breitner.de> <010f01759f213e2a-3aa6a574-bb64-4d1d-ad90-8f9d55a6d701-000000@us-east-2.amazonses.com> <45ef1fcc7594311da0eb119dbb189732554c41c9.camel@joachim-breitner.de> <22f9e49e-c8e9-43a3-8421-fc6f3e8ca9a9@www.fastmail.com> Message-ID: Hello, I like the simple process, however I think I'd prefer a bit more discussion in phase 2,when we know the current tallies, and also I think we should give ourselves the option to decide *not* to have GHC2020---it seems odd that this is a proposal that is phrased as "we are definitely going to end up with GHC 2020, we just don't know what's in it :-) -Iavor On Fri, Nov 13, 2020 at 5:41 AM Spiwack, Arnaud wrote: > Joachim puts his opinion quite eloquently and convincingly :-) > > I was initially in favour of one conversation space by proposed extension, > but, at least for the first round this is likely to be overwhelming. At > least, I haven't found or seen, yet, a way to make this manageable. So let > me vote with the majority opinion here. > > Let's see how it goes really, if it doesn't work out how we expected this > time around, we can change the process for the next iteration. > > /Arnaud > > On Tue, Nov 10, 2020 at 8:11 PM Eric Seidel wrote: > >> Thanks Alejandro and Joachim for pushing this forward! >> >> I also suggested a heavier process along the lines of (2) at some point, >> but after reading the proposal and Joachim's argument here, I feel >> comfortable with (1) as well. >> >> Also, I think @AntC2 made a good point about -fglasgow-exts on the PR >> [1]. For the initial round it would be useful to list the extensions >> enabled by -fglasgow-exts as a reference point. >> >> [1]: >> https://github.com/ghc-proposals/ghc-proposals/pull/372#issuecomment-716066900 >> >> On Tue, Nov 10, 2020, at 06:18, Simon Peyton Jones via >> ghc-steering-committee wrote: >> > | Is anyone not in favor of this proposal, or has questions, or shall >> we >> > | declare consensus and merge it? >> > >> > In my message of 4 Nov, I asked for feedback within "a week or two". >> > Let's set a deadline of the end of this week. >> > >> > All: please respond before then, if you want to. >> > >> > I don't think this is terribly controversial, so I'll take silence as >> assent. >> > >> > All this assuming we adopt Alternative 1. >> > >> > Simon >> > >> > | -----Original Message----- >> > | From: ghc-steering-committee < >> ghc-steering-committee-bounces at haskell.org> On >> > | Behalf Of Joachim Breitner >> > | Sent: 09 November 2020 16:28 >> > | To: ghc-steering-committee at haskell.org >> > | Subject: Re: [ghc-steering-committee] GHC 20xx process >> > | >> > | Hi, >> > | >> > | Am Freitag, den 06.11.2020, 19:55 +0000 schrieb Richard Eisenberg: >> > | > This is an effective argument; you've changed my mind. >> > | > >> > | > I'm now in favor of Joachim's simpler process. >> > | >> > | thanks, also for making me get more clarity on this as well. >> > | >> > | Is anyone still preferring Alternative 2, or should we take it off >> the >> > | table? >> > | >> > | Is anyone not in favor of this proposal, or has questions, or shall >> we >> > | declare consensus and merge it? >> > | >> > | >> > | It seems that now is a good time to then actually do the first >> iteration of >> > | the process – the State of Haskell survey data, once out, will be >> fresh, and >> > | we'd be well in time for inclusion in the Spring release of GHC, >> likely 9.1 >> > | (unless the 9.0 delay shifts things around… oh well, let’s just make >> sure we >> > | have GHC2021 defined before or near the start of 2021, not late in >> that year >> > | :-)) >> > | >> > | Cheers, >> > | Joachim >> > | >> > | -- >> > | Joachim Breitner >> > | mail at joachim-breitner.de >> > | >> > | >> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim >> > | - >> > | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com >> %7C125f812494db4225 >> > | >> 0f4808d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63740536191896 >> > | >> 4507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 >> > | >> haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BfuHY7eCNyF5QlP7BfXDrNjxgWhoj%2FGI92S >> > | esCy1gLA%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.haske >> > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- >> > | committee&data=04%7C01%7Csimonpj%40microsoft.com >> %7C125f812494db42250f480 >> > | >> 8d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637405361918974502% >> > | >> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi >> > | >> LCJXVCI6Mn0%3D%7C3000&sdata=TyxdMqz%2FXFY9WYgZKdUHkFSQEvqRMJdoVEajh39JNs >> > | A%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 >> > >> _______________________________________________ >> 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 Fri Nov 13 16:46:55 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 13 Nov 2020 17:46:55 +0100 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: References: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> <2d6e721dbc94e3457cbb4c866d5bac8912f8dddb.camel@joachim-breitner.de> <010f01759f213e2a-3aa6a574-bb64-4d1d-ad90-8f9d55a6d701-000000@us-east-2.amazonses.com> <45ef1fcc7594311da0eb119dbb189732554c41c9.camel@joachim-breitner.de> <22f9e49e-c8e9-43a3-8421-fc6f3e8ca9a9@www.fastmail.com> Message-ID: <883f5639005867e72466a5beb0c8252b868603fe.camel@joachim-breitner.de> Hi, I am not worried; this is a process outline, not a constitution. It’s enough for us to now say “yes, let’s try this” (which implies “if it goes badly, we’ll reconsider”) and just give it a try! We could replace > After these four weeks, the proposal with the current tally gets > accepted by the secretary, and defines GHC20xx with > After these four weeks, the proposal with the current tally gets, > as a whole, voted on by the committee. Is that your intention? Im inclined to be optimistic and hope that the process will lead to a result that does no need another vote. But I also think that if, at that time, you or anyone else on the committee says “hold a moment, this doesn’t feel right, can we have a final vote”, neither or nor the Chairs will deny that wish. As to how much discussion we have in phase two – again noting to worry about now. The mailing list will not be suddenly moderated, and if discussion comes up and turns out to be productive and fruitful, nobody will stop it. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From iavor.diatchki at gmail.com Fri Nov 13 17:10:27 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 13 Nov 2020 09:10:27 -0800 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: <883f5639005867e72466a5beb0c8252b868603fe.camel@joachim-breitner.de> References: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> <2d6e721dbc94e3457cbb4c866d5bac8912f8dddb.camel@joachim-breitner.de> <010f01759f213e2a-3aa6a574-bb64-4d1d-ad90-8f9d55a6d701-000000@us-east-2.amazonses.com> <45ef1fcc7594311da0eb119dbb189732554c41c9.camel@joachim-breitner.de> <22f9e49e-c8e9-43a3-8421-fc6f3e8ca9a9@www.fastmail.com> <883f5639005867e72466a5beb0c8252b868603fe.camel@joachim-breitner.de> Message-ID: Seems reasonable, let's do it! On Fri, Nov 13, 2020 at 8:47 AM Joachim Breitner wrote: > Hi, > > I am not worried; this is a process outline, not a constitution. It’s > enough for us to now say “yes, let’s try this” (which implies “if it > goes badly, we’ll reconsider”) and just give it a try! > > > We could replace > > > After these four weeks, the proposal with the current > tally gets > > accepted by the secretary, and defines GHC20xx > > with > > > > After these four weeks, the proposal with the current tally gets, > > as > a whole, voted on by the committee. > > Is that your intention? > > Im inclined > to be optimistic and hope that the process will lead to a result that > does no need another vote. But I also think that if, at that time, you > or anyone else on the committee says “hold a moment, this doesn’t feel > right, can we have a final vote”, neither or nor the Chairs will deny > that wish. > > > As to how much discussion we have in phase two – again noting to worry > about now. The mailing list will not be suddenly moderated, and if > discussion comes up and turns out to be productive and fruitful, nobody > will stop it. > > > 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 simonpj at microsoft.com Fri Nov 13 21:59:58 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 13 Nov 2020 21:59:58 +0000 Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Delimited continuation primops (#313) In-Reply-To: References: Message-ID: Simon, Charles is right. You were appointed shepherd on 12 Sept, and our guidelines are that the shepherd should make a recommendation within a fortnight, and guide the committee to a conclusion. I guess this fell off your radar. Simon From: Charles Strahan Sent: 13 November 2020 18:36 To: ghc-proposals/ghc-proposals Cc: Simon Peyton Jones ; Mention Subject: Re: [ghc-proposals/ghc-proposals] Delimited continuation primops (#313) Is this awaiting @simonmar's action, or is this pending @lexi-lambda's response to @simonpj (or something else)? ________________________________ I fear unintentionally spamming this list, but I find that the next step isn't obvious to me, so I figured there might be some value for all involved parties in raising the question. While I'm here: I'm very excited about this work! 🙂 — 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 trupill at gmail.com Sat Nov 14 12:21:12 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Sat, 14 Nov 2020 04:21:12 -0800 Subject: [ghc-steering-committee] Is @ a name-space override, or a visibility override? In-Reply-To: References: Message-ID: This might be relevant to this discussion. Richard Eisenberg has opened a proposal to give a “general steering” towards Dependent Haskell, or not. - Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/378 - Reddit: https://www.reddit.com/r/haskell/comments/jtvf06/should_ghc_support_ergonomic_dependent_types/ I think it’s also a place where we all should express our opinion. Alejandro On 13 Nov 2020 at 16:51:58, Iavor Diatchki wrote: > _______________________________________________ > 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 Sat Nov 14 22:11:31 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Sat, 14 Nov 2020 22:11:31 +0000 Subject: [ghc-steering-committee] Is @ a name-space override, or a visibility override? In-Reply-To: References: Message-ID: <010f0175c8d03b28-093c02d6-4c4e-4fb3-90c4-b0322b0dcfb9-000000@us-east-2.amazonses.com> Yes -- apologies for not posting to this list last night, but I was eager to get my proposal out the door while it was topical... and then eager to get to bed once it had. That proposal (https://github.com/ghc-proposals/ghc-proposals/pull/378) is, in a sense, a generalization of this thread (thanks, Arnaud for starting it). To Iavor's email: I think the design you describe makes good sense, but only for a language without dependent types. A language with dependent types could be imagined with "languages above" and "languages below", but I think the "above"/"below" switching would introduce friction with little self-sustaining benefit. By "self-sustaining" there, I mean that a dependently typed language often has no need for different languages above or below, and so making that distinction in a dependently typed language is awkward. However, one could imagine a dependently typed Haskell that retains the distinction, essentially for philosophical backward compatibility. ("Philosophical" because I believe we can design dependent types in Haskell to be fully backward compatible, but it might require a new way of thinking about what phrases in the language mean.) Perhaps even more directly, avoiding a distinction between languages above/below is a key component of what I require in an ergonomic interpretation of dependent types. Keeping the distinction would, unless I'm convinced otherwise, appear un-ergonomic. Richard > On Nov 14, 2020, at 7:21 AM, Alejandro Serrano Mena wrote: > > This might be relevant to this discussion. Richard Eisenberg has opened a proposal to give a “general steering” towards Dependent Haskell, or not. > - Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/378 > - Reddit: https://www.reddit.com/r/haskell/comments/jtvf06/should_ghc_support_ergonomic_dependent_types/ > > I think it’s also a place where we all should express our opinion. > > Alejandro > > On 13 Nov 2020 at 16:51:58, Iavor Diatchki > wrote: > _______________________________________________ > 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 Sun Nov 15 17:19:27 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 15 Nov 2020 18:19:27 +0100 Subject: [ghc-steering-committee] Prelimary GHC extensions stats Message-ID: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> Dear Committee, in hopefully anticipation that we can start the GHC2021 process soon, and also given that the Haskell Survey closes today (so we get that data also soon, I guess), I ran a simple analysis against hackage today. I’ll share the data in a proper way when it's time; this is just a preview into what I have in mind. ## Methodology The methodology is: * For each package on hackage, get the latest version * For each such package, try to read out the extensions used in the cabal file and in the modules (This uses https://github.com/kowainik/extensions) * Aggregate these numbers. Out of 12729 packages fetched (4GB), 12025 could be parsed by the extensions library (if anyone cares about the missing ones, please submit fixes to hat library). Only 1116 specify extensions in the cabal file using default- extensions; the rest uses per-file extensions exclusively. This is a relatively low number, so barring bugs in the analysis code, this means that most developers prefer per-module extensions (I am one of those). I extracted three metrics, all represented as percentages: * Proliferation: #(packages using that extensions)/#(packages parsed) (I’ll reserve the word “Popularity” for the data from the poll.) * Innocuousness #(packages enable it in .cabal)/#(packages using default-extensions) A high number here indicates that many developers want this on by default in their project, across all modules. * Aloofness #(packages using this, but _only_ in modules, despite using default-extensions) /#(packages using default-extensions) A high number here indicates that, although a developer was in principle happy with putting extensions into the default-extensions field, they did not include this particular one. I take this as an indication that this extension does _not_ make a great on-by-default extension. (Matching my expectation, TemplateHaskell and CPP make the highest here) Yes, I went overboard with finding fun names to describe the metrics. Happy to take suggestions for more suitable names, maybe from Richard, our master of sophisticated English vocabulary. ## Source I am using this code: https://github.com/nomeata/ghc-proposals-stats/tree/master/ext-stats The are proof that I am very much capable of writing horrible Haskell code that looks like bad python code. If someone (including anyone outside the committee) feels like contributing better code, talk to me! Besides just prettier code, the tool could understand and be smart about implications between extensions, be clever about extensions that are part of the default-language already, and maybe provide nicer reporting. ## Results Eventually I’ll provide a CSV file with all relevant data (hackage stats and poll results), and maybe even upload it on some suitable web service that allows you to explore such a table easily (suggestions?). For now, a preview of the complete output, sorted by Proliferation: Proliferation | Innocousness | | | Aloofness | | | 0% 0% 0% NoMonoLocalBinds 0% 0% 0% NoRebindableSyntax 0% 0% 0% NoMagicHash 0% 1% 0% RelaxedPolyRec 0% 3% 0% DoAndIfThenElse 0% 4% 0% ForeignFunctionInterface 0% 12% 0% PatternGuards 0% 14% 0% EmptyDataDecls 0% 0% 0% ParallelArrays 0% 0% 0% NoForeignFunctionInterface 0% 0% 0% NoDatatypeContexts 0% 0% 0% TransformListComp 0% 0% 0% InterruptibleFFI 0% 1% 0% MonadFailDesugaring 0% 0% 0% NullaryTypeClasses 0% 0% 0% UnboxedSums 0% 0% 0% CApiFFI 0% 0% 0% StaticPointers 0% 0% 0% DerivingStrategies 0% 1% 0% NamedWildCards 0% 0% 0% GHCForeignImportPrim 0% 0% 0% TemplateHaskellQuotes 0% 0% 0% GADTSyntax 0% 0% 0% JavaScriptFFI 0% 0% 0% PostfixOperators 0% 0% 0% DeriveLift 0% 0% 0% NondecreasingIndentation 0% 0% 0% Strict 0% 1% 0% NumDecimals 0% 0% 0% AutoDeriveTypeable 0% 1% 1% StrictData 0% 0% 0% ConstrainedClassMethods 0% 1% 0% DisambiguateRecordFields 0% 2% 0% NegativeLiterals 0% 2% 0% MonadComprehensions 0% 0% 0% UnliftedFFITypes 0% 2% 0% OverloadedLabels 0% 2% 0% BinaryLiterals 0% 2% 0% ApplicativeDo 0% 1% 0% MonoLocalBinds 0% 0% 1% ExplicitNamespaces 0% 1% 1% TypeFamilyDependencies 0% 0% 1% UndecidableSuperClasses 0% 0% 1% RoleAnnotations 1% 0% 1% ExplicitForAll 1% 0% 1% ExtendedDefaultRules 1% 2% 0% RebindableSyntax 1% 3% 0% EmptyCase 1% 3% 0% PartialTypeSignatures 1% 3% 1% DuplicateRecordFields 1% 2% 1% TypeInType 1% 2% 1% ImpredicativeTypes 1% 2% 0% RecursiveDo 1% 0% 2% ImplicitParams 1% 0% 2% OverloadedLists 1% 0% 1% IncoherentInstances 1% 11% 0% LiberalTypeSynonyms 1% 2% 2% AllowAmbiguousTypes 1% 1% 3% DeriveAnyClass 1% 10% 0% ParallelListComp 2% 2% 1% PackageImports 2% 6% 1% InstanceSigs 2% 11% 0% Arrows 2% 6% 0% UnicodeSyntax 2% 4% 2% PatternSynonyms 2% 6% 3% TypeApplications 2% 0% 2% OverlappingInstances 3% 9% 1% UnboxedTuples 3% 15% 1% MultiWayIf 3% 6% 3% NamedFieldPuns 4% 16% 2% DeriveFoldable 4% 7% 3% PolyKinds 4% 16% 2% DeriveTraversable 4% 10% 3% MagicHash 4% 13% 3% NoMonomorphismRestriction 4% 18% 4% DefaultSignatures 6% 8% 5% ViewPatterns 6% 10% 4% KindSignatures 6% 15% 6% QuasiQuotes 6% 3% 6% ExistentialQuantification 7% 30% 2% NoImplicitPrelude 7% 25% 6% ConstraintKinds 8% 23% 6% DeriveFunctor 8% 22% 6% FunctionalDependencies 9% 24% 6% StandaloneDeriving 9% 24% 6% TupleSections 10% 25% 6% DataKinds 10% 6% 8% TypeSynonymInstances 11% 28% 4% LambdaCase 11% 24% 7% GADTs 12% 27% 5% TypeOperators 12% 6% 15% UndecidableInstances 12% 20% 7% BangPatterns 14% 27% 10% DeriveGeneric 15% 27% 8% RecordWildCards 17% 21% 16% TemplateHaskell 17% 29% 14% GeneralizedNewtypeDeriving 19% 29% 12% RankNTypes 20% 26% 8% DeriveDataTypeable 20% 31% 11% TypeFamilies 21% 34% 11% MultiParamTypeClasses 22% 11% 18% CPP 25% 37% 13% ScopedTypeVariables 26% 42% 14% FlexibleContexts 31% 43% 16% FlexibleInstances 34% 53% 10% OverloadedStrings Enjoy! Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Sun Nov 15 17:27:17 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 15 Nov 2020 18:27:17 +0100 Subject: [ghc-steering-committee] Prelimary GHC extensions stats In-Reply-To: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> References: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> Message-ID: <362a31950ed8df0ab44c4d40324b287f06b3f7a0.camel@joachim-breitner.de> Hi again, Am Sonntag, den 15.11.2020, 18:19 +0100 schrieb Joachim Breitner: > ## Results I just noticed that I was using a hackage copy from 2018. All the prose still applies; the actual stats are a bit outdated… anyways, this way there is more suspense until I can provide the real data :-) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Mon Nov 16 08:24:58 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Nov 2020 08:24:58 +0000 Subject: [ghc-steering-committee] GHC 20xx process In-Reply-To: References: <010f017593b2e260-17f76c5f-9a36-40ce-bf96-2ba242e1c6bc-000000@us-east-2.amazonses.com> <2d6e721dbc94e3457cbb4c866d5bac8912f8dddb.camel@joachim-breitner.de> <010f01759f213e2a-3aa6a574-bb64-4d1d-ad90-8f9d55a6d701-000000@us-east-2.amazonses.com> <45ef1fcc7594311da0eb119dbb189732554c41c9.camel@joachim-breitner.de> Message-ID: I believe that we have a consensus in favour of acceptance, using Alternative 1. Yell if you disagree; but otherwise Joachim you can merge. Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Simon Peyton Jones via ghc-steering- | committee | Sent: 10 November 2020 11:18 | To: Joachim Breitner ; ghc-steering- | committee at haskell.org | Subject: Re: [ghc-steering-committee] GHC 20xx process | | | Is anyone not in favor of this proposal, or has questions, or shall | | we declare consensus and merge it? | | In my message of 4 Nov, I asked for feedback within "a week or two". | Let's set a deadline of the end of this week. | | All: please respond before then, if you want to. | | I don't think this is terribly controversial, so I'll take silence as | assent. | | All this assuming we adopt Alternative 1. | | Simon | | | -----Original Message----- | | From: ghc-steering-committee | | On Behalf Of Joachim | | Breitner | | Sent: 09 November 2020 16:28 | | To: ghc-steering-committee at haskell.org | | Subject: Re: [ghc-steering-committee] GHC 20xx process | | | | Hi, | | | | Am Freitag, den 06.11.2020, 19:55 +0000 schrieb Richard Eisenberg: | | > This is an effective argument; you've changed my mind. | | > | | > I'm now in favor of Joachim's simpler process. | | | | thanks, also for making me get more clarity on this as well. | | | | Is anyone still preferring Alternative 2, or should we take it off | | the table? | | | | Is anyone not in favor of this proposal, or has questions, or shall | | we declare consensus and merge it? | | | | | | It seems that now is a good time to then actually do the first | | iteration of the process – the State of Haskell survey data, once | | out, will be fresh, and we'd be well in time for inclusion in the | | Spring release of GHC, likely 9.1 (unless the 9.0 delay shifts | things | | around… oh well, let’s just make sure we have GHC2021 defined | before | | or near the start of 2021, not late in that year | | :-)) | | | | 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=04%7C01%7Csimonpj%40microsoft.com%7C125f812494 | | db4225 | | | | | 0f4808d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63740536 | | 191896 | | | | | 4507%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT | | iI6Ik1 | | | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2BfuHY7eCNyF5QlP7BfXDrNjxgWhoj%2 | | FGI92S | | esCy1gLA%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 | | .haske | | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | | | | | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C125f812494db422 | | 50f480 | | | 8d884cc8403%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374053619189 | | 74502% | | | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik | | 1haWwi | | | LCJXVCI6Mn0%3D%7C3000&sdata=TyxdMqz%2FXFY9WYgZKdUHkFSQEvqRMJdoVEaj | | h39JNs | | A%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=04%7C01%7Csimonpj%40microsoft.com%7Cdad666bbc166453 | 267e908d8856a5d77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374060 | 39162835972%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=13u0rZfZbxH73XwGeMPI | EjrREiqsY%2BUpnjiC9W20Y7s%3D&reserved=0 From simonpj at microsoft.com Mon Nov 16 08:30:14 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 16 Nov 2020 08:30:14 +0000 Subject: [ghc-steering-committee] We have a nudger! Message-ID: Friends Our GHC proposals process says * A shepherd will make a recommendation within 2 weeks * Committee will make a decision with 4 weeks after that But we sometimes drop the ball and we have no recovery mechanism, which isn't really fair on authors. At our ICFP meeting we decided to appoint a "Nudger" to watch the timetable (weekly perhaps) give the shepherds a polite nudge. If successive nudges don't work (e.g. perhaps a committee member has been overtaken by an emergency) then s/he can alert the Secretary to appoint a new shepherd. I'm happy to say that Tom Harding has agreed to act as our Nudger, for six-month term. Thank you Tom! You may want to check with Joachim about exactly what's in flight. Shepherds: note that it's fine to have an active dialogue with the author about content, before making your recommendation. That might take longer than 2 weeks, but make sure the author knows that is what you are doing. Thanks Tom! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomjharding at live.co.uk Mon Nov 16 09:24:49 2020 From: tomjharding at live.co.uk (Tom Harding) Date: Mon, 16 Nov 2020 09:24:49 +0000 Subject: [ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding In-Reply-To: References: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> Message-ID: <80AC6298-076D-41C2-821B-BE19DA7EBA3D@live.co.uk> Hi everyone, It sounds as though this change isn’t too controversial, and everyone who has voiced an opinion has given some level of agreement. If there are no other thoughts, Joachim, shall I declare this proposal accepted on the thread? Thanks, Tom On 4 Nov 2020, at 15:22, Tom Harding > wrote: Hi all, I’d like to open committee discussion for DuplicateRecordFields without ambiguous field access. Other committee members have already commented, and I’ll say I’m strongly in favour of this proposal. I definitely see the suggestion here as “tidying up” an unintuitive - perhaps even counterintuitive - behaviour. https://github.com/ghc-proposals/ghc-proposals/pull/366 Thanks, Tom PS. Sorry for my recent absence; I think it has been a very strange few months for all us! On 2 Nov 2020, at 09:08, Joachim Breitner > wrote: Dear Committee, this is your secretary speaking: DuplicateRecordFields without ambiguous field access was proposed by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/366 https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst I’ll propose Tom Harding 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 _______________________________________________ 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 Nov 16 10:57:32 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 16 Nov 2020 11:57:32 +0100 Subject: [ghc-steering-committee] Please review #366: DuplicateRecordFields without ambiguous field access, Shepherd: Tom Harding In-Reply-To: <80AC6298-076D-41C2-821B-BE19DA7EBA3D@live.co.uk> References: <837a5539afc7f0580abc54c404c5f986c9618775.camel@joachim-breitner.de> <80AC6298-076D-41C2-821B-BE19DA7EBA3D@live.co.uk> Message-ID: Hi, yes, please do. I can do the actual merging later today, when I do it to the GHC20xx proposal as well. Cheers, Joachim Am Montag, den 16.11.2020, 09:24 +0000 schrieb Tom Harding: > Hi everyone, > > It sounds as though this change isn’t too controversial, and everyone who has voiced an opinion has given some level of agreement. If there are no other thoughts, Joachim, shall I declare this proposal accepted on the thread? > > Thanks, > Tom > > > On 4 Nov 2020, at 15:22, Tom Harding wrote: > > > > Hi all, > > > > I’d like to open committee discussion for DuplicateRecordFields without ambiguous field access. Other committee members have already commented, and I’ll say I’m strongly in favour of this proposal. I definitely see the suggestion here as “tidying up” an unintuitive - perhaps even counterintuitive - behaviour. > > > > https://github.com/ghc-proposals/ghc-proposals/pull/366 > > > > Thanks, > > Tom > > > > PS. Sorry for my recent absence; I think it has been a very strange few months for all us! > > > > > On 2 Nov 2020, at 09:08, Joachim Breitner wrote: > > > > > > Dear Committee, > > > > > > this is your secretary speaking: > > > > > > DuplicateRecordFields without ambiguous field access > > > was proposed by Adam Gundry > > > https://github.com/ghc-proposals/ghc-proposals/pull/366 > > > https://github.com/adamgundry/ghc-proposals/blob/no-ambiguous-selectors/proposals/0000-no-ambiguous-field-access.rst > > > > > > I’ll propose Tom Harding 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 > > > > _______________________________________________ > > 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 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Mon Nov 16 10:58:59 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 16 Nov 2020 11:58:59 +0100 Subject: [ghc-steering-committee] We have a nudger! In-Reply-To: References: Message-ID: Hi, thanks Tom for helping here! I know I have been slacking on that front a bit, overly optimistically hoping that github reminders and the “status” emails suffice… well, they don't. So your support in procedural matters is appreciated! Cheers, Joachim Am Montag, den 16.11.2020, 08:30 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > Friends > Our GHC proposals process says > A shepherd will make a recommendation within 2 weeks > Committee will make a decision with 4 weeks after that > But we sometimes drop the ball and we have no recovery mechanism, which isn’t really fair on authors. > At our ICFP meeting we decided to appoint a "Nudger" to watch the timetable (weekly perhaps) give the shepherds a polite nudge. If successive nudges don't work (e.g. perhaps a committee member has been overtaken by an emergency) then s/he can alert the Secretary to appoint a new shepherd. > I’m happy to say that Tom Harding has agreed to act as our Nudger, for six-month term. Thank you Tom! You may want to check with Joachim about exactly what’s in flight. > Shepherds: note that it’s fine to have an active dialogue with the author about content, before making your recommendation. That might take longer than 2 weeks, but make sure the author knows that is what you are doing. > Thanks Tom! > Simon > _______________________________________________ > 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/ From rae at richarde.dev Mon Nov 16 14:05:08 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 16 Nov 2020 14:05:08 +0000 Subject: [ghc-steering-committee] Prelimary GHC extensions stats In-Reply-To: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> References: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> Message-ID: <010f0175d15fa79d-04bca437-4dbf-4327-ae22-c5162878fcee-000000@us-east-2.amazonses.com> > On Nov 15, 2020, at 12:19 PM, Joachim Breitner wrote: > > Happy to take suggestions for more suitable names, maybe from Richard, > our master of sophisticated English vocabulary. Hmph. And I always consider Simon PJ to be a more erudite logophile than I. But, really, I think Joachim is just parading the fact that he unseated my near-miss at getting "bespoke" to be a keyword in Haskell (instead of the "stock" deriving strategy). Thanks for doing this analysis! Richard From mail at joachim-breitner.de Mon Nov 16 14:15:41 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 16 Nov 2020 15:15:41 +0100 Subject: [ghc-steering-committee] Prelimary GHC extensions stats In-Reply-To: <010f0175d15fa79d-04bca437-4dbf-4327-ae22-c5162878fcee-000000@us-east-2.amazonses.com> References: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> <010f0175d15fa79d-04bca437-4dbf-4327-ae22-c5162878fcee-000000@us-east-2.amazonses.com> Message-ID: <5e534e6aad09b852510a0478850d1361feed7caa.camel@joachim-breitner.de> Hi, Am Montag, den 16.11.2020, 14:05 +0000 schrieb Richard Eisenberg: > > On Nov 15, 2020, at 12:19 PM, Joachim Breitner wrote: > > > > Happy to take suggestions for more suitable names, maybe from Richard, > > our master of sophisticated English vocabulary. > > Hmph. And I always consider Simon PJ to be a more erudite logophile > than I. But, really, I think Joachim is just parading the fact that > he unseated my near-miss at getting "bespoke" to be a keyword in > Haskell (instead of the "stock" deriving strategy). I don’t deny Simon’s logophilia, but whoever calls other logophiles “erudite” is definitely humble bragging. And clearly, while I am very fond of the style of logophilia that brought us gems like “zonking“, the “WizWoz machine” and many others, the criteria names in my original message were a genuine attempt attempt to imitate Richard’s very own style – as as such, be assured that it was most sincere flattery, and not at all parading of past quarrels :-) Ok, might also have been influenced by just finished reading a book by Alan Bradley… Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From eric at seidel.io Mon Nov 16 14:33:56 2020 From: eric at seidel.io (Eric Seidel) Date: Mon, 16 Nov 2020 09:33:56 -0500 Subject: [ghc-steering-committee] Prelimary GHC extensions stats In-Reply-To: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> References: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> Message-ID: <0aaa6cab-bcd6-4442-8b4d-d1dd2878a20e@www.fastmail.com> Thanks for the analysis! We have an extremely long tail of extensions with 0% Proliferation. This is somewhat tangential to the GHC20XX process, but I'm curious how many of these extensions actually have no uses as opposed to being rounded to zero. There might be some opportunities to remove unused extensions that just add to GHC's maintenance burden. On Sun, Nov 15, 2020, at 12:19, Joachim Breitner wrote: > Dear Committee, > > in hopefully anticipation that we can start the GHC2021 process soon, > and also given that the Haskell Survey closes today (so we get that > data also soon, I guess), I ran a simple analysis against hackage > today. I’ll share the data in a proper way when it's time; this is just > a preview into what I have in mind. > > ## Methodology > > The methodology is: > > * For each package on hackage, get the latest version > * For each such package, try to read out the extensions used > in the cabal file and in the modules > (This uses https://github.com/kowainik/extensions) > * Aggregate these numbers. > > > Out of 12729 packages fetched (4GB), 12025 could be parsed by the > extensions library (if anyone cares about the missing ones, please > submit fixes to hat library). > > Only 1116 specify extensions in the cabal file using default- > extensions; the rest uses per-file extensions exclusively. This is a > relatively low number, so barring bugs in the analysis code, this means > that most developers prefer per-module extensions (I am one of those). > > I extracted three metrics, all represented as percentages: > > * Proliferation: > #(packages using that extensions)/#(packages parsed) > > (I’ll reserve the word “Popularity” for the data from the poll.) > > * Innocuousness > #(packages enable it in .cabal)/#(packages using default-extensions) > > A high number here indicates that many developers want this on by > default in their project, across all modules. > > * Aloofness > #(packages using this, but _only_ in modules, despite using > default-extensions) > /#(packages using default-extensions) > > A high number here indicates that, although a developer was in > principle happy with putting extensions into the default-extensions > field, they did not include this particular one. I take this as an > indication that this extension does _not_ make a great on-by-default > extension. (Matching my expectation, TemplateHaskell and CPP make > the highest here) > > Yes, I went overboard with finding fun names to describe the metrics. > Happy to take suggestions for more suitable names, maybe from Richard, > our master of sophisticated English vocabulary. > > > ## Source > > I am using this code: > > https://github.com/nomeata/ghc-proposals-stats/tree/master/ext-stats > > The are proof that I am very much capable of writing horrible Haskell > code that looks like bad python code. > > If someone (including anyone > outside the committee) feels like contributing better code, talk to me! > Besides just prettier code, the tool could understand and be smart > about implications between extensions, be clever about extensions that > are part of the default-language already, and maybe provide nicer > reporting. > > ## Results > > Eventually I’ll provide a CSV file with all relevant data (hackage > stats and poll results), and maybe even upload it on some suitable web > service that allows you to explore such a table easily (suggestions?). > > For now, a preview of the complete output, sorted by Proliferation: > > Proliferation > | Innocousness > | | | Aloofness > | | | > 0% 0% 0% NoMonoLocalBinds > 0% 0% 0% NoRebindableSyntax > 0% 0% 0% NoMagicHash > 0% 1% 0% RelaxedPolyRec > 0% 3% 0% DoAndIfThenElse > 0% 4% 0% ForeignFunctionInterface > 0% 12% 0% PatternGuards > 0% 14% 0% EmptyDataDecls > 0% 0% 0% ParallelArrays > 0% 0% 0% NoForeignFunctionInterface > 0% 0% 0% NoDatatypeContexts > 0% 0% 0% TransformListComp > 0% 0% 0% InterruptibleFFI > 0% 1% 0% MonadFailDesugaring > 0% 0% 0% NullaryTypeClasses > 0% 0% 0% UnboxedSums > 0% 0% 0% CApiFFI > 0% 0% 0% StaticPointers > 0% 0% 0% DerivingStrategies > 0% 1% 0% NamedWildCards > 0% 0% 0% GHCForeignImportPrim > 0% 0% 0% TemplateHaskellQuotes > 0% 0% 0% GADTSyntax > 0% 0% 0% JavaScriptFFI > 0% 0% 0% PostfixOperators > 0% 0% 0% DeriveLift > 0% 0% 0% NondecreasingIndentation > 0% 0% 0% Strict > 0% 1% 0% NumDecimals > 0% 0% 0% AutoDeriveTypeable > 0% 1% 1% StrictData > 0% 0% 0% ConstrainedClassMethods > 0% 1% 0% DisambiguateRecordFields > 0% 2% 0% NegativeLiterals > 0% 2% 0% MonadComprehensions > 0% 0% 0% UnliftedFFITypes > 0% 2% 0% OverloadedLabels > 0% 2% 0% BinaryLiterals > 0% 2% 0% ApplicativeDo > 0% 1% 0% MonoLocalBinds > 0% 0% 1% ExplicitNamespaces > 0% 1% 1% TypeFamilyDependencies > 0% 0% 1% UndecidableSuperClasses > 0% 0% 1% RoleAnnotations > 1% 0% 1% ExplicitForAll > 1% 0% 1% ExtendedDefaultRules > 1% 2% 0% RebindableSyntax > 1% 3% 0% EmptyCase > 1% 3% 0% PartialTypeSignatures > 1% 3% 1% DuplicateRecordFields > 1% 2% 1% TypeInType > 1% 2% 1% ImpredicativeTypes > 1% 2% 0% RecursiveDo > 1% 0% 2% ImplicitParams > 1% 0% 2% OverloadedLists > 1% 0% 1% IncoherentInstances > 1% 11% 0% LiberalTypeSynonyms > 1% 2% 2% AllowAmbiguousTypes > 1% 1% 3% DeriveAnyClass > 1% 10% 0% ParallelListComp > 2% 2% 1% PackageImports > 2% 6% 1% InstanceSigs > 2% 11% 0% Arrows > 2% 6% 0% UnicodeSyntax > 2% 4% 2% PatternSynonyms > 2% 6% 3% TypeApplications > 2% 0% 2% OverlappingInstances > 3% 9% 1% UnboxedTuples > 3% 15% 1% MultiWayIf > 3% 6% 3% NamedFieldPuns > 4% 16% 2% DeriveFoldable > 4% 7% 3% PolyKinds > 4% 16% 2% DeriveTraversable > 4% 10% 3% MagicHash > 4% 13% 3% NoMonomorphismRestriction > 4% 18% 4% DefaultSignatures > 6% 8% 5% ViewPatterns > 6% 10% 4% KindSignatures > 6% 15% 6% QuasiQuotes > 6% 3% 6% ExistentialQuantification > 7% 30% 2% NoImplicitPrelude > 7% 25% 6% ConstraintKinds > 8% 23% 6% DeriveFunctor > 8% 22% 6% FunctionalDependencies > 9% 24% 6% StandaloneDeriving > 9% 24% 6% TupleSections > 10% 25% 6% DataKinds > 10% 6% 8% TypeSynonymInstances > 11% 28% 4% LambdaCase > 11% 24% 7% GADTs > 12% 27% 5% TypeOperators > 12% 6% 15% UndecidableInstances > 12% 20% 7% BangPatterns > 14% 27% 10% DeriveGeneric > 15% 27% 8% RecordWildCards > 17% 21% 16% TemplateHaskell > 17% 29% 14% GeneralizedNewtypeDeriving > 19% 29% 12% RankNTypes > 20% 26% 8% DeriveDataTypeable > 20% 31% 11% TypeFamilies > 21% 34% 11% MultiParamTypeClasses > 22% 11% 18% CPP > 25% 37% 13% ScopedTypeVariables > 26% 42% 14% FlexibleContexts > 31% 43% 16% FlexibleInstances > 34% 53% 10% OverloadedStrings > > Enjoy! > 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 mail at joachim-breitner.de Mon Nov 16 14:49:15 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 16 Nov 2020 15:49:15 +0100 Subject: [ghc-steering-committee] Prelimary GHC extensions stats In-Reply-To: <0aaa6cab-bcd6-4442-8b4d-d1dd2878a20e@www.fastmail.com> References: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> <0aaa6cab-bcd6-4442-8b4d-d1dd2878a20e@www.fastmail.com> Message-ID: Hi, I believe the way this script works, extensions with literally no use would not even show up. So all these are used somewhere. Cheers, Joachim Am Montag, den 16.11.2020, 09:33 -0500 schrieb Eric Seidel: > Thanks for the analysis! > > We have an extremely long tail of extensions with 0% Proliferation. This is somewhat tangential to the GHC20XX process, but I'm curious how many of these extensions actually have no uses as opposed to being rounded to zero. There might be some opportunities to remove unused extensions that just add to GHC's maintenance burden. > > On Sun, Nov 15, 2020, at 12:19, Joachim Breitner wrote: > > Dear Committee, > > > > in hopefully anticipation that we can start the GHC2021 process soon, > > and also given that the Haskell Survey closes today (so we get that > > data also soon, I guess), I ran a simple analysis against hackage > > today. I’ll share the data in a proper way when it's time; this is just > > a preview into what I have in mind. > > > > ## Methodology > > > > The methodology is: > > > > * For each package on hackage, get the latest version > > * For each such package, try to read out the extensions used > > in the cabal file and in the modules > > (This uses https://github.com/kowainik/extensions) > > * Aggregate these numbers. > > > > > > Out of 12729 packages fetched (4GB), 12025 could be parsed by the > > extensions library (if anyone cares about the missing ones, please > > submit fixes to hat library). > > > > Only 1116 specify extensions in the cabal file using default- > > extensions; the rest uses per-file extensions exclusively. This is a > > relatively low number, so barring bugs in the analysis code, this means > > that most developers prefer per-module extensions (I am one of those). > > > > I extracted three metrics, all represented as percentages: > > > > * Proliferation: > > #(packages using that extensions)/#(packages parsed) > > > > (I’ll reserve the word “Popularity” for the data from the poll.) > > > > * Innocuousness > > #(packages enable it in .cabal)/#(packages using default-extensions) > > > > A high number here indicates that many developers want this on by > > default in their project, across all modules. > > > > * Aloofness > > #(packages using this, but _only_ in modules, despite using > > default-extensions) > > /#(packages using default-extensions) > > > > A high number here indicates that, although a developer was in > > principle happy with putting extensions into the default-extensions > > field, they did not include this particular one. I take this as an > > indication that this extension does _not_ make a great on-by-default > > extension. (Matching my expectation, TemplateHaskell and CPP make > > the highest here) > > > > Yes, I went overboard with finding fun names to describe the metrics. > > Happy to take suggestions for more suitable names, maybe from Richard, > > our master of sophisticated English vocabulary. > > > > > > ## Source > > > > I am using this code: > > > > https://github.com/nomeata/ghc-proposals-stats/tree/master/ext-stats > > > > The are proof that I am very much capable of writing horrible Haskell > > code that looks like bad python code. > > > > If someone (including anyone > > outside the committee) feels like contributing better code, talk to me! > > Besides just prettier code, the tool could understand and be smart > > about implications between extensions, be clever about extensions that > > are part of the default-language already, and maybe provide nicer > > reporting. > > > > ## Results > > > > Eventually I’ll provide a CSV file with all relevant data (hackage > > stats and poll results), and maybe even upload it on some suitable web > > service that allows you to explore such a table easily (suggestions?). > > > > For now, a preview of the complete output, sorted by Proliferation: > > > > Proliferation > > | Innocousness > > | | | Aloofness > > | | | > > 0% 0% 0% NoMonoLocalBinds > > 0% 0% 0% NoRebindableSyntax > > 0% 0% 0% NoMagicHash > > 0% 1% 0% RelaxedPolyRec > > 0% 3% 0% DoAndIfThenElse > > 0% 4% 0% ForeignFunctionInterface > > 0% 12% 0% PatternGuards > > 0% 14% 0% EmptyDataDecls > > 0% 0% 0% ParallelArrays > > 0% 0% 0% NoForeignFunctionInterface > > 0% 0% 0% NoDatatypeContexts > > 0% 0% 0% TransformListComp > > 0% 0% 0% InterruptibleFFI > > 0% 1% 0% MonadFailDesugaring > > 0% 0% 0% NullaryTypeClasses > > 0% 0% 0% UnboxedSums > > 0% 0% 0% CApiFFI > > 0% 0% 0% StaticPointers > > 0% 0% 0% DerivingStrategies > > 0% 1% 0% NamedWildCards > > 0% 0% 0% GHCForeignImportPrim > > 0% 0% 0% TemplateHaskellQuotes > > 0% 0% 0% GADTSyntax > > 0% 0% 0% JavaScriptFFI > > 0% 0% 0% PostfixOperators > > 0% 0% 0% DeriveLift > > 0% 0% 0% NondecreasingIndentation > > 0% 0% 0% Strict > > 0% 1% 0% NumDecimals > > 0% 0% 0% AutoDeriveTypeable > > 0% 1% 1% StrictData > > 0% 0% 0% ConstrainedClassMethods > > 0% 1% 0% DisambiguateRecordFields > > 0% 2% 0% NegativeLiterals > > 0% 2% 0% MonadComprehensions > > 0% 0% 0% UnliftedFFITypes > > 0% 2% 0% OverloadedLabels > > 0% 2% 0% BinaryLiterals > > 0% 2% 0% ApplicativeDo > > 0% 1% 0% MonoLocalBinds > > 0% 0% 1% ExplicitNamespaces > > 0% 1% 1% TypeFamilyDependencies > > 0% 0% 1% UndecidableSuperClasses > > 0% 0% 1% RoleAnnotations > > 1% 0% 1% ExplicitForAll > > 1% 0% 1% ExtendedDefaultRules > > 1% 2% 0% RebindableSyntax > > 1% 3% 0% EmptyCase > > 1% 3% 0% PartialTypeSignatures > > 1% 3% 1% DuplicateRecordFields > > 1% 2% 1% TypeInType > > 1% 2% 1% ImpredicativeTypes > > 1% 2% 0% RecursiveDo > > 1% 0% 2% ImplicitParams > > 1% 0% 2% OverloadedLists > > 1% 0% 1% IncoherentInstances > > 1% 11% 0% LiberalTypeSynonyms > > 1% 2% 2% AllowAmbiguousTypes > > 1% 1% 3% DeriveAnyClass > > 1% 10% 0% ParallelListComp > > 2% 2% 1% PackageImports > > 2% 6% 1% InstanceSigs > > 2% 11% 0% Arrows > > 2% 6% 0% UnicodeSyntax > > 2% 4% 2% PatternSynonyms > > 2% 6% 3% TypeApplications > > 2% 0% 2% OverlappingInstances > > 3% 9% 1% UnboxedTuples > > 3% 15% 1% MultiWayIf > > 3% 6% 3% NamedFieldPuns > > 4% 16% 2% DeriveFoldable > > 4% 7% 3% PolyKinds > > 4% 16% 2% DeriveTraversable > > 4% 10% 3% MagicHash > > 4% 13% 3% NoMonomorphismRestriction > > 4% 18% 4% DefaultSignatures > > 6% 8% 5% ViewPatterns > > 6% 10% 4% KindSignatures > > 6% 15% 6% QuasiQuotes > > 6% 3% 6% ExistentialQuantification > > 7% 30% 2% NoImplicitPrelude > > 7% 25% 6% ConstraintKinds > > 8% 23% 6% DeriveFunctor > > 8% 22% 6% FunctionalDependencies > > 9% 24% 6% StandaloneDeriving > > 9% 24% 6% TupleSections > > 10% 25% 6% DataKinds > > 10% 6% 8% TypeSynonymInstances > > 11% 28% 4% LambdaCase > > 11% 24% 7% GADTs > > 12% 27% 5% TypeOperators > > 12% 6% 15% UndecidableInstances > > 12% 20% 7% BangPatterns > > 14% 27% 10% DeriveGeneric > > 15% 27% 8% RecordWildCards > > 17% 21% 16% TemplateHaskell > > 17% 29% 14% GeneralizedNewtypeDeriving > > 19% 29% 12% RankNTypes > > 20% 26% 8% DeriveDataTypeable > > 20% 31% 11% TypeFamilies > > 21% 34% 11% MultiParamTypeClasses > > 22% 11% 18% CPP > > 25% 37% 13% ScopedTypeVariables > > 26% 42% 14% FlexibleContexts > > 31% 43% 16% FlexibleInstances > > 34% 53% 10% OverloadedStrings > > > > Enjoy! > > 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 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From rae at richarde.dev Mon Nov 16 21:37:43 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 16 Nov 2020 21:37:43 +0000 Subject: [ghc-steering-committee] Type applications in patterns In-Reply-To: References: Message-ID: <010f0175d2fe0365-a8672e6c-d2ad-4776-b72e-e808126deef9-000000@us-east-2.amazonses.com> This thread was one of the reasons I posted https://github.com/ghc-proposals/ghc-proposals/pull/378, which advocates for accepting #291 (again, with significant changes to clarify the text). I thus think that the better choice would be "(B) like term variables", as I hope for there not to be a distinction between types and terms in the future. I admit that (B) is less expressive than (A) and would welcome a proposal allowing for parameterized patterns that can take inputs as well as producing outputs -- among both terms and types. Richard > On Nov 13, 2020, at 11:10 AM, Iavor Diatchki wrote: > > Hello Simon, > > I think that the consistent choice would be "(A) like pattern signatures". I think this would ensure that all types in patterns handle variables in the same way. It would be confusing to me if the following two examples ended up doing different things: > > h1 (Nothing :: Maybe [p]) = ... > h2 (Nothing @[p]) = ... > > -Iavor > > > > On Fri, Nov 13, 2020 at 3:30 AM Simon Peyton Jones via ghc-steering-committee > wrote: > Dear Steering Committee > > You may remember that we approved the Type Applications in Patterns proposal, some time ago. Cale has been implementing it (see ticket 11350 and MR 2464 ). It’s nearly done. > > But in doing so, one design choice came up that we did not discuss much, and I’d like to consult you. > > Consider first the existing pattern-signature mechanism (not the new feature): > > data T a where > > MkT :: forall a b. a -> b -> T a > > > > f1 :: forall p. T [p] -> blah > > f1 (MkT (x :: a) pi) = blah > > > > f2 :: forall p. T [p] -> blah > > f2 (MkT (x :: p) pi) = blah > > In f1, the pattern (x :: a) brings ‘a’ into scope, binding it to the type [p]. But in f2, since p is already in scope, the pattern (x :: p) does not bring anything new into scope. Instead it requires that x have type p, but actually it has type [p], so f2 is rejected. > > Notice that a pattern signature brings a new variable into scope only if it isn’t already in scope. Notice how this differs from the treatment of term variables; the ‘pi’ in the pattern brings ‘pi’ into scope unconditionally, shadowing the existing ‘pi’ (from the Prelude). > > OK, now let’s look at the new feature. Consider > > g1 :: forall p. T [p] -> blah > > g1 (MkT @a x y) = blah > > > > g2 :: forall p. T [p] -> blah > > g2 (MkT @p x pi) = blah > > > > Question: should the variables free in these type arguments be treated like pattern signatures, or like term variables? > > Like pattern signatures. In this design, in g1, ‘a’ is not in scope, so this brings it into scope, bound to [p]. But in g2, ‘p’ is in scope, so this is rejected (because MkT is instantiated at [p] not p. > Like term variables. In this design, all the variables free in type patterns are fresh, and brought into scope. In g2, a new ‘p’ is brought into scope, shadowing the existing ‘p’; indeed the new ‘p’ is bound to [old_p]. > The original paper, and hence the accepted proposal, adopts (A). But Cale likes (B). Indeed John Ericson wrote a Proposal 291: simplify scoping for type applications in pattens to advocate this change. (The proposal is not easy to understand, but advocating (B) is its payload. > > This is not a terribly big deal, but it would be good to settle it. > > The right place to have debate is on Proposal 291 . This email is just to alert you to it, and ask for your opinions. > > Simon > > > > _______________________________________________ > 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 eric at seidel.io Tue Nov 17 00:41:40 2020 From: eric at seidel.io (Eric Seidel) Date: Mon, 16 Nov 2020 19:41:40 -0500 Subject: [ghc-steering-committee] Type applications in patterns In-Reply-To: <010f0175d2fe0365-a8672e6c-d2ad-4776-b72e-e808126deef9-000000@us-east-2.amazonses.com> References: <010f0175d2fe0365-a8672e6c-d2ad-4776-b72e-e808126deef9-000000@us-east-2.amazonses.com> Message-ID: Like I said in the discussion, I find it a bit strange to treat @ as an explicit binder as part of a data pattern period. The type should be bound as an earlier standalone pattern, where the signature dictates it should appear. I guess you would respond that in the world of dependent types it's natural to think of the type parameters as being just as much part of the scrutinee as the value parameters, but this still feels.. off to me somehow. I think one reason is that case analysis is a runtime thing and types are erased, so why are we binding parameters that aren't actually there at runtime and can't be relevant? But more importantly, the way we use type parameters is different from how we use value parameters, even in a dependently-typed setting. Values we bind and compute on, exclusively. But types are also used to guide type checking, and we lose some of our ability to do that with option (B). Maybe doing this in patterns is not all that useful in practice, but it is pretty deeply ingrained into my mental model of how types behave in Haskell. There is another option for unifying the behavior of type and value parameters in patterns, make values more like types. That is, allow repeated occurrences of term variables in patterns, with the semantics that the pattern only matches if the values are the same. This could be implemented as a trivial desugaring f x x = e ~> f x x' | x == x' = e and it would give the surface language a nice extra declarative feeling. On Mon, Nov 16, 2020, at 16:37, Richard Eisenberg wrote: > This thread was one of the reasons I posted > https://github.com/ghc-proposals/ghc-proposals/pull/378, which > advocates for accepting #291 (again, with significant changes to > clarify the text). > > I thus think that the better choice would be "(B) like term variables", > as I hope for there not to be a distinction between types and terms in > the future. > > I admit that (B) is less expressive than (A) and would welcome a > proposal allowing for parameterized patterns that can take inputs as > well as producing outputs -- among both terms and types. > > Richard > > > On Nov 13, 2020, at 11:10 AM, Iavor Diatchki wrote: > > > > Hello Simon, > > > > I think that the consistent choice would be "(A) like pattern signatures". I think this would ensure that all types in patterns handle variables in the same way. It would be confusing to me if the following two examples ended up doing different things: > > > > h1 (Nothing :: Maybe [p]) = ... > > h2 (Nothing @[p]) = ... > > > > -Iavor > > > > > > > > On Fri, Nov 13, 2020 at 3:30 AM Simon Peyton Jones via ghc-steering-committee wrote: > >> Dear Steering Committee____ > > >> You may remember that we approved the Type Applications in Patterns proposal, some time ago. Cale has been implementing it (see ticket 11350 and MR 2464 ). It’s nearly done.____ > > >> But in doing so, one design choice came up that we did not discuss much, and I’d like to consult you.____ > > >> Consider first the *existing* pattern-signature mechanism (not the new feature):____ > > >> data T a where____ > > >> MkT :: forall a b. a -> b -> T a____ > > >> __ __ > > >> f1 :: forall p. T [p] -> blah____ > > >> f1 (MkT (x :: a) pi) = blah____ > > >> __ __ > > >> f2 :: forall p. T [p] -> blah____ > > >> f2 (MkT (x :: p) pi) = blah____ > > >> In f1, the pattern (x :: a) brings ‘a’ into scope, binding it to the type [p]. But in f2, since p is already in scope, the pattern (x :: p) does not bring anything new into scope. Instead it requires that x have type p, but actually it has type [p], so f2 is rejected.____ > > >> Notice that a pattern signature brings a new variable into scope only if it isn’t already in scope. Notice how this differs from the treatment of term variables; the ‘pi’ in the pattern brings ‘pi’ into scope unconditionally, shadowing the existing ‘pi’ (from the Prelude).____ > > >> OK, now let’s look at the new feature. Consider____ > > >> g1 :: forall p. T [p] -> blah____ > > >> g1 (MkT @a x y) = blah____ > > >> __ __ > > >> g2 :: forall p. T [p] -> blah____ > > >> g2 (MkT @p x pi) = blah____ > > >> __ __ > > >> *Question*: should the variables free in these type arguments be treated like pattern signatures, or like term variables?____ > > >> 1. *Like pattern signatures*. In this design, in g1, ‘a’ is not in scope, so this brings it into scope, bound to [p]. But in g2, ‘p’ is in scope, so this is rejected (because MkT is instantiated at [p] not p.____ > >> 2. *Like term variables*. In this design, all the variables free in type patterns are fresh, and brought into scope. In g2, a new ‘p’ is brought into scope, shadowing the existing ‘p’; indeed the new ‘p’ is bound to [old_p].____ > >> The original paper, and hence the accepted proposal, adopts (A). But Cale likes (B). Indeed John Ericson wrote a Proposal 291: simplify scoping for type applications in pattens to advocate this change. (The proposal is not easy to understand, but advocating (B) is its payload.____ > > >> This is not a terribly big deal, but it would be good to settle it. ____ > > >> The right place to have debate is on Proposal 291 . This email is just to alert you to it, and ask for your opinions.____ > > >> Simon____ > > >> __ __ > > >> _______________________________________________ > >> 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 > From marlowsd at gmail.com Tue Nov 17 16:09:22 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 17 Nov 2020 16:09:22 +0000 Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Delimited continuation primops (#313) In-Reply-To: References: Message-ID: Yes, sorry - will get to this soon. Simon On Fri, 13 Nov 2020 at 22:00, Simon Peyton Jones via ghc-steering-committee wrote: > Simon, > > > > Charles is right. You were appointed shepherd on 12 Sept, and our > guidelines are that the shepherd should make a recommendation within a > fortnight, and guide the committee to a conclusion. I guess this fell off > your radar. > > > > Simon > > > > *From:* Charles Strahan > *Sent:* 13 November 2020 18:36 > *To:* ghc-proposals/ghc-proposals > *Cc:* Simon Peyton Jones ; Mention < > mention at noreply.github.com> > *Subject:* Re: [ghc-proposals/ghc-proposals] Delimited continuation > primops (#313) > > > > Is this awaiting @simonmar > 's > action, or is this pending @lexi-lambda > 's > response to @simonpj > > (or something else)? > ------------------------------ > > I fear unintentionally spamming this list, but I find that the next step > isn't obvious to me, so I figured there might be some value for all > involved parties in raising the question. > > While I'm here: I'm very excited about this work! 🙂 > > — > 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 Thu Nov 19 09:16:01 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 19 Nov 2020 10:16:01 +0100 Subject: [ghc-steering-committee] Prelimary GHC extensions stats In-Reply-To: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> References: <4328d200250633cdf27b64b77b4ec0f948287fcd.camel@joachim-breitner.de> Message-ID: <82fcc2d382d056b80ffcb10db250cefc0278532c.camel@joachim-breitner.de> Hi, Am Sonntag, den 15.11.2020, 18:19 +0100 schrieb Joachim Breitner: > in hopefully anticipation that we can start the GHC2021 process soon, > and also given that the Haskell Survey closes today (so we get that > data also soon, I guess) for those of us who are as eager as I am to use the momentum here: I expect the survey data on the weekend. Then I’ll get the data into a presentable form, and start the process here. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Fri Nov 20 14:54:36 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 20 Nov 2020 15:54:36 +0100 Subject: [ghc-steering-committee] Please review #242: Unsaturated type families, Shepherd: Richard Eisenberg Message-ID: Dear Committee, this is your secretary speaking: Unsaturated type families has been proposed by Richard Eisenberg https://github.com/ghc-proposals/ghc-proposals/pull/242 https://github.com/kcsongor/ghc-proposals/blob/unsaturated-type-families/proposals/0000-unsaturated-type-families.rst I’ll propose Richard Eisenberg as the shepherd, as he has looked at i t in detail already. 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/ From rae at richarde.dev Fri Nov 20 18:43:52 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 20 Nov 2020 18:43:52 +0000 Subject: [ghc-steering-committee] Please review #242: Unsaturated type families, Shepherd: Richard Eisenberg In-Reply-To: References: Message-ID: <010f0175e6f846aa-614cd989-d837-4d18-8813-d87f3ff5fbc0-000000@us-east-2.amazonses.com> Just to clarify: this is proposed by Csongor Kiss, not Richard Eisenberg. :) Happy to shepherd. Expect a recommendation soon. Richard > On Nov 20, 2020, at 9:54 AM, Joachim Breitner wrote: > > Dear Committee, > > this is your secretary speaking: > > Unsaturated type families > has been proposed by Richard Eisenberg > https://github.com/ghc-proposals/ghc-proposals/pull/242 > https://github.com/kcsongor/ghc-proposals/blob/unsaturated-type-families/proposals/0000-unsaturated-type-families.rst > > I’ll propose Richard Eisenberg as the shepherd, as he has looked at i > t in detail already. > > 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 From rae at richarde.dev Fri Nov 20 19:36:12 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 20 Nov 2020 19:36:12 +0000 Subject: [ghc-steering-committee] Unsaturated type families (#242) Message-ID: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com> Hi committee, Csongor Kiss has proposed -XUnsaturatedTypeFamilies. Proposal: https://github.com/kcsongor/ghc-proposals/blob/unsaturated-type-families/proposals/0000-unsaturated-type-families.rst ICFP'19 paper: https://www.microsoft.com/en-us/research/uploads/prod/2019/03/unsaturated-type-families-icfp-2019.pdf Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/242 The central idea is to allow type functions (both type families and type synonyms) to appear unsaturated. (Currently, all type functions are required syntactically to be applied to all parameters they are declared with.) This poses a problem for type inference, as detailed in both the proposal and the paper. The key question: if we have (f a ~ g b), can we conclude (f ~ g) and (a ~ b)? Not if either of f or g is a type function. This proposal thus describes a mechanism to introduce a new flavor of arrow, such that we can identify type functions by their kind. Specifically, we have regular types like Maybe :: Type -> @M Type (where the M stands for "matchable"), but type functions like F :: Type -> @U Type (where the U stands for "unmatchable"). Unmatchable applications can not be decomposed during type inference. Much of the proposal is concerned with backward-compatibility: most users will not want to write @M or @U after each of their arrows, so the proposal describes ways of defaulting this behavior to match (most) programmers' expectations. The proposal also includes matchability polymorphism, the ability to abstract over a matchability parameter. Pros: + This proposal greatly increases the expressiveness of Haskell's type system. + With this proposal, we can finally do proper functional programming in types, rather than just in terms. + This proposal is a key ingredient toward having dependent types, as unsaturated functions are commonplace in terms, and thus should also be supported in types. (Allowing unsaturated functions in types was a key difference between Adam Gundry's proposal for dependent types https://adam.gundry.co.uk/pub/thesis/, which requires a notion of a subset of the type and term languages shared in common, and mine, which makes no distinction between terms and types.) + There is a prototype implementation. + The ideas are backed up by peer-reviewed research. + Despite focusing on type families, this work applies equally to ordinary functions which might be used in types once we have stronger support for dependent types. Cons: - This adds a new dimension of complexity to our kind system, by separating out matchable and unmatchable arrows. - The rules for defaulting appear convenient in practice, but are somewhat arbitrary. - The rules for defaulting care about context -- does an arrow appear in the type of a term or the type of a type? These rules thus go against the spirit of #378, which advocates for not accepting features that distinguish between types and terms. Recommendation: With reservations, I recommend acceptance. I think that the power to use higher-order programming should not be restricted to terms, and allowing unsaturated functions at compile time is necessary in order to have convenient dependent types. However, I am concerned about the extra complexity of matchability. A key open question for me is how much matchability is apparent to users -- even ones using some higher-order type-level programming. If matchability is pervasive, then I would lean against. But my expectation is that matchability fades into the background -- much like levity polymorphism (unless you want it). Open question: What to do about syntax? The proposed syntax is sensible. However, #370 suggests an alternative syntax that might be more forward-thinking. Richard From mail at joachim-breitner.de Sat Nov 21 09:07:18 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 21 Nov 2020 10:07:18 +0100 Subject: [ghc-steering-committee] Please review #370: Syntax for Modifiers, Shepherd: Alejandro Message-ID: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: A syntax for modifiers has been proposed by Richard Eisenberg (this time it’s true) https://github.com/ghc-proposals/ghc-proposals/pull/370 https://dfinity.slack.com/archives/C01BJ73A893/p1605922403340800?thread_ts=1605913774.336600&cid=C01BJ73A893 I’ll propose Alejandro as the shepherd, as he has looked at i t in detail already. 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/ From mail at joachim-breitner.de Sat Nov 21 09:10:30 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 21 Nov 2020 10:10:30 +0100 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: References: Message-ID: <524f6d6dcb187207c6a2534fea6e458b3e74af2f.camel@joachim-breitner.de> Dear Committee, Iavor suggested to reject this proposal, but we have not heard a lot here yet. Especially before rejecting proposals, we probably owe a careful analysis, possibly with suggestions of ways forward (splitting the proposal into smaller pieces maybe? Iavor says there are many changes there). If we have continued silence, we’d reject. Cheers, Joachim Am Mittwoch, den 11.11.2020, 13:41 -0800 schrieb Iavor Diatchki: > Hello, > > Proposal #281 has been submitted for review by the committee again, please read through it and let's have a discussion. Here are links to the proposal's discussion section, and the proposal text: > > https://github.com/ghc-proposals/ghc-proposals/pull/281 > https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst > > While I suggested acceptance on the previous version, I am leaning towards rejecting the proposal now. My reasoning is that I hadn't fully understood all the aspects of the original proposal, and the new proposal seems to lack a simple modular specification. There are *many* changes described in the document, but I found it hard to understand what is the current design, from the point of view of a user of the feature, as opposed to someone trying to implement it. > > I'd be curious about what others think. > > -Iavor > > > _______________________________________________ > 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/ From trupill at gmail.com Sun Nov 22 17:09:43 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Sun, 22 Nov 2020 18:09:43 +0100 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: <524f6d6dcb187207c6a2534fea6e458b3e74af2f.camel@joachim-breitner.de> References: <524f6d6dcb187207c6a2534fea6e458b3e74af2f.camel@joachim-breitner.de> Message-ID: Hi all, For me, there are two main concerns here: 1. This could be split on different proposals: (1) using the “forall a ->” syntax, (2) conflating the type and term syntax and namespaces, (3) introducing checking and inference for it; 2. I find the claim that you can just take the Quick Look Impredicativity paper, make a couple of adjustments, and get correct checking and inference. This kind of big change is the one for which I would actually expect a peer-reviewed paper. Regards, Alejandro El El sáb, 21 nov 2020 a las 10:10, Joachim Breitner < mail at joachim-breitner.de> escribió: > Dear Committee, > > Iavor suggested to reject this proposal, but we have not heard a lot > here yet. Especially before rejecting proposals, we probably owe a > careful analysis, possibly with suggestions of ways forward (splitting > the proposal into smaller pieces maybe? Iavor says there are many > changes there). > > If we have continued silence, we’d reject. > > Cheers, > Joachim > > > Am Mittwoch, den 11.11.2020, 13:41 -0800 schrieb Iavor Diatchki: > > Hello, > > > > Proposal #281 has been submitted for review by the committee again, > please read through it and let's have a discussion. Here are links to the > proposal's discussion section, and the proposal text: > > > > https://github.com/ghc-proposals/ghc-proposals/pull/281 > > > https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst > > > > While I suggested acceptance on the previous version, I am leaning > towards rejecting the proposal now. My reasoning is that I hadn't fully > understood all the aspects of the original proposal, and the new proposal > seems to lack a simple modular specification. There are *many* changes > described in the document, but I found it hard to understand what is the > current design, from the point of view of a user of the feature, as opposed > to someone trying to implement it. > > > > I'd be curious about what others think. > > > > -Iavor > > > > > > _______________________________________________ > > 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/ > > > _______________________________________________ > 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 Nov 23 03:35:38 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 23 Nov 2020 03:35:38 +0000 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: References: <524f6d6dcb187207c6a2534fea6e458b3e74af2f.camel@joachim-breitner.de> Message-ID: <010f0175f32bd94d-88792ad6-0d26-4294-81b7-80eb77aa9583-000000@us-east-2.amazonses.com> My silence on this proposal is because I want to accept, but I agree with Iavor that it's become too baroque. My #378 is, in part, an attempt to clarify our stance on these sorts of features so that we can take a stab at simplifying #281 by making it less expressive. So, I guess my vote is to delay decision on this proposal until we have one for #378 (or #270, which can also help shed light on this one). Responding directly to Alejandro's concerns here: I actually don't really understand. I think (1) is decided by https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0081-forall-arrow.rst; we use this syntax in standalone kind signatures in GHC 8.10. We *could* change this if there were a compelling reason, but this proposal is just continuing an existing feature. By (2), I think you're referring to all the complications in the proposals at how to deal with names and syntax in arguments -- I wouldn't myself describe this as conflating the two namespaces, but rather as defining a subtle set of rules for interpreting ambiguous names. It's the subtlety of these rules that makes me uncomfortable. For (3), I don't really think there's much there -- and what there is seems to require (2) (and vice versa). Do you have an example of a type-inference interaction you're worried about here? Richard > On Nov 22, 2020, at 12:09 PM, Alejandro Serrano Mena wrote: > > Hi all, > For me, there are two main concerns here: > This could be split on different proposals: (1) using the “forall a ->” syntax, (2) conflating the type and term syntax and namespaces, (3) introducing checking and inference for it; > I find the claim that you can just take the Quick Look Impredicativity paper, make a couple of adjustments, and get correct checking and inference. This kind of big change is the one for which I would actually expect a peer-reviewed paper. > > Regards, > Alejandro > > El El sáb, 21 nov 2020 a las 10:10, Joachim Breitner > escribió: > Dear Committee, > > Iavor suggested to reject this proposal, but we have not heard a lot > here yet. Especially before rejecting proposals, we probably owe a > careful analysis, possibly with suggestions of ways forward (splitting > the proposal into smaller pieces maybe? Iavor says there are many > changes there). > > If we have continued silence, we’d reject. > > Cheers, > Joachim > > > Am Mittwoch, den 11.11.2020, 13:41 -0800 schrieb Iavor Diatchki: > > Hello, > > > > Proposal #281 has been submitted for review by the committee again, please read through it and let's have a discussion. Here are links to the proposal's discussion section, and the proposal text: > > > > https://github.com/ghc-proposals/ghc-proposals/pull/281 > > https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst > > > > While I suggested acceptance on the previous version, I am leaning towards rejecting the proposal now. My reasoning is that I hadn't fully understood all the aspects of the original proposal, and the new proposal seems to lack a simple modular specification. There are *many* changes described in the document, but I found it hard to understand what is the current design, from the point of view of a user of the feature, as opposed to someone trying to implement it. > > > > I'd be curious about what others think. > > > > -Iavor > > > > > > _______________________________________________ > > 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/ > > > _______________________________________________ > 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 Nov 23 08:10:16 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 23 Nov 2020 09:10:16 +0100 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: <010f0175f32bd94d-88792ad6-0d26-4294-81b7-80eb77aa9583-000000@us-east-2.amazonses.com> References: <524f6d6dcb187207c6a2534fea6e458b3e74af2f.camel@joachim-breitner.de> <010f0175f32bd94d-88792ad6-0d26-4294-81b7-80eb77aa9583-000000@us-east-2.amazonses.com> Message-ID: Hi, Richard roughly says what is my sentiment too… I’d phrase it like this: It seems that #281 would be rather straight forward, if it were not for the fact that this is the first (of many?) extensions that allow types and terms to occur in the same syntactic spot. So far, when mentally parsing a program, I know where to look for types, and where to look for terms. #281 breaks that, and has to come up with lots of subtle rules, that make me uneasy. But that's not really #281’s fault – assuming we want to head towards Dependent Haskell with a unified namespace, it’s a problem that needs to be solved! But better have that discussion with a focus on that problem, and have a plan that works in general. Maybe #270 is the right place to have that discussion. My impression is that all (most?) of those working towards a Dependent Haskell world assume that we get a unified namespace with no punning, and all complexity (`type` sigils, `type`-qualified imports) is around compatibility with modules that use punning, with the hope that this is rare. Few are proposing to stick to a world of two namespaces and punning and make _that_ ergonomic. Is that impression correct? Do local modules (#283) alleviate the punning problem a bit? Given `data T = T`, could we make it so that T is the type and T.T the constructor? But this really isn't the right place to throw out shower ideas. I wonder if it would help if someone could maintain a wiki page with an overview of all the numerous proposals and ideas thrown around to tackle the problem about how we get from a world of two name spaces and punning to one with one namespaces and no punning. As for #281, unless I misjudge the urgency of that change, I’d be in favor to park it until we have a good, generally applicable plan for mixing terms and types. Cheers, Joachim Am Montag, den 23.11.2020, 03:35 +0000 schrieb Richard Eisenberg: > My silence on this proposal is because I want to accept, but I agree with Iavor that it's become too baroque. My #378 is, in part, an attempt to clarify our stance on these sorts of features so that we can take a stab at simplifying #281 by making it less expressive. > > So, I guess my vote is to delay decision on this proposal until we have one for #378 (or #270, which can also help shed light on this one). > > Responding directly to Alejandro's concerns here: I actually don't really understand. I think (1) is decided by https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0081-forall-arrow.rst; we use this syntax in standalone kind signatures in GHC 8.10. We *could* change this if there were a compelling reason, but this proposal is just continuing an existing feature. By (2), I think you're referring to all the complications in the proposals at how to deal with names and syntax in arguments -- I wouldn't myself describe this as conflating the two namespaces, but rather as defining a subtle set of rules for interpreting ambiguous names. It's the subtlety of these rules that makes me uncomfortable. For (3), I don't really think there's much there -- and what there is seems to require (2) (and vice versa). Do you have an example of a type-inference interaction you're worried about here? > > Richard > > > On Nov 22, 2020, at 12:09 PM, Alejandro Serrano Mena wrote: > > > > Hi all, > > For me, there are two main concerns here: > > This could be split on different proposals: (1) using the “forall a ->” syntax, (2) conflating the type and term syntax and namespaces, (3) introducing checking and inference for it; > > I find the claim that you can just take the Quick Look Impredicativity paper, make a couple of adjustments, and get correct checking and inference. This kind of big change is the one for which I would actually expect a peer-reviewed paper. > > > > Regards, > > Alejandro > > > > El El sáb, 21 nov 2020 a las 10:10, Joachim Breitner escribió: > > > Dear Committee, > > > > > > Iavor suggested to reject this proposal, but we have not heard a lot > > > here yet. Especially before rejecting proposals, we probably owe a > > > careful analysis, possibly with suggestions of ways forward (splitting > > > the proposal into smaller pieces maybe? Iavor says there are many > > > changes there). > > > > > > If we have continued silence, we’d reject. > > > > > > Cheers, > > > Joachim > > > > > > > > > Am Mittwoch, den 11.11.2020, 13:41 -0800 schrieb Iavor Diatchki: > > > > Hello, > > > > > > > > Proposal #281 has been submitted for review by the committee again, please read through it and let's have a discussion. Here are links to the proposal's discussion section, and the proposal text: > > > > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/281 > > > > https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst > > > > > > > > While I suggested acceptance on the previous version, I am leaning towards rejecting the proposal now. My reasoning is that I hadn't fully understood all the aspects of the original proposal, and the new proposal seems to lack a simple modular specification. There are *many* changes described in the document, but I found it hard to understand what is the current design, from the point of view of a user of the feature, as opposed to someone trying to implement it. > > > > > > > > I'd be curious about what others think. > > > > > > > > -Iavor > > > > > > > > > > > > _______________________________________________ > > > > 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/ > > > > > > > > > _______________________________________________ > > > 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 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From marlowsd at gmail.com Mon Nov 23 14:37:57 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 23 Nov 2020 14:37:57 +0000 Subject: [ghc-steering-committee] Please review #313: Delimited continuation primops, Shepherd: Simon Marlow In-Reply-To: <8f73b563dc640510a288261be00db36314669fff.camel@joachim-breitner.de> References: <8f73b563dc640510a288261be00db36314669fff.camel@joachim-breitner.de> Message-ID: Committee, We have been asked to review #313: Delimited continuation primops https://github.com/ghc-proposals/ghc-proposals/pull/313 https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md *Summary* The proposal makes no language changes, it only adds three primops . The main motivation is to support building efficient implementations of Algebraic Effect systems, which depend on being able to efficiently capture a continuation. Currently this is done explicitly, which imposes a severe performance penalty. These primops are the minimal support needed to be able to capture a continuation and apply it at runtime, together with some basic type safety via the PromtTag type to ensure that at least we don't replace a continuation with a computation of a different type. (there are other ways to go wrong with these primops though, they're not a safe interface by themselves: they need to be wrapped in a safe library). The primops are implemented by copying chunks of stack into the heap. This is something that GHC's runtime already does a lot of, so it's not a new concept, although it does require a new closure type and knock-on changes across several files in the runtime (though it's mainly mechanical). There's a prototype implementation here: https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline *Decision* I'm going to tentatively recommend acceptance. - This is a sensible choice for the primtives, being the most general of the alternatives, as explained in the proposal. - Would the new primops impose a significant ongoing maintenance burden? Having looked at the patch, although there are some missing pieces, I don't think the new concepts impose any significant new requirements on other parts of the runtime. - I suspect there may be some difficulties around unsafePerformIO, so I raised that on the github thread Thoughts? On Sat, 12 Sep 2020 at 22:59, Joachim Breitner wrote: > Dear Committee, > > this is your secretary speaking: > > Delimited continuation primops > has been proposed by Alexis King > https://github.com/ghc-proposals/ghc-proposals/pull/313 > > https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md > > I’ll propose Simon Marlow 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Nov 23 18:22:28 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 23 Nov 2020 18:22:28 +0000 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: References: <524f6d6dcb187207c6a2534fea6e458b3e74af2f.camel@joachim-breitner.de> <010f0175f32bd94d-88792ad6-0d26-4294-81b7-80eb77aa9583-000000@us-east-2.amazonses.com> Message-ID: <010f0175f657c4a2-83e64682-6a6a-4f03-92fe-3ba5af74125b-000000@us-east-2.amazonses.com> I agree with Joachim here, who has unpacked this better than I did. For me, the key observation is "but that's not really #281's fault". That is, #281 just happens to be the first place where we're hitting this problem head on. > On Nov 23, 2020, at 3:10 AM, Joachim Breitner wrote: > > My impression is that all (most?) of > those working towards a Dependent Haskell world assume that we get a > unified namespace with no punning That indeed has been my assumption, but I've been reminded recently that this assumption is just that. In particular, combining types and terms is not strictly necessary to support dependent types. I do think it's necessary to have the smooth, happy dependent types I yearn for, but maybe we can't always get what we want. I don't want to distract this particular thread with the details (which would take some work to spell out), but I will admit that this merger is not strictly necessary for dependent types -- and perhaps the merger is precisely what I mean when I use "ergonomic" in #378. > Few are proposing to stick to > a world of two namespaces and punning and make _that_ ergonomic. Is > that impression correct? For those of us working in this area, I think that is correct. There may be people about the excited about ergonomic dependent types that don't merge, but I don't believe they're actively working on designs. > > Do local modules (#283) alleviate the punning problem a bit? Given > `data T = T`, could we make it so that T is the type and T.T the > constructor? Interesting point. Yes, in #283's full glory. Maybe this is good motivation to make the requested updates there. > > But this really isn't the right place to throw out shower ideas. I > wonder if it would help if someone could maintain a wiki page with an > overview of all the numerous proposals and ideas thrown around to > tackle the problem about how we get from a world of two name spaces and > punning to one with one namespaces and no punning. Yes. I'll do this if no one beats me to it. But it may be a few days. Thanks, Richard From mail at joachim-breitner.de Tue Nov 24 09:05:24 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 24 Nov 2020 10:05:24 +0100 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: <010f0175f657c4a2-83e64682-6a6a-4f03-92fe-3ba5af74125b-000000@us-east-2.amazonses.com> References: <524f6d6dcb187207c6a2534fea6e458b3e74af2f.camel@joachim-breitner.de> <010f0175f32bd94d-88792ad6-0d26-4294-81b7-80eb77aa9583-000000@us-east-2.amazonses.com> <010f0175f657c4a2-83e64682-6a6a-4f03-92fe-3ba5af74125b-000000@us-east-2.amazonses.com> Message-ID: Hi, Am Montag, den 23.11.2020, 18:22 +0000 schrieb Richard Eisenberg: > On Nov 23, 2020, at 3:10 AM, Joachim Breitner wrote: > > > > My impression is that all (most?) of > > those working towards a Dependent Haskell world assume that we get a > > unified namespace with no punning > > That indeed has been my assumption, but I've been reminded recently > that this assumption is just that. In particular, combining types and > terms is not strictly necessary to support dependent types. I do > think it's necessary to have the smooth, happy dependent types I > yearn for, but maybe we can't always get what we want. I don't want > to distract this particular thread with the details (which would take > some work to spell out), but I will admit that this merger is not > strictly necessary for dependent types -- and perhaps the merger is > precisely what I mean when I use "ergonomic" in #378. Hmm, I think the emphasis above was lost in written communication, I meant “that we get a unified namespace _with no punning_”. What would a unified namespace with punning mean? It means there is no inherent difference between what is now a data constructor and a type constructor, i.e. a unified namespace, but set up so that juggling the fact that the same name may be used in multiple places is ergonomic. Already, we deal with something like that, purely within what’s currently the term level: * The same name may be used in different modules (and then I qualify) * The same name may be bound in different scopes (and we resolve via with shadowing) * The same name may be a record accessor in different records (and we resolve that with… eh, well, I have seen proposals about that ;-) So maybe there is a path towards a world where there is a single namespace, but we can deal with the same name referring to different things, where the resolution mechanism is ergonomic to use, and (unlike “type” and “term” sigils) does not keep the distinction between terms and types longer than necessary. If such a path exists I would be more confident that we can steer Haskell into that direction, given the plethora of punning libraries out there that should ideally continue to work ergonomically. Not sure how different “single namespace, but working with punning is ergonomic” is different from “two namespaces”. Maybe only in terms of framing and conceptualization. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Tue Nov 24 09:34:18 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 24 Nov 2020 10:34:18 +0100 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts Message-ID: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Dear Committee, the requested data (hackage and survey) is in, has been aggregated, cooked, seasoned and is ready for consumption. 116 extensions are waiting on your assessment, so time to vote! ## Procedure Please vote by email to this list, in a response to this thread. I want to make tallying easy and automatic, and my code will consider an extension Foo voted for if you write "Foo: yes" on its own line. This means you can include rationales, write "Foo: maybe" and "Foo: no" to remind yourself and others that about where you are, and you can safely quote other’s mails. For example, if you write: ---- begin example ---- Easy ones: DeriveFooBar: yes OverloadedBen: no These ones are tricky: ImplicitExceptions: yes I know nobody likes that one, but I do. RandomEvaluationOrder: maybe Not sure about this one, here is why… > Richard wrote: > DependentHaskell: yes > Rationale: See my thesis I’m not convinced yet, tell me more, so DependentHaskell: maybe ---- end example ---- then you have voted for DeriveFooBar and ImplicitExceptions. Only “yes” matters, “no”, “maybe” and “later” are all ignored. I will shortly send my first ballot around. Also see the end of this mail for a copy’n’paste template. You can update your vote as often as you want. Please always send your full votes (I will only consider your latest email). I encourage you to do that early, e.g. maybe start with a mail where you list the obvious yes and nos, and keep some at maybe and then refine. The timeline says first votes should be in within two weeks, and then a bit more to refine. But the earlier the merrier! The quota is 8. In particular, if everyone votes (and I hope everyone will), an extension won’t make it this round if 4 don’t include it. ## Data Please see https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data for the data, including explanations. It is intentionally not sorted by the data, as the choice of ranking function would already be quite influencing. You may want to play around with that data, e.g. sort it by your own criteria etc. I looked long for an online service where I can upload the data and allow you to explore it, but then I noticed that that's a bit stupid, since we all probably can do it best with Haskell. So I made it easy to load the data into GHCi, see the instructions at https://github.com/nomeata/ghc-proposals-stats/blob/master/ext-stats/README.md which allow you, for example, to do this *Main> mapM_ (\E{..} -> Text.Printf.printf "%s: %d\n" ext survey_no) $ take 10 $ reverse $ sortOn (\E{..} -> survey_no) (M.elems exts) AllowAmbiguousTypes: 195 CPP: 192 IncoherentInstances: 176 Arrows: 156 Strict: 153 ImplicitParams: 147 UndecidableInstances: 144 OverlappingInstances: 144 Unsafe: 139 TemplateHaskell: 137 Of course, if someone wants to upload the data somewhere and share that, that's also useful. Let me know if some of this doesn't quite work for you, and should be improved. Maybe we need a web form instead of mails? ## PS: Blank ballot To start, you could copy the following into an email AllowAmbiguousTypes: maybe ApplicativeDo: maybe Arrows: maybe BangPatterns: maybe BinaryLiterals: maybe BlockArguments: maybe CApiFFI: maybe CPP: maybe CUSKs: maybe ConstrainedClassMethods: maybe ConstraintKinds: maybe DataKinds: maybe DatatypeContexts: maybe DefaultSignatures: maybe DeriveAnyClass: maybe DeriveDataTypeable: maybe DeriveFoldable: maybe DeriveFunctor: maybe DeriveGeneric: maybe DeriveLift: maybe DeriveTraversable: maybe DerivingStrategies: maybe DerivingVia: maybe DisambiguateRecordFields: maybe DuplicateRecordFields: maybe EmptyCase: maybe EmptyDataDecls: maybe EmptyDataDeriving: maybe ExistentialQuantification: maybe ExplicitForAll: maybe ExplicitNamespaces: maybe ExtendedDefaultRules: maybe FlexibleContexts: maybe FlexibleInstances: maybe ForeignFunctionInterface: maybe FunctionalDependencies: maybe GADTSyntax: maybe GADTs: maybe GHCForeignImportPrim: maybe GeneralisedNewtypeDeriving: maybe HexFloatLiterals: maybe ImplicitParams: maybe ImportQualifiedPost: maybe ImpredicativeTypes: maybe IncoherentInstances: maybe InstanceSigs: maybe InterruptibleFFI: maybe KindSignatures: maybe LambdaCase: maybe LexicalNegation: maybe LiberalTypeSynonyms: maybe LinearTypes: maybe MagicHash: maybe MonadComprehensions: maybe MonadFailDesugaring: maybe MonoLocalBinds: maybe MultiParamTypeClasses: maybe MultiWayIf: maybe NPlusKPatterns: maybe NamedFieldPuns: maybe NamedWildCards: maybe NegativeLiterals: maybe NoImplicitPrelude: maybe NoMonomorphismRestriction: maybe NoPatternGuards: maybe NoTraditionalRecordSyntax: maybe NondecreasingIndentation: maybe NullaryTypeClasses: maybe NumDecimals: maybe NumericUnderscores: maybe OverlappingInstances: maybe OverloadedLabels: maybe OverloadedLists: maybe OverloadedStrings: maybe PackageImports: maybe ParallelListComp: maybe PartialTypeSignatures: maybe PatternSynonyms: maybe PolyKinds: maybe PostfixOperators: maybe QualifiedDo: maybe QuantifiedConstraints: maybe QuasiQuotes: maybe RankNTypes: maybe RebindableSyntax: maybe RecordWildCards: maybe RecursiveDo: maybe RoleAnnotations: maybe Safe: maybe ScopedTypeVariables: maybe StandaloneDeriving: maybe StandaloneKindSignatures: maybe StarIsType: maybe StaticPointers: maybe Strict: maybe StrictData: maybe TemplateHaskell: maybe TemplateHaskellQuotes: maybe TransformListComp: maybe Trustworthy: maybe TupleSections: maybe TypeApplications: maybe TypeFamilies: maybe TypeFamilyDependencies: maybe TypeInType: maybe TypeOperators: maybe TypeSynonymInstances: maybe UnboxedSums: maybe UnboxedTuples: maybe UndecidableInstances: maybe UndecidableSuperClasses: maybe UnicodeSyntax: maybe UnliftedFFITypes: maybe UnliftedNewtypes: maybe Unsafe: maybe ViewPatterns: maybe -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Tue Nov 24 10:16:29 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 24 Nov 2020 11:16:29 +0100 Subject: [ghc-steering-committee] #380 GHC2021: My initial vote In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: <031ddf4e33e5beee2cfdacd947c960c964d4e1f3.camel@joachim-breitner.de> Hi, here is my current vote, mostly getting out of the way what seems obvious to me. Let’s first get all those out of the way that are too contentions according to the data (with 2*no>yes votes): My starting point here was: *Main> putStr $ unlines [ ext ++ ": no" | E{..} <- M.elems exts, survey_no > 10, survey_no * 2 > survey_yes ] And that gave me the following: AllowAmbiguousTypes: no ApplicativeDo: no Arrows: no BlockArguments: no CApiFFI: no CPP: no ConstrainedClassMethods: no DatatypeContexts: no DisambiguateRecordFields: no DuplicateRecordFields: no ExplicitNamespaces: no ExtendedDefaultRules: no ForeignFunctionInterface: no HexFloatLiterals: no ImplicitParams: no ImportQualifiedPost: no ImpredicativeTypes: no IncoherentInstances: no InterruptibleFFI: no LiberalTypeSynonyms: no MagicHash: no MonadComprehensions: no MonoLocalBinds: no NPlusKPatterns: no NamedWildCards: no NoImplicitPrelude: no NoMonomorphismRestriction: no NoPatternGuards: no NoTraditionalRecordSyntax: no NullaryTypeClasses: no NumDecimals: no -- ^ Unsure about this one OverlappingInstances: no OverloadedLabels: no OverloadedLists: no PackageImports: no ParallelListComp: no PartialTypeSignatures: no -- ^ Unsure about this one, but trusting the crowd until convinced otherwise PostfixOperators: no -- ^ Woudn’t mind this cleanup. Tally numbers are maybe insignificant QuantifiedConstraints: no QuasiQuotes: no RebindableSyntax: no RecursiveDo: no -- ^ I like that one. But probably not widespread enough. StaticPointers: no Strict: no StrictData: no TemplateHaskell: no TemplateHaskellQuotes: no TransformListComp: no Trustworthy: no TypeFamilyDependencies: no TypeInType: no TypeSynonymInstances: no UnboxedSums: no UnboxedTuples: no UndecidableInstances: no UndecidableSuperClasses: no Unsafe: no Actually, some of them I disagree with, and believe they are safe to turn on by default, and would be happy to, with sufficient committee support: NegativeLiterals: yes RoleAnnotations: yes UnicodeSyntax: yes -- ^ I ❤ unicode UnliftedNewtype s: yes -- ^ or is there something wrong with that? Now to those with at least 20% popularity: *Main> putStr $ unlines [ ext ++ ": no" | E{..} <- M.elems exts, not (survey_no > 10 && survey_no * 2 > survey_yes), 5 * survey_yes > survey_total ] These I happily go with, until I learn otherwise: BangPatterns: yes ConstraintKinds: yes DataKinds: yes DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveTraversable: yes DerivingStrategies: yes DerivingVia: yes FlexibleContexts: yes FlexibleInstances: yes GADTs: yes GeneralisedNewtypeDeriving: yes KindSignatures: yes LambdaCase: yes MultiParamTypeClasses: yes RankNTypes: yes StandaloneDeriving: yes TupleSections: yes TypeApplications: yes TypeFamilies: yes TypeOperators: yes ViewPatterns: yes There are some where I disagree with the crowd: ScopedTypeVariables: no -- ^ Too much of a kitchen sink, some edges are rough, and some of its semantics (“bind type signatures unless in scope”) are being questioned. If we had the plain PatternSignatures as a separate extension, I’d vote that in though. If ScopedTypeVariables doesn't make it this round, I will revive #119 to get that. OverloadedStrings: no -- ^ yes, has many fans. But I believe that many might actuall use that although what they really want is a monomorphic "foo" :: Text and I wonder if there is a way to give them that. Also, some report that too much polymorphism can hurt, e.g. in is_vowel c = c `elem` "aeiou" Three is also 12% Aloofness and 12% Contentionsness, which are not to be dismissed. So I am inclined to leave this out, for this round at least. MultiWayIf: no -- ^ in light of discussion around a multi-case, maybe premature The remaining ones, *Main> putStr $ unlines [ ext ++ ": yes" | E{..} <- M.elems exts, not (survey_no > 10 && survey_no * 2 > survey_yes), not (5 * survey_yes > survey_total) ] Kinda clear: BinaryLiterals: yes DeriveLift: yes EmptyCase: yes EmptyDataDecls: yes EmptyDataDeriving: yes ExistentialQuantification: yes -- ^ Or is anything wrong with that? ExplicitForAll: yes GADTSyntax: yes -- ^ In case GADTs don’t make it InstanceSigs: yes NamedFieldPuns: yes NondecreasingIndentation: yes -- ^ It’s Haskell98 and the current default(!), but not Haskell2010? NumericUnderscores: yes RecordWildCards: yes UnliftedFFITypes: yes StarIsType: yes -- ^ It’s the default now. Probably too early to turn off? DefaultSignatures: no -- ^ Deriving via is probably preferrable these days DeriveAnyClass: no LinearTypes: no PatternSynonyms: no -- ^ I like them, but maybe a bit too early MonadFailDesugaring: no -- ^ This extension is temporary, and will be deprecated in a future release. QualifiedDo: no Safe: no No expert on these, will read your rationales: FunctionalDependencies: maybe StandaloneKindSignatures: maybe CUSKs: maybe GHCForeignImportPrim: maybe LexicalNegation: maybe -- ^ Unsure about the maturity of the whitespace sensitiviy trend PolyKinds: maybe -- ^ Does it even make sense to vote on this? Quite a long list! Surely the next years will be easier. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Tue Nov 24 12:14:39 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 24 Nov 2020 12:14:39 +0000 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: References: <524f6d6dcb187207c6a2534fea6e458b3e74af2f.camel@joachim-breitner.de> <010f0175f32bd94d-88792ad6-0d26-4294-81b7-80eb77aa9583-000000@us-east-2.amazonses.com> Message-ID: * Having two name-spaces appears to be The Major Obstacle towards making satisfying incremental progress in the direction of dependent types. * So perhaps we should have an extension -XSingleNameSpace that has a single name space, with all the consequences that would entail (like changing the syntax of tuple and list types). * Then further extensions toward dependent types could require -XSingleNameSpace. If you don't want that, you don't get the new goodies. There would be no expectation that a dependent-types extension should fit well with the double-name-space situation; maybe the combination is actually disallowed. * Or maybe the combination is allowed, but a bit clunky. For example, suppose a library defines f :: forall a -> blah Then, in a module with classic-Haskell name spaces, you'd have to say f (type Int) and not (f Int), forcibly setting the namespace. It'd be good to have this conversation on GitHub, and perhaps #378 is the place to do that? Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Joachim Breitner | Sent: 23 November 2020 08:10 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Please review "Visible 'forall' in | types of terms" #281 | | Hi, | | Richard roughly says what is my sentiment too… I’d phrase it like this: | | It seems that #281 would be rather straight forward, if it were not for the | fact that this is the first (of many?) extensions that allow types and terms | to occur in the same syntactic spot. So far, when mentally parsing a | program, I know where to look for types, and where to look for terms. #281 | breaks that, and has to come up with lots of subtle rules, that make me | uneasy. | | But that's not really #281’s fault – assuming we want to head towards | Dependent Haskell with a unified namespace, it’s a problem that needs to be | solved! But better have that discussion with a focus on that problem, and | have a plan that works in general. Maybe #270 is the right place to have | that discussion. | | My impression is that all (most?) of | those working towards a Dependent Haskell world assume that we get a unified | namespace with no punning, and all complexity (`type` sigils, `type`- | qualified imports) is around compatibility with modules that use punning, | with the hope that this is rare. Few are proposing to stick to a world of | two namespaces and punning and make _that_ ergonomic. Is that impression | correct? | | Do local modules (#283) alleviate the punning problem a bit? Given `data T = | T`, could we make it so that T is the type and T.T the constructor? | | But this really isn't the right place to throw out shower ideas. I wonder if | it would help if someone could maintain a wiki page with an overview of all | the numerous proposals and ideas thrown around to tackle the problem about | how we get from a world of two name spaces and punning to one with one | namespaces and no punning. | | | As for #281, unless I misjudge the urgency of that change, I’d be in favor | to park it until we have a good, generally applicable plan for mixing terms | and types. | | Cheers, | Joachim | | | | | Am Montag, den 23.11.2020, 03:35 +0000 schrieb Richard Eisenberg: | > My silence on this proposal is because I want to accept, but I agree with | Iavor that it's become too baroque. My #378 is, in part, an attempt to | clarify our stance on these sorts of features so that we can take a stab at | simplifying #281 by making it less expressive. | > | > So, I guess my vote is to delay decision on this proposal until we have | one for #378 (or #270, which can also help shed light on this one). | > | > Responding directly to Alejandro's concerns here: I actually don't really | understand. I think (1) is decided by | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com | %2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0081-forall- | arrow.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e470021260 | 8d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417159812849940% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=vU3lOmJ6kFNfEuy9MOo6ZoapadyzGIXPZblhR9QYvD0% | 3D&reserved=0; we use this syntax in standalone kind signatures in GHC | 8.10. We *could* change this if there were a compelling reason, but this | proposal is just continuing an existing feature. By (2), I think you're | referring to all the complications in the proposals at how to deal with | names and syntax in arguments -- I wouldn't myself describe this as | conflating the two namespaces, but rather as defining a subtle set of rules | for interpreting ambiguous names. It's the subtlety of these rules that | makes me uncomfortable. For (3), I don't really think there's much there -- | and what there is seems to require (2) (and vice versa). Do you have an | example of a type-inference interaction you're worried about here? | > | > Richard | > | > > On Nov 22, 2020, at 12:09 PM, Alejandro Serrano Mena | wrote: | > > | > > Hi all, | > > For me, there are two main concerns here: | > > This could be split on different proposals: (1) using the “forall a | > > ->” syntax, (2) conflating the type and term syntax and namespaces, (3) | introducing checking and inference for it; I find the claim that you can | just take the Quick Look Impredicativity paper, make a couple of | adjustments, and get correct checking and inference. This kind of big change | is the one for which I would actually expect a peer-reviewed paper. | > > | > > Regards, | > > Alejandro | > > | > > El El sáb, 21 nov 2020 a las 10:10, Joachim Breitner escribió: | > > > Dear Committee, | > > > | > > > Iavor suggested to reject this proposal, but we have not heard a | > > > lot here yet. Especially before rejecting proposals, we probably | > > > owe a careful analysis, possibly with suggestions of ways forward | > > > (splitting the proposal into smaller pieces maybe? Iavor says | > > > there are many changes there). | > > > | > > > If we have continued silence, we’d reject. | > > > | > > > Cheers, | > > > Joachim | > > > | > > > | > > > Am Mittwoch, den 11.11.2020, 13:41 -0800 schrieb Iavor Diatchki: | > > > > Hello, | > > > > | > > > > Proposal #281 has been submitted for review by the committee again, | please read through it and let's have a discussion. Here are links to the | proposal's discussion section, and the proposal text: | > > > > | > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F% | > > > > 2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&da | > > > > ta=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e4700212608d88 | > > > > f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741715981 | > > > > 2849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | > > > > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oWBR%2BJue6s | > > > > 2bh7WU7lRhfHTcaDrQoUHzveh7e4XqWJE%3D&reserved=0 | > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F% | > > > > 2Fgithub.com%2Fint-index%2Fghc-proposals%2Fblob%2Fvisible-forall | > > > > %2Fproposals%2F0000-visible-forall.rst&data=04%7C01%7Csimonp | > > > > j%40microsoft.com%7Ccba94a6d611e4700212608d88f87414e%7C72f988bf8 | > > > > 6f141af91ab2d7cd011db47%7C1%7C1%7C637417159812849940%7CUnknown%7 | > > > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw | > > > > iLCJXVCI6Mn0%3D%7C3000&sdata=cfbyhbDYnPX%2BC7BKrak3mzPEFyiXY | > > > > wPhza3T1sv2X2I%3D&reserved=0 | > > > > | > > > > While I suggested acceptance on the previous version, I am leaning | towards rejecting the proposal now. My reasoning is that I hadn't fully | understood all the aspects of the original proposal, and the new proposal | seems to lack a simple modular specification. There are *many* changes | described in the document, but I found it hard to understand what is the | current design, from the point of view of a user of the feature, as opposed | to someone trying to implement it. | > > > > | > > > > I'd be curious about what others think. | > > > > | > > > > -Iavor | > > > > | > > > > | > > > > _______________________________________________ | > > > > 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=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d | > > > > 611e4700212608d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1% | > > > > 7C1%7C637417159812849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA | > > > > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s | > > > > data=JJjZfHZhOTQ6yo31ucKEFHC9hNIXG9McT18FbuYbgvI%3D&reserved | > > > > =0 | > > > -- | > > > Joachim Breitner | > > > mail at joachim-breitner.de | > > > | > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw | > > > ww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.c | > > > om%7Ccba94a6d611e4700212608d88f87414e%7C72f988bf86f141af91ab2d7cd0 | > > > 11db47%7C1%7C1%7C637417159812849940%7CUnknown%7CTWFpbGZsb3d8eyJWIj | > > > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 | > > > 0&sdata=BArEbQSBvN4zsTDWtN9PW3klvk1c05lX8hhm2jMKk5E%3D&res | > > > erved=0 | > > > | > > > | > > > _______________________________________________ | > > > ghc-steering-committee mailing list | > > > ghc-steering-committee at haskell.org | > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F | > > > mail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-com | > > > mittee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e47 | > > > 00212608d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63 | > > > 7417159812849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | > > > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JJjZfHZ | > > > hOTQ6yo31ucKEFHC9hNIXG9McT18FbuYbgvI%3D&reserved=0 | > > | > > _______________________________________________ | > > ghc-steering-committee mailing list | > > ghc-steering-committee at haskell.org | > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > > il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | > > ee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e47002126 | > > 08d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374171598 | > > 12849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI | > > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JJjZfHZhOTQ6yo31ucK | > > EFHC9hNIXG9McT18FbuYbgvI%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&a | > mp;data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e4700212608d88f | > 87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417159812859933 | > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I | > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=er3qe80%2BcqnIn3UIKfjuGu4VDwkH7 | > jEosJqR45eKvn4%3D&reserved=0 | -- | Joachim Breitner | mail at joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e4700 | 212608d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741715981285 | 9933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dyYFsh09gm4vxafb%2FRfa36jb8QT%2BBlHUtx1 | OK6AMf%2BE%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.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e470021260 | 8d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417159812859933% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=er3qe80%2BcqnIn3UIKfjuGu4VDwkH7jEosJqR45eKvn | 4%3D&reserved=0 From arnaud.spiwack at tweag.io Wed Nov 25 11:20:30 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 25 Nov 2020 12:20:30 +0100 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: Here is my vote: ## I don't know what these are LexicalNegation: maybe NondecreasingIndentation: maybe ## No opinion yet Probably none of these are popular enough to be worth including in this first round anyway. BlockArguments: maybe CUSKs: maybe DataKinds: maybe DefaultSignatures: maybe DisambiguateRecordFields: maybe DuplicateRecordFields: maybe ImportQualifiedPost: maybe MonadComprehensions: maybe ^ It's fairly popular this one, but I don't know the effects on type inference. I feel it may be a similar case as the OverloadedX extensions, in which case it feels premature to add it to GHC2021. NamedFieldPuns: maybe ^ While I live and breath for NamedFieldPuns, it does remove some shadowing warnings, so it does make some things harder, and it's likely that we want this one left out of this round. NamedWildCards: maybe RecordWildCards: maybe NullaryTypeClasses: maybe NumDecimals: maybe PackageImports: maybe ParallelListComp: maybe PolyKinds: maybe PostfixOperators: maybe RankNTypes: maybe RecursiveDo: maybe TransformListComp: maybe TypeInType: maybe TypeSynonymInstances: maybe UnliftedFFITypes: maybe ScopedTypeVariables: maybe ^ There seem to be discussion about the type-signature-in-pattern part of this extension, which I have no opinion about. I'm very much in favour of the bind-type-signature-variable parts. But I guess this is likely to be too controversial an extension for this round. UnicodeSyntax: maybe ^ I think it changes error messages. I don't think that we can make error messages in Unicode by default. If it only affects parsing, then I'm in favour. ## Just adds syntax These extensions simply add syntax, they bear little risk, I see no reason not to avoid them. Let me include all of the deriving things in this category. Arrows: yes BangPatterns: yes BinaryLiterals: yes DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveLift: yes DeriveTraversable: yes DerivingStrategies: yes GeneralisedNewtypeDeriving: yes ^ Though this technically collides with the DeriveX syntax, the collision is innocuous: you would derive the same functor whether you are using the stock strategy or the newtype strategy. TypeFamilies: yes TypeFamilyDependencies: yes GADTs: yes GADTSyntax: yes ^ Implied by GADTs TypeOperators: yes ConstraintKinds: yes FunctionalDependencies: yes EmptyCase: yes HexFloatLiterals: yes ConstrainedClassMethods: yes ExplicitForAll: yes ExplicitNamespaces: yes KindSignatures: yes NegativeLiterals: yes NumericUnderscores: yes PartialTypeSignatures: yes ViewPatterns: yes TypeApplications: yes StandaloneDeriving: yes MonoLocalBinds: yes ^ MonoLocalBinds is implied by both GADTs and TypeFamilies. And it makes my addition of GADTs and TypeFamilies in this section a lie. We may want to have NoMonoLocalBinds turned on forcefully (or GADTSyntax but not GADTs nor TypeFamilies this time around). But MonoLocalBinds really want to become the default. So I'm inclined to let it be. ### Exceptions to the rule DeriveAnyClass: no ^ This doesn't so much add syntax as generalises syntax (as opposed to DeriveFunctor, for instance, which may be read as adding Functor to the syntactic list of things which can appear in the Derive list). This probably leads to too many ambiguities for the first round. DerivingVia: no ^ It's pretty innocuous, but too recent for inclusion. TupleSections: probably not ^ I believe there has been some discussion about conflicts between TupleSection and terminal commas. So while it's a fairly popular extension, I think it's safer to keep it out. ExistentialQuantification: probably notation ^ I don't think we need this syntax if GADTs are around. So maybe I'd rather see that as not being a default, so as to nudge programmers to the GADT syntax. LambdaCase: probably not ^ As popular and lovely as this extension is, considering that there are some discussion on its future, I'm sadly compelled to give it a pass. ## Type class stuff MultiParamTypeClasses: yes FlexibleContexts: yes FlexibleInstances: yes ^ I believe both FlexibleContexts and FlexibleInstances to be almost always innocuous, so they should probably make it in. UndecidableInstances: no UndecidableSuperClasses: no ^ The UndecidableX are not as scary as they look, yet, I don't think they ought to be there by default. This termination check exists for a reason. It's true that, today, many (most?) instances using MultiParamTypeClasses need UndecidableInstances, though. But it could probably be improved. ## Feature switches These are switches for advanced feature (or "slow" features in the case of the case of Template Haskell), they should never be on by default. NoImplicitPrelude: no TemplateHaskell: no TemplateHaskellQuotes: no QuasiQuotes: no RebindableSyntax: no CApiFFI: no CPP: no ForeignFunctionInterface: no GHCForeignImportPrim: no InterruptibleFFI: no MagicHash: no UnboxedSums: no UnboxedTuples: no ^ Though, frankly, all of MagicHash, UnboxedSums, and UnboxedTuples could very well become not-advanced in a not-so-far-future. Then we could turn them on by default as just-adding-syntax. ### Forks on the roads These are not so much advanced features as features that change significantly the meaning of the module they are in. Strict: no StrictData: no ## Module metadata None of these should be on. Safe: no Trustworthy: no Unsafe: no ## OverloadedX These extensions can confuse type inference, yielding ambiguous type variables message. And as much as I like them, I don't think it's safe to include them yet. Not until we have a reasonable story for defaulting literals. OverloadedLabels: no OverloadedLists: no OverloadedStrings: no ## Difficult errors These extension yield type errors which are quite a bit more difficult than turning them off. So they are better left out. AllowAmbiguousTypes: no ## Not ready yet Hodgepodge list. ApplicativeDo: no LinearTypes: no ImpredicativeTypes: no QualifiedDo: no QuantifiedConstraints: no RoleAnnotations: no StaticPointers: no StandaloneKindSignatures: no UnliftedNewtypes: no ## Already in GHC MonadFailDesugaring: yes StarIsType: yes ^ We should not turn this one off until standalone kind signatures are also the default, in my opinion. ## Already in Haskell 2010 EmptyDataDecls: yes EmptyDataDeriving: yes ## Uncommon extensions ExtendedDefaultRules: no ImplicitParams: no InstanceSigs: no -- ^ It does feel mostly innocuous on the surface, but it has a probably surprising semantics. Considering that it's quite rarely used, probably better left out. LiberalTypeSynonyms: no NoMonomorphismRestriction: no NoPatternGuards: no NoTraditionalRecordSyntax: no PatternSynonyms: no ## Deprecated extensions OverlappingInstances: no DatatypeContexts: no IncoherentInstances: no MultiWayIf: no NPlusKPatterns: no -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Nov 25 11:43:03 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 25 Nov 2020 12:43:03 +0100 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: <42dd12659d046d363f83db5ecbe88e4550a42869.camel@joachim-breitner.de> Hi, Thanks! I’ll update the tally later today. Am Mittwoch, den 25.11.2020, 12:20 +0100 schrieb Spiwack, Arnaud: > UnicodeSyntax: maybe > ^ I think it changes error messages. I don't think that we can > make error messages in Unicode by default. If it only affects > parsing, then I'm in favour. That is my sentiment as well, and I would phrase my vote as: GHC2021 implies UnicodeSyntax, but not -fprint-unicode-syntax. Enabling UnicodeSyntax explicitly may still imply -fprint-unicode-syntax. I guess the details of how GHC formats its messages are not strictly our authority, so I didn't spell this out, but yes: it helps to paint the picture here more clearly. > InstanceSigs: no > -- ^ It does feel mostly innocuous on the surface, but it has a > probably surprising semantics. Considering that it's quite rarely > used, probably better left out. Interesting, I don’t see a mention of this on https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-InstanceSigs Can you elaborate? Also thanks for looking up which extensions are already in GHC, Haskell2010 and are deprecated. I should indicate that in the table somehow (or simply drop them from the ballot, at least the deprecated ones). Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Wed Nov 25 12:01:28 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 25 Nov 2020 13:01:28 +0100 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: <42dd12659d046d363f83db5ecbe88e4550a42869.camel@joachim-breitner.de> References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> <42dd12659d046d363f83db5ecbe88e4550a42869.camel@joachim-breitner.de> Message-ID: On Wed, Nov 25, 2020 at 12:43 PM Joachim Breitner wrote: > Hi, > > Thanks! I’ll update the tally later today. > > Am Mittwoch, den 25.11.2020, 12:20 +0100 schrieb Spiwack, Arnaud: > > UnicodeSyntax: maybe > > ^ I think it changes error messages. I don't think that we can > > make error messages in Unicode by default. If it only affects > > parsing, then I'm in favour. > > That is my sentiment as well, and I would phrase my vote as: > > GHC2021 implies UnicodeSyntax, but not -fprint-unicode-syntax. > Enabling UnicodeSyntax explicitly may still imply -fprint-unicode-syntax. > > I guess the details of how GHC formats its messages are not strictly > our authority, so I didn't spell this out, but yes: it helps to paint > the picture here more clearly. > > > InstanceSigs: no > > -- ^ It does feel mostly innocuous on the surface, but it has a > > probably surprising semantics. Considering that it's quite rarely > > used, probably better left out. > > Interesting, I don’t see a mention of this on > > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-InstanceSigs > Can you elaborate? > I'm referring to: > The type signature in the instance declaration must be more polymorphic than (or the same as) the one in the class declaration, instantiated with the instance type. I may be overly conservative here, to be honest. But I'm just a tad hesitant. I should probably have written “a tad hesistant” instead of “no”, though. But this is a long list of extensions, and I was getting tired :) . Also thanks for looking up which extensions are already in GHC, > Haskell2010 and are deprecated. I should indicate that in the table > somehow (or simply drop them from the ballot, at least the deprecated > ones). > I don't claim exhaustiveness there. Nor am I 100% sure about correctness. For instance, I'm pretty sure that n+k patterns are considered deprecated, but the documentation doesn't reflect it. I still stored it in the deprecated section as there is basically no way that we turn this one on by default again. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Nov 25 12:12:53 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 25 Nov 2020 13:12:53 +0100 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: References: <524f6d6dcb187207c6a2534fea6e458b3e74af2f.camel@joachim-breitner.de> <010f0175f32bd94d-88792ad6-0d26-4294-81b7-80eb77aa9583-000000@us-east-2.amazonses.com> Message-ID: Back to the main point, it seems to be fairly consensual, right now, that #281 doesn't seem to have found the sweet spot which would make it work quite right. Not yet. I basically agree with the points raised so far. As I said earlier in the thread, I'm sympathetic with the goals, but unconvinced by the details. Is there a committee member which disagrees with the emerging consensus? On Tue, Nov 24, 2020 at 1:15 PM Simon Peyton Jones via ghc-steering-committee wrote: > * Having two name-spaces appears to be The Major Obstacle towards making > satisfying incremental progress in the direction of dependent types. > > * So perhaps we should have an extension -XSingleNameSpace that has a > single > name space, with all the consequences that would entail (like changing > the > syntax of tuple and list types). > > * Then further extensions toward dependent types could require > -XSingleNameSpace. > If you don't want that, you don't get the new goodies. There would be no > expectation that a dependent-types extension should fit well with the > double-name-space situation; maybe the combination is actually > disallowed. > > * Or maybe the combination is allowed, but a bit clunky. For example, > suppose > a library defines f :: forall a -> blah > Then, in a module with classic-Haskell name spaces, you'd have to say > f (type Int) > and not (f Int), forcibly setting the namespace. > > It'd be good to have this conversation on GitHub, and perhaps #378 is the > place to do that? > > Simon > > | -----Original Message----- > | From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> On > | Behalf Of Joachim Breitner > | Sent: 23 November 2020 08:10 > | To: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] Please review "Visible 'forall' in > | types of terms" #281 > | > | Hi, > | > | Richard roughly says what is my sentiment too… I’d phrase it like this: > | > | It seems that #281 would be rather straight forward, if it were not for > the > | fact that this is the first (of many?) extensions that allow types and > terms > | to occur in the same syntactic spot. So far, when mentally parsing a > | program, I know where to look for types, and where to look for terms. > #281 > | breaks that, and has to come up with lots of subtle rules, that make me > | uneasy. > | > | But that's not really #281’s fault – assuming we want to head towards > | Dependent Haskell with a unified namespace, it’s a problem that needs > to be > | solved! But better have that discussion with a focus on that problem, > and > | have a plan that works in general. Maybe #270 is the right place to have > | that discussion. > | > | My impression is that all (most?) of > | those working towards a Dependent Haskell world assume that we get a > unified > | namespace with no punning, and all complexity (`type` sigils, `type`- > | qualified imports) is around compatibility with modules that use > punning, > | with the hope that this is rare. Few are proposing to stick to a world > of > | two namespaces and punning and make _that_ ergonomic. Is that impression > | correct? > | > | Do local modules (#283) alleviate the punning problem a bit? Given > `data T = > | T`, could we make it so that T is the type and T.T the constructor? > | > | But this really isn't the right place to throw out shower ideas. I > wonder if > | it would help if someone could maintain a wiki page with an overview of > all > | the numerous proposals and ideas thrown around to tackle the problem > about > | how we get from a world of two name spaces and punning to one with one > | namespaces and no punning. > | > | > | As for #281, unless I misjudge the urgency of that change, I’d be in > favor > | to park it until we have a good, generally applicable plan for mixing > terms > | and types. > | > | Cheers, > | Joachim > | > | > | > | > | Am Montag, den 23.11.2020, 03:35 +0000 schrieb Richard Eisenberg: > | > My silence on this proposal is because I want to accept, but I agree > with > | Iavor that it's become too baroque. My #378 is, in part, an attempt to > | clarify our stance on these sorts of features so that we can take a > stab at > | simplifying #281 by making it less expressive. > | > > | > So, I guess my vote is to delay decision on this proposal until we > have > | one for #378 (or #270, which can also help shed light on this one). > | > > | > Responding directly to Alejandro's concerns here: I actually don't > really > | understand. I think (1) is decided by > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com > | > %2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0081-forall- > | arrow.rst&data=04%7C01%7Csimonpj%40microsoft.com > %7Ccba94a6d611e470021260 > | > 8d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417159812849940% > | > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > | > LCJXVCI6Mn0%3D%7C3000&sdata=vU3lOmJ6kFNfEuy9MOo6ZoapadyzGIXPZblhR9QYvD0% > | 3D&reserved=0; we use this syntax in standalone kind signatures in > GHC > | 8.10. We *could* change this if there were a compelling reason, but this > | proposal is just continuing an existing feature. By (2), I think you're > | referring to all the complications in the proposals at how to deal with > | names and syntax in arguments -- I wouldn't myself describe this as > | conflating the two namespaces, but rather as defining a subtle set of > rules > | for interpreting ambiguous names. It's the subtlety of these rules that > | makes me uncomfortable. For (3), I don't really think there's much > there -- > | and what there is seems to require (2) (and vice versa). Do you have an > | example of a type-inference interaction you're worried about here? > | > > | > Richard > | > > | > > On Nov 22, 2020, at 12:09 PM, Alejandro Serrano Mena < > trupill at gmail.com> > | wrote: > | > > > | > > Hi all, > | > > For me, there are two main concerns here: > | > > This could be split on different proposals: (1) using the “forall a > | > > ->” syntax, (2) conflating the type and term syntax and namespaces, > (3) > | introducing checking and inference for it; I find the claim that you can > | just take the Quick Look Impredicativity paper, make a couple of > | adjustments, and get correct checking and inference. This kind of big > change > | is the one for which I would actually expect a peer-reviewed paper. > | > > > | > > Regards, > | > > Alejandro > | > > > | > > El El sáb, 21 nov 2020 a las 10:10, Joachim Breitner | breitner.de> escribió: > | > > > Dear Committee, > | > > > > | > > > Iavor suggested to reject this proposal, but we have not heard a > | > > > lot here yet. Especially before rejecting proposals, we probably > | > > > owe a careful analysis, possibly with suggestions of ways forward > | > > > (splitting the proposal into smaller pieces maybe? Iavor says > | > > > there are many changes there). > | > > > > | > > > If we have continued silence, we’d reject. > | > > > > | > > > Cheers, > | > > > Joachim > | > > > > | > > > > | > > > Am Mittwoch, den 11.11.2020, 13:41 -0800 schrieb Iavor Diatchki: > | > > > > Hello, > | > > > > > | > > > > Proposal #281 has been submitted for review by the committee > again, > | please read through it and let's have a discussion. Here are links to > the > | proposal's discussion section, and the proposal text: > | > > > > > | > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F% > | > > > > 2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&da > | > > > > ta=04%7C01%7Csimonpj%40microsoft.com > %7Ccba94a6d611e4700212608d88 > | > > > > f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741715981 > | > > > > 2849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu > | > > > > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oWBR%2BJue6s > | > > > > 2bh7WU7lRhfHTcaDrQoUHzveh7e4XqWJE%3D&reserved=0 > | > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F% > | > > > > 2Fgithub.com%2Fint-index%2Fghc-proposals%2Fblob%2Fvisible-forall > | > > > > %2Fproposals%2F0000-visible-forall.rst&data=04%7C01%7Csimonp > | > > > > j%40microsoft.com > %7Ccba94a6d611e4700212608d88f87414e%7C72f988bf8 > | > > > > 6f141af91ab2d7cd011db47%7C1%7C1%7C637417159812849940%7CUnknown%7 > | > > > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw > | > > > > iLCJXVCI6Mn0%3D%7C3000&sdata=cfbyhbDYnPX%2BC7BKrak3mzPEFyiXY > | > > > > wPhza3T1sv2X2I%3D&reserved=0 > | > > > > > | > > > > While I suggested acceptance on the previous version, I am > leaning > | towards rejecting the proposal now. My reasoning is that I hadn't > fully > | understood all the aspects of the original proposal, and the new > proposal > | seems to lack a simple modular specification. There are *many* changes > | described in the document, but I found it hard to understand what is > the > | current design, from the point of view of a user of the feature, as > opposed > | to someone trying to implement it. > | > > > > > | > > > > I'd be curious about what others think. > | > > > > > | > > > > -Iavor > | > > > > > | > > > > > | > > > > _______________________________________________ > | > > > > 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=04%7C01%7Csimonpj%40microsoft.com > %7Ccba94a6d > | > > > > 611e4700212608d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1% > | > > > > 7C1%7C637417159812849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA > | > > > > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s > | > > > > data=JJjZfHZhOTQ6yo31ucKEFHC9hNIXG9McT18FbuYbgvI%3D&reserved > | > > > > =0 > | > > > -- > | > > > Joachim Breitner > | > > > mail at joachim-breitner.de > | > > > > | > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw > | > > > ww.joachim-breitner.de > %2F&data=04%7C01%7Csimonpj%40microsoft.c > | > > > om%7Ccba94a6d611e4700212608d88f87414e%7C72f988bf86f141af91ab2d7cd0 > | > > > 11db47%7C1%7C1%7C637417159812849940%7CUnknown%7CTWFpbGZsb3d8eyJWIj > | > > > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > | > > > 0&sdata=BArEbQSBvN4zsTDWtN9PW3klvk1c05lX8hhm2jMKk5E%3D&res > | > > > erved=0 > | > > > > | > > > > | > > > _______________________________________________ > | > > > ghc-steering-committee mailing list > | > > > ghc-steering-committee at haskell.org > | > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F > | > > > mail.haskell.org > %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-com > | > > > mittee&data=04%7C01%7Csimonpj%40microsoft.com > %7Ccba94a6d611e47 > | > > > 00212608d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63 > | > > > 7417159812849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI > | > > > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JJjZfHZ > | > > > hOTQ6yo31ucKEFHC9hNIXG9McT18FbuYbgvI%3D&reserved=0 > | > > > | > > _______________________________________________ > | > > ghc-steering-committee mailing list > | > > ghc-steering-committee at haskell.org > | > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma > | > > il.haskell.org > %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ > | > > ee&data=04%7C01%7Csimonpj%40microsoft.com > %7Ccba94a6d611e47002126 > | > > 08d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374171598 > | > > 12849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI > | > > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JJjZfHZhOTQ6yo31ucK > | > > EFHC9hNIXG9McT18FbuYbgvI%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&a > | > mp;data=04%7C01%7Csimonpj%40microsoft.com > %7Ccba94a6d611e4700212608d88f > | > 87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417159812859933 > | > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > | > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=er3qe80%2BcqnIn3UIKfjuGu4VDwkH7 > | > jEosJqR45eKvn4%3D&reserved=0 > | -- > | Joachim Breitner > | mail at joachim-breitner.de > | > | > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim > | - > | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com > %7Ccba94a6d611e4700 > | > 212608d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741715981285 > | > 9933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > | > haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dyYFsh09gm4vxafb%2FRfa36jb8QT%2BBlHUtx1 > | OK6AMf%2BE%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.haske > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=04%7C01%7Csimonpj%40microsoft.com > %7Ccba94a6d611e470021260 > | > 8d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417159812859933% > | > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > | > LCJXVCI6Mn0%3D%7C3000&sdata=er3qe80%2BcqnIn3UIKfjuGu4VDwkH7jEosJqR45eKvn > | 4%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 arnaud.spiwack at tweag.io Wed Nov 25 12:18:16 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 25 Nov 2020 13:18:16 +0100 Subject: [ghc-steering-committee] Please review #313: Delimited continuation primops, Shepherd: Simon Marlow In-Reply-To: References: <8f73b563dc640510a288261be00db36314669fff.camel@joachim-breitner.de> Message-ID: I like delimited continuations a lot. They are a fantastic tool of delicious sweetness. So I'm delighted at the idea of delimited continuations coming to GHC. I may not be very objective here. I haven't looked at the proposal for a while. But, last I checked, I found it rather convincing. I have little opinion about the implementation, which touches parts of GHC of which I know very little. But if Simon and Simon, you both find the prototype reasonable, I'll be quite happy to accept the proposal. On Mon, Nov 23, 2020 at 3:38 PM Simon Marlow wrote: > Committee, > > We have been asked to review > #313: Delimited continuation primops > https://github.com/ghc-proposals/ghc-proposals/pull/313 > > https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md > > *Summary* > > The proposal makes no language changes, it only adds three primops > > . > > The main motivation is to support building efficient implementations of > Algebraic Effect systems, which depend on being able to efficiently capture > a continuation. Currently this is done explicitly, which imposes a severe > performance penalty. > > These primops are the minimal support needed to be able to capture a > continuation and apply it at runtime, together with some basic type safety > via the PromtTag type to ensure that at least we don't replace a > continuation with a computation of a different type. (there are other ways > to go wrong with these primops though, they're not a safe interface by > themselves: they need to be wrapped in a safe library). > > The primops are implemented by copying chunks of stack into the heap. This > is something that GHC's runtime already does a lot of, so it's not a new > concept, although it does require a new closure type and knock-on changes > across several files in the runtime (though it's mainly mechanical). > There's a prototype implementation here: > https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline > > *Decision* > > I'm going to tentatively recommend acceptance. > > - This is a sensible choice for the primtives, being the most general > of the alternatives, as explained in the proposal. > > - Would the new primops impose a significant ongoing maintenance > burden? Having looked at the patch, although there are some missing pieces, > I don't think the new concepts impose any significant new requirements on > other parts of the runtime. > - I suspect there may be some difficulties around unsafePerformIO, so > I raised that on the github thread > > > Thoughts? > > > > On Sat, 12 Sep 2020 at 22:59, Joachim Breitner > wrote: > >> Dear Committee, >> >> this is your secretary speaking: >> >> Delimited continuation primops >> has been proposed by Alexis King >> https://github.com/ghc-proposals/ghc-proposals/pull/313 >> >> https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md >> >> I’ll propose Simon Marlow 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 >> > _______________________________________________ > 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 Wed Nov 25 13:47:03 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Nov 2020 13:47:03 +0000 Subject: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 In-Reply-To: References: <524f6d6dcb187207c6a2534fea6e458b3e74af2f.camel@joachim-breitner.de> <010f0175f32bd94d-88792ad6-0d26-4294-81b7-80eb77aa9583-000000@us-east-2.amazonses.com> Message-ID: Back to the main point, it seems to be fairly consensual, right now, that #281 doesn't seem to have found the sweet spot which would make it work quite right I don’t think I agree. I think it’s close to working right. See my recent comment on the proposal. Simon From: Spiwack, Arnaud Sent: 25 November 2020 12:13 To: Simon Peyton Jones Cc: Joachim Breitner ; ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Please review "Visible 'forall' in types of terms" #281 Back to the main point, it seems to be fairly consensual, right now, that #281 doesn't seem to have found the sweet spot which would make it work quite right. Not yet. I basically agree with the points raised so far. As I said earlier in the thread, I'm sympathetic with the goals, but unconvinced by the details. Is there a committee member which disagrees with the emerging consensus? On Tue, Nov 24, 2020 at 1:15 PM Simon Peyton Jones via ghc-steering-committee > wrote: * Having two name-spaces appears to be The Major Obstacle towards making satisfying incremental progress in the direction of dependent types. * So perhaps we should have an extension -XSingleNameSpace that has a single name space, with all the consequences that would entail (like changing the syntax of tuple and list types). * Then further extensions toward dependent types could require -XSingleNameSpace. If you don't want that, you don't get the new goodies. There would be no expectation that a dependent-types extension should fit well with the double-name-space situation; maybe the combination is actually disallowed. * Or maybe the combination is allowed, but a bit clunky. For example, suppose a library defines f :: forall a -> blah Then, in a module with classic-Haskell name spaces, you'd have to say f (type Int) and not (f Int), forcibly setting the namespace. It'd be good to have this conversation on GitHub, and perhaps #378 is the place to do that? Simon | -----Original Message----- | From: ghc-steering-committee > On | Behalf Of Joachim Breitner | Sent: 23 November 2020 08:10 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Please review "Visible 'forall' in | types of terms" #281 | | Hi, | | Richard roughly says what is my sentiment too… I’d phrase it like this: | | It seems that #281 would be rather straight forward, if it were not for the | fact that this is the first (of many?) extensions that allow types and terms | to occur in the same syntactic spot. So far, when mentally parsing a | program, I know where to look for types, and where to look for terms. #281 | breaks that, and has to come up with lots of subtle rules, that make me | uneasy. | | But that's not really #281’s fault – assuming we want to head towards | Dependent Haskell with a unified namespace, it’s a problem that needs to be | solved! But better have that discussion with a focus on that problem, and | have a plan that works in general. Maybe #270 is the right place to have | that discussion. | | My impression is that all (most?) of | those working towards a Dependent Haskell world assume that we get a unified | namespace with no punning, and all complexity (`type` sigils, `type`- | qualified imports) is around compatibility with modules that use punning, | with the hope that this is rare. Few are proposing to stick to a world of | two namespaces and punning and make _that_ ergonomic. Is that impression | correct? | | Do local modules (#283) alleviate the punning problem a bit? Given `data T = | T`, could we make it so that T is the type and T.T the constructor? | | But this really isn't the right place to throw out shower ideas. I wonder if | it would help if someone could maintain a wiki page with an overview of all | the numerous proposals and ideas thrown around to tackle the problem about | how we get from a world of two name spaces and punning to one with one | namespaces and no punning. | | | As for #281, unless I misjudge the urgency of that change, I’d be in favor | to park it until we have a good, generally applicable plan for mixing terms | and types. | | Cheers, | Joachim | | | | | Am Montag, den 23.11.2020, 03:35 +0000 schrieb Richard Eisenberg: | > My silence on this proposal is because I want to accept, but I agree with | Iavor that it's become too baroque. My #378 is, in part, an attempt to | clarify our stance on these sorts of features so that we can take a stab at | simplifying #281 by making it less expressive. | > | > So, I guess my vote is to delay decision on this proposal until we have | one for #378 (or #270, which can also help shed light on this one). | > | > Responding directly to Alejandro's concerns here: I actually don't really | understand. I think (1) is decided by | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com | %2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0081-forall- | arrow.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e470021260 | 8d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417159812849940% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=vU3lOmJ6kFNfEuy9MOo6ZoapadyzGIXPZblhR9QYvD0% | 3D&reserved=0; we use this syntax in standalone kind signatures in GHC | 8.10. We *could* change this if there were a compelling reason, but this | proposal is just continuing an existing feature. By (2), I think you're | referring to all the complications in the proposals at how to deal with | names and syntax in arguments -- I wouldn't myself describe this as | conflating the two namespaces, but rather as defining a subtle set of rules | for interpreting ambiguous names. It's the subtlety of these rules that | makes me uncomfortable. For (3), I don't really think there's much there -- | and what there is seems to require (2) (and vice versa). Do you have an | example of a type-inference interaction you're worried about here? | > | > Richard | > | > > On Nov 22, 2020, at 12:09 PM, Alejandro Serrano Mena > | wrote: | > > | > > Hi all, | > > For me, there are two main concerns here: | > > This could be split on different proposals: (1) using the “forall a | > > ->” syntax, (2) conflating the type and term syntax and namespaces, (3) | introducing checking and inference for it; I find the claim that you can | just take the Quick Look Impredicativity paper, make a couple of | adjustments, and get correct checking and inference. This kind of big change | is the one for which I would actually expect a peer-reviewed paper. | > > | > > Regards, | > > Alejandro | > > | > > El El sáb, 21 nov 2020 a las 10:10, Joachim Breitner > escribió: | > > > Dear Committee, | > > > | > > > Iavor suggested to reject this proposal, but we have not heard a | > > > lot here yet. Especially before rejecting proposals, we probably | > > > owe a careful analysis, possibly with suggestions of ways forward | > > > (splitting the proposal into smaller pieces maybe? Iavor says | > > > there are many changes there). | > > > | > > > If we have continued silence, we’d reject. | > > > | > > > Cheers, | > > > Joachim | > > > | > > > | > > > Am Mittwoch, den 11.11.2020, 13:41 -0800 schrieb Iavor Diatchki: | > > > > Hello, | > > > > | > > > > Proposal #281 has been submitted for review by the committee again, | please read through it and let's have a discussion. Here are links to the | proposal's discussion section, and the proposal text: | > > > > | > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F% | > > > > 2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F281&da | > > > > ta=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e4700212608d88 | > > > > f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741715981 | > > > > 2849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | > > > > MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=oWBR%2BJue6s | > > > > 2bh7WU7lRhfHTcaDrQoUHzveh7e4XqWJE%3D&reserved=0 | > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F% | > > > > 2Fgithub.com%2Fint-index%2Fghc-proposals%2Fblob%2Fvisible-forall | > > > > %2Fproposals%2F0000-visible-forall.rst&data=04%7C01%7Csimonp | > > > > j%40microsoft.com%7Ccba94a6d611e4700212608d88f87414e%7C72f988bf8 | > > > > 6f141af91ab2d7cd011db47%7C1%7C1%7C637417159812849940%7CUnknown%7 | > > > > CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWw | > > > > iLCJXVCI6Mn0%3D%7C3000&sdata=cfbyhbDYnPX%2BC7BKrak3mzPEFyiXY | > > > > wPhza3T1sv2X2I%3D&reserved=0 | > > > > | > > > > While I suggested acceptance on the previous version, I am leaning | towards rejecting the proposal now. My reasoning is that I hadn't fully | understood all the aspects of the original proposal, and the new proposal | seems to lack a simple modular specification. There are *many* changes | described in the document, but I found it hard to understand what is the | current design, from the point of view of a user of the feature, as opposed | to someone trying to implement it. | > > > > | > > > > I'd be curious about what others think. | > > > > | > > > > -Iavor | > > > > | > > > > | > > > > _______________________________________________ | > > > > 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=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d | > > > > 611e4700212608d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1% | > > > > 7C1%7C637417159812849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA | > > > > wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&s | > > > > data=JJjZfHZhOTQ6yo31ucKEFHC9hNIXG9McT18FbuYbgvI%3D&reserved | > > > > =0 | > > > -- | > > > Joachim Breitner | > > > mail at joachim-breitner.de | > > > | > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw | > > > ww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.c | > > > om%7Ccba94a6d611e4700212608d88f87414e%7C72f988bf86f141af91ab2d7cd0 | > > > 11db47%7C1%7C1%7C637417159812849940%7CUnknown%7CTWFpbGZsb3d8eyJWIj | > > > oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 | > > > 0&sdata=BArEbQSBvN4zsTDWtN9PW3klvk1c05lX8hhm2jMKk5E%3D&res | > > > erved=0 | > > > | > > > | > > > _______________________________________________ | > > > ghc-steering-committee mailing list | > > > ghc-steering-committee at haskell.org | > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F | > > > mail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-com | > > > mittee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e47 | > > > 00212608d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63 | > > > 7417159812849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | > > > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JJjZfHZ | > > > hOTQ6yo31ucKEFHC9hNIXG9McT18FbuYbgvI%3D&reserved=0 | > > | > > _______________________________________________ | > > ghc-steering-committee mailing list | > > ghc-steering-committee at haskell.org | > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma | > > il.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committ | > > ee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e47002126 | > > 08d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374171598 | > > 12849940%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI | > > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=JJjZfHZhOTQ6yo31ucK | > > EFHC9hNIXG9McT18FbuYbgvI%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&a | > mp;data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e4700212608d88f | > 87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417159812859933 | > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I | > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=er3qe80%2BcqnIn3UIKfjuGu4VDwkH7 | > jEosJqR45eKvn4%3D&reserved=0 | -- | Joachim Breitner | mail at joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e4700 | 212608d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741715981285 | 9933%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dyYFsh09gm4vxafb%2FRfa36jb8QT%2BBlHUtx1 | OK6AMf%2BE%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.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccba94a6d611e470021260 | 8d88f87414e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C637417159812859933% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=er3qe80%2BcqnIn3UIKfjuGu4VDwkH7jEosJqR45eKvn | 4%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 arnaud.spiwack at tweag.io Wed Nov 25 14:05:59 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 25 Nov 2020 15:05:59 +0100 Subject: [ghc-steering-committee] Unsaturated type families (#242) In-Reply-To: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com> References: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com> Message-ID: I often wish I could use unsaturated type families. Where I can see that going fairly mainstream in the medium term is in the higher-kinded-data-type sort of idiom. Whereby one parameterises the type of a record (say) by a family `f :: * -> *` and vary the family to great effect. For instance, it would make the types in the multiplate library [ https://hackage.haskell.org/package/multiplate ] quite a bit more palatable. Like Richard, I want to advance a prudent: yes. As far as alternatives go, I'm in favour of never inferring matchability polymorphism [ alternative 6, currently ]. That being said this is a proposal which touches the arrow, which makes it a fairly large proposal. So it does need more careful eyes to anticipate issues. The proposal is, in particular, not fully backwards compatible (it involves promotion of data constructors which take functions as arguments, it's hard to avoid it). So please, give this one a good reading. Let's make sure we are happy with it. On Fri, Nov 20, 2020 at 8:36 PM Richard Eisenberg wrote: > Hi committee, > > Csongor Kiss has proposed -XUnsaturatedTypeFamilies. > > Proposal: > https://github.com/kcsongor/ghc-proposals/blob/unsaturated-type-families/proposals/0000-unsaturated-type-families.rst > ICFP'19 paper: > https://www.microsoft.com/en-us/research/uploads/prod/2019/03/unsaturated-type-families-icfp-2019.pdf > Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/242 > > The central idea is to allow type functions (both type families and type > synonyms) to appear unsaturated. (Currently, all type functions are > required syntactically to be applied to all parameters they are declared > with.) This poses a problem for type inference, as detailed in both the > proposal and the paper. The key question: if we have (f a ~ g b), can we > conclude (f ~ g) and (a ~ b)? Not if either of f or g is a type function. > This proposal thus describes a mechanism to introduce a new flavor of > arrow, such that we can identify type functions by their kind. > Specifically, we have regular types like Maybe :: Type -> @M Type (where > the M stands for "matchable"), but type functions like F :: Type -> @U Type > (where the U stands for "unmatchable"). Unmatchable applications can not be > decomposed during type inference. > > Much of the proposal is concerned with backward-compatibility: most users > will not want to write @M or @U after each of their arrows, so the proposal > describes ways of defaulting this behavior to match (most) programmers' > expectations. > > The proposal also includes matchability polymorphism, the ability to > abstract over a matchability parameter. > > Pros: > + This proposal greatly increases the expressiveness of Haskell's type > system. > + With this proposal, we can finally do proper functional programming in > types, rather than just in terms. > + This proposal is a key ingredient toward having dependent types, as > unsaturated functions are commonplace in terms, and thus should also be > supported in types. (Allowing unsaturated functions in types was a key > difference between Adam Gundry's proposal for dependent types > https://adam.gundry.co.uk/pub/thesis/, which requires a notion of a > subset of the type and term languages shared in common, and mine, which > makes no distinction between terms and types.) > + There is a prototype implementation. > + The ideas are backed up by peer-reviewed research. > + Despite focusing on type families, this work applies equally to ordinary > functions which might be used in types once we have stronger support for > dependent types. > > Cons: > - This adds a new dimension of complexity to our kind system, by > separating out matchable and unmatchable arrows. > - The rules for defaulting appear convenient in practice, but are somewhat > arbitrary. > - The rules for defaulting care about context -- does an arrow appear in > the type of a term or the type of a type? These rules thus go against the > spirit of #378, which advocates for not accepting features that distinguish > between types and terms. > > Recommendation: With reservations, I recommend acceptance. I think that > the power to use higher-order programming should not be restricted to > terms, and allowing unsaturated functions at compile time is necessary in > order to have convenient dependent types. However, I am concerned about the > extra complexity of matchability. A key open question for me is how much > matchability is apparent to users -- even ones using some higher-order > type-level programming. If matchability is pervasive, then I would lean > against. But my expectation is that matchability fades into the background > -- much like levity polymorphism (unless you want it). > > Open question: What to do about syntax? The proposed syntax is sensible. > However, #370 suggests an alternative syntax that might be more > forward-thinking. > > 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 trupill at gmail.com Wed Nov 25 14:37:41 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Wed, 25 Nov 2020 14:37:41 +0000 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: -- the ones with comments CUSKs: no -- ^ according to the guide, this is superseded by StandaloneKindSignatures ConstrainedClassMethods: yes -- ^ it is implied by MultiParamTypeClasses anyway DefaultSignatures: no -- ^ as Joachim says, this should be succeeded by DerivingVia -- ^ anyway, this is one required for the writer of the class, so no big deal DeriveAnyClass: yes -- ^ I think this makes no harm, and I tend to use deriving (ToJSON, FromJSON) DerivingVia: yes -- ^ even though it’s quite recent, I think it’s quite sensible and I don’t foresee many changes to it DisambiguateRecordFields: no DuplicateRecordFields: no -- ^ we seem to still be working on this FunctionalDependencies: maybe -- ^ this is a hard one! Not so terrible since it’s only required by the creator of the class, not of the instances MonadFailDesugaring: yes -- ^ isn’t this the default nowadays? MonoLocalBinds: maybe -- ^ this is implied by GADTs, but otherwise we shouldn’t MultiWayIf: no -- ^ still in discussion NamedWildCards: yes -- ^ not many people use this, but I think this is the sane default OverloadedLists: maybe OverloadedStrings: maybe -- ^ I would love to see these included, but I agree with the sentiment that they need more work PartialTypeSignatures: no -- ^ I really think that partial type signatures should not be accepted by default QuantifiedConstraints: maybe -- ^ too early, may want to refine this ScopedTypeVariables: yes -- ^ I think this is really well understood and people want it PatternSynonyms: maybe -- ^ we are still working out the edges of this -- these seem simple syntactic extensions -- many of them bring compatibility with the syntax of Java-like languages BinaryLiterals: yes HexFloatLiterals: yes NegativeLiterals: yes NumDecimals: yes NumericUnderscores: yes -- too early but wouldn’t care to introduce it StandaloneKindSignatures: maybe ImportQualifiedPost: maybe -- don’t know ForeignFunctionInterface: maybe GHCForeignImportPrim: maybe InterruptibleFFI: maybe LexicalNegation: maybe NondecreasingIndentation: maybe PackageImports: maybe ParallelListComp: maybe StarIsType: maybe TransformListComp: maybe UnliftedFFITypes: maybe UnliftedNewtypes: maybe UnicodeSyntax: maybe -- the rest AllowAmbiguousTypes: no ApplicativeDo: no Arrows: no BangPatterns: yes BlockArguments: no CApiFFI: no CPP: no ConstraintKinds: yes DataKinds: yes DatatypeContexts: no DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveLift: yes DeriveTraversable: yes DerivingStrategies: yes EmptyCase: yes EmptyDataDecls: yes EmptyDataDeriving: yes ExistentialQuantification: yes ExplicitForAll: yes ExplicitNamespaces: no ExtendedDefaultRules: no FlexibleContexts: yes FlexibleInstances: yes GADTSyntax: yes -- ^ implied by GADTs anyway GADTs: yes GeneralisedNewtypeDeriving: yes ImplicitParams: no ImpredicativeTypes: no IncoherentInstances: no InstanceSigs: yes KindSignatures: yes LambdaCase: yes LiberalTypeSynonyms: no LinearTypes: no MagicHash: no MonadComprehensions: no MultiParamTypeClasses: yes NPlusKPatterns: no NamedFieldPuns: yes NoImplicitPrelude: no NoMonomorphismRestriction: yes NoPatternGuards: no NoTraditionalRecordSyntax: no NullaryTypeClasses: yes OverlappingInstances: no OverloadedLabels: no PolyKinds: yes PostfixOperators: yes QualifiedDo: no QuasiQuotes: no RankNTypes: no RebindableSyntax: no RecordWildCards: yes RecursiveDo: no RoleAnnotations: no Safe: no StandaloneDeriving: yes StaticPointers: no Strict: no StrictData: no TemplateHaskell: no TemplateHaskellQuotes: no Trustworthy: no TupleSections: yes TypeApplications: yes TypeFamilies: yes TypeFamilyDependencies: no TypeInType: maybe TypeOperators: yes TypeSynonymInstances: yes UnboxedSums: no UnboxedTuples: no UndecidableInstances: no UndecidableSuperClasses: no Unsafe: no ViewPatterns: yes On 24 Nov 2020 at 10:34:18, Joachim Breitner wrote: > Dear Committee, > > the requested data (hackage and survey) is in, has been aggregated, > cooked, seasoned and is ready for consumption. 116 extensions are > waiting on your assessment, so time to vote! > > ## Procedure > > Please vote by email to this list, in a response to this thread. > > I want to make tallying easy and automatic, and my code will consider > an extension Foo voted for if you write "Foo: yes" on its own line. > This means you can include rationales, write "Foo: maybe" and "Foo: no" > to remind yourself and others that about where you are, and you can > safely quote other’s mails. For example, if you write: > > ---- begin > example ---- > > Easy ones: > > DeriveFooBar: yes > OverloadedBen: no > > These ones are tricky: > > ImplicitExceptions: yes > I know nobody likes that one, but I do. > > RandomEvaluationOrder: maybe > Not sure about this one, here is why… > > > Richard wrote: > > DependentHaskell: yes > > Rationale: See my thesis > > > I’m not convinced yet, tell me more, so > DependentHaskell: maybe > > ---- end example ---- > > then you have voted for DeriveFooBar and ImplicitExceptions. Only “yes” > matters, “no”, “maybe” and “later” are all ignored. > > I will shortly send my first ballot around. Also see the end of this > mail for a copy’n’paste template. > > You can update your vote as often as you want. Please always send your > full votes (I will only consider your latest email). I encourage you to > do that early, e.g. maybe start with a mail where you list the obvious > yes and nos, and keep some at maybe and then refine. > > The timeline says first votes should be in within two weeks, and then a > bit more to refine. But the earlier the merrier! > > The quota is 8. In particular, if everyone votes (and I hope everyone > will), an extension won’t make it this round if 4 don’t include it. > > ## Data > > Please see > > https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data > for the data, including explanations. It is intentionally not sorted by > the data, as the choice of ranking function would already be quite > influencing. > > You may want to play around with that data, e.g. sort it by your own > criteria etc. I looked long for an online service where I can upload > the data and allow you to explore it, but then I noticed that that's a > bit stupid, since we all probably can do it best with Haskell. > > So I made it easy to load the data into GHCi, see the instructions at > > https://github.com/nomeata/ghc-proposals-stats/blob/master/ext-stats/README.md > which allow you, for example, to do this > > *Main> mapM_ (\E{..} -> Text.Printf.printf "%s: %d\n" ext survey_no) $ > take 10 $ reverse $ sortOn (\E{..} -> survey_no) (M.elems exts) > AllowAmbiguousTypes: 195 > CPP: 192 > IncoherentInstances: 176 > Arrows: 156 > Strict: 153 > ImplicitParams: 147 > UndecidableInstances: 144 > OverlappingInstances: 144 > Unsafe: 139 > TemplateHaskell: 137 > > Of course, if someone wants to upload the data somewhere and share > that, that's also useful. > > > Let me know if some of this doesn't quite work for you, and should be > improved. Maybe we need a web form instead of mails? > > > ## PS: Blank ballot > > To start, you could copy the following into an email > > AllowAmbiguousTypes: maybe > ApplicativeDo: maybe > Arrows: maybe > BangPatterns: maybe > BinaryLiterals: maybe > BlockArguments: maybe > CApiFFI: maybe > CPP: maybe > CUSKs: maybe > ConstrainedClassMethods: maybe > ConstraintKinds: maybe > DataKinds: maybe > DatatypeContexts: maybe > DefaultSignatures: maybe > DeriveAnyClass: maybe > DeriveDataTypeable: maybe > DeriveFoldable: maybe > DeriveFunctor: maybe > DeriveGeneric: maybe > DeriveLift: maybe > DeriveTraversable: maybe > DerivingStrategies: maybe > DerivingVia: maybe > DisambiguateRecordFields: maybe > DuplicateRecordFields: maybe > EmptyCase: maybe > EmptyDataDecls: maybe > EmptyDataDeriving: maybe > ExistentialQuantification: maybe > ExplicitForAll: maybe > ExplicitNamespaces: maybe > ExtendedDefaultRules: maybe > FlexibleContexts: maybe > FlexibleInstances: maybe > ForeignFunctionInterface: maybe > FunctionalDependencies: maybe > GADTSyntax: maybe > GADTs: maybe > GHCForeignImportPrim: maybe > GeneralisedNewtypeDeriving: maybe > HexFloatLiterals: maybe > ImplicitParams: maybe > ImportQualifiedPost: maybe > ImpredicativeTypes: maybe > IncoherentInstances: maybe > InstanceSigs: maybe > InterruptibleFFI: maybe > KindSignatures: maybe > LambdaCase: maybe > LexicalNegation: maybe > LiberalTypeSynonyms: maybe > LinearTypes: maybe > MagicHash: maybe > MonadComprehensions: maybe > MonadFailDesugaring: maybe > MonoLocalBinds: maybe > MultiParamTypeClasses: maybe > MultiWayIf: maybe > NPlusKPatterns: maybe > NamedFieldPuns: maybe > NamedWildCards: maybe > NegativeLiterals: maybe > NoImplicitPrelude: maybe > NoMonomorphismRestriction: maybe > NoPatternGuards: maybe > NoTraditionalRecordSyntax: maybe > NondecreasingIndentation: maybe > NullaryTypeClasses: maybe > NumDecimals: maybe > NumericUnderscores: maybe > OverlappingInstances: maybe > OverloadedLabels: maybe > OverloadedLists: maybe > OverloadedStrings: maybe > PackageImports: maybe > ParallelListComp: maybe > PartialTypeSignatures: maybe > PatternSynonyms: maybe > PolyKinds: maybe > PostfixOperators: maybe > QualifiedDo: maybe > QuantifiedConstraints: maybe > QuasiQuotes: maybe > RankNTypes: maybe > RebindableSyntax: maybe > RecordWildCards: maybe > RecursiveDo: maybe > RoleAnnotations: maybe > Safe: maybe > ScopedTypeVariables: maybe > StandaloneDeriving: maybe > StandaloneKindSignatures: maybe > StarIsType: maybe > StaticPointers: maybe > Strict: maybe > StrictData: maybe > TemplateHaskell: maybe > TemplateHaskellQuotes: maybe > TransformListComp: maybe > Trustworthy: maybe > TupleSections: maybe > TypeApplications: maybe > TypeFamilies: maybe > TypeFamilyDependencies: maybe > TypeInType: maybe > TypeOperators: maybe > TypeSynonymInstances: maybe > UnboxedSums: maybe > UnboxedTuples: maybe > UndecidableInstances: maybe > UndecidableSuperClasses: maybe > UnicodeSyntax: maybe > UnliftedFFITypes: maybe > UnliftedNewtypes: maybe > Unsafe: maybe > ViewPatterns: maybe > > > > > -- > 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 trupill at gmail.com Wed Nov 25 14:50:35 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Wed, 25 Nov 2020 14:50:35 +0000 Subject: [ghc-steering-committee] Unsaturated type families (#242) In-Reply-To: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com> References: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com> Message-ID: Hi everybody, I really like this proposal. However: - I think the defaulting rules should be revised. Not only because it may conflict with #378 (if accepted), but because I think that the rules should not differentiate between terms and types because getting different outcomes from term functions and type function / families would be surprising. - I think we should wait until we decide about #370 for the syntax. Regards, Alejandro On 20 Nov 2020 at 20:36:12, Richard Eisenberg wrote: > Hi committee, > > Csongor Kiss has proposed -XUnsaturatedTypeFamilies. > > Proposal: > https://github.com/kcsongor/ghc-proposals/blob/unsaturated-type-families/proposals/0000-unsaturated-type-families.rst > ICFP'19 paper: > https://www.microsoft.com/en-us/research/uploads/prod/2019/03/unsaturated-type-families-icfp-2019.pdf > Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/242 > > The central idea is to allow type functions (both type families and type > synonyms) to appear unsaturated. (Currently, all type functions are > required syntactically to be applied to all parameters they are declared > with.) This poses a problem for type inference, as detailed in both the > proposal and the paper. The key question: if we have (f a ~ g b), can we > conclude (f ~ g) and (a ~ b)? Not if either of f or g is a type function. > This proposal thus describes a mechanism to introduce a new flavor of > arrow, such that we can identify type functions by their kind. > Specifically, we have regular types like Maybe :: Type -> @M Type (where > the M stands for "matchable"), but type functions like F :: Type -> @U Type > (where the U stands for "unmatchable"). Unmatchable applications can not be > decomposed during type inference. > > Much of the proposal is concerned with backward-compatibility: most users > will not want to write @M or @U after each of their arrows, so the proposal > describes ways of defaulting this behavior to match (most) programmers' > expectations. > > The proposal also includes matchability polymorphism, the ability to > abstract over a matchability parameter. > > Pros: > + This proposal greatly increases the expressiveness of Haskell's type > system. > + With this proposal, we can finally do proper functional programming in > types, rather than just in terms. > + This proposal is a key ingredient toward having dependent types, as > unsaturated functions are commonplace in terms, and thus should also be > supported in types. (Allowing unsaturated functions in types was a key > difference between Adam Gundry's proposal for dependent types > https://adam.gundry.co.uk/pub/thesis/, which requires a notion of a > subset of the type and term languages shared in common, and mine, which > makes no distinction between terms and types.) > + There is a prototype implementation. > + The ideas are backed up by peer-reviewed research. > + Despite focusing on type families, this work applies equally to ordinary > functions which might be used in types once we have stronger support for > dependent types. > > Cons: > - This adds a new dimension of complexity to our kind system, by > separating out matchable and unmatchable arrows. > - The rules for defaulting appear convenient in practice, but are somewhat > arbitrary. > - The rules for defaulting care about context -- does an arrow appear in > the type of a term or the type of a type? These rules thus go against the > spirit of #378, which advocates for not accepting features that distinguish > between types and terms. > > Recommendation: With reservations, I recommend acceptance. I think that > the power to use higher-order programming should not be restricted to > terms, and allowing unsaturated functions at compile time is necessary in > order to have convenient dependent types. However, I am concerned about the > extra complexity of matchability. A key open question for me is how much > matchability is apparent to users -- even ones using some higher-order > type-level programming. If matchability is pervasive, then I would lean > against. But my expectation is that matchability fades into the background > -- much like levity polymorphism (unless you want it). > > Open question: What to do about syntax? The proposed syntax is sensible. > However, #370 suggests an alternative syntax that might be more > forward-thinking. > > 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 simonpj at microsoft.com Wed Nov 25 15:28:55 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 25 Nov 2020 15:28:55 +0000 Subject: [ghc-steering-committee] Unsaturated type families (#242) In-Reply-To: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com> References: <010f0175e7283309-be0a27ae-ac36-455a-a000-6928d3f083f5-000000@us-east-2.amazonses.com> Message-ID: I'm on board with unsaturated type families. Like Linear Haskell, it's quite a "big" proposal, but accepting it is compatible with idea of Haskell as a laboratory for exploration. I think we should flag it as experimental, with the implication that details are liable to change as we gain experience. Like others, I'd like us to converge on #370 before fixing syntax. I don’t have a strong opinion about the defaulting stuff. Declaration of interest: I'm a co-author on the paper. Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Richard Eisenberg | Sent: 20 November 2020 19:36 | To: Simon Peyton Jones via ghc-steering-committee | Subject: [ghc-steering-committee] Unsaturated type families (#242) | | Hi committee, | | Csongor Kiss has proposed -XUnsaturatedTypeFamilies. | | Proposal: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fkcsongor%2Fghc-proposals%2Fblob%2Funsaturated-type- | families%2Fproposals%2F0000-unsaturated-type- | families.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e3137e | 40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374 | 14978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2l | uMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=WdLjCp2ReG9ZXOjmE | Ow6VCJlAO7Yf1aWkVAXHxrsmMM%3D&reserved=0 | ICFP'19 paper: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. | microsoft.com%2Fen- | us%2Fresearch%2Fuploads%2Fprod%2F2019%2F03%2Funsaturated-type- | families-icfp- | 2019.pdf&data=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e3137e4038 | 5b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63741497 | 8666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI | iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dgowMlsNpH0X9fPAr498F | Y9u8xML9n0G1nwvPN4R9HA%3D&reserved=0 | Discussion: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F242&data=04%7C01%7Csimonpj%40microsoft.com%7Cbd | 9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C9N0y7l | KhZsepv0mkXbJOMDVLFi4bN5kaVW7DbXW1ro%3D&reserved=0 | | The central idea is to allow type functions (both type families and | type synonyms) to appear unsaturated. (Currently, all type functions | are required syntactically to be applied to all parameters they are | declared with.) This poses a problem for type inference, as detailed | in both the proposal and the paper. The key question: if we have (f a | ~ g b), can we conclude (f ~ g) and (a ~ b)? Not if either of f or g | is a type function. This proposal thus describes a mechanism to | introduce a new flavor of arrow, such that we can identify type | functions by their kind. Specifically, we have regular types like | Maybe :: Type -> @M Type (where the M stands for "matchable"), but | type functions like F :: Type -> @U Type (where the U stands for | "unmatchable"). Unmatchable applications can not be decomposed during | type inference. | | Much of the proposal is concerned with backward-compatibility: most | users will not want to write @M or @U after each of their arrows, so | the proposal describes ways of defaulting this behavior to match | (most) programmers' expectations. | | The proposal also includes matchability polymorphism, the ability to | abstract over a matchability parameter. | | Pros: | + This proposal greatly increases the expressiveness of Haskell's type | system. | + With this proposal, we can finally do proper functional programming | in types, rather than just in terms. | + This proposal is a key ingredient toward having dependent types, as | + unsaturated functions are commonplace in terms, and thus should also | be supported in types. (Allowing unsaturated functions in types was a | key difference between Adam Gundry's proposal for dependent types | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fadam | .gundry.co.uk%2Fpub%2Fthesis%2F&data=04%7C01%7Csimonpj%40microsoft | .com%7Cbd9e62e3137e40385b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011 | db47%7C1%7C1%7C637414978666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4w | LjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdat | a=wk7Xc%2Bb5FLSrndKYZ2ytJh6gO2oYiCXLDhQhdEOfSOg%3D&reserved=0, | which requires a notion of a subset of the type and term languages | shared in common, and mine, which makes no distinction between terms | and types.) There is a prototype implementation. | + The ideas are backed up by peer-reviewed research. | + Despite focusing on type families, this work applies equally to | ordinary functions which might be used in types once we have stronger | support for dependent types. | | Cons: | - This adds a new dimension of complexity to our kind system, by | separating out matchable and unmatchable arrows. | - The rules for defaulting appear convenient in practice, but are | somewhat arbitrary. | - The rules for defaulting care about context -- does an arrow appear | in the type of a term or the type of a type? These rules thus go | against the spirit of #378, which advocates for not accepting features | that distinguish between types and terms. | | Recommendation: With reservations, I recommend acceptance. I think | that the power to use higher-order programming should not be | restricted to terms, and allowing unsaturated functions at compile | time is necessary in order to have convenient dependent types. | However, I am concerned about the extra complexity of matchability. A | key open question for me is how much matchability is apparent to users | -- even ones using some higher-order type-level programming. If | matchability is pervasive, then I would lean against. But my | expectation is that matchability fades into the background -- much | like levity polymorphism (unless you want it). | | Open question: What to do about syntax? The proposed syntax is | sensible. However, #370 suggests an alternative syntax that might be | more forward-thinking. | | Richard | _______________________________________________ | 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=04%7C01%7Csimonpj%40microsoft.com%7Cbd9e62e3137e403 | 85b5f08d88d8b91e0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C6374149 | 78666235646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cIlDCT4r8C8Yc0%2BOib | Q%2F6Dv1qzBiB1PpavCdAJI3ruw%3D&reserved=0 From trupill at gmail.com Thu Nov 26 19:58:07 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Thu, 26 Nov 2020 14:58:07 -0500 Subject: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance In-Reply-To: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de> References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de> Message-ID: Dear all, This proposal suggests adding syntax for a general notion of modifiers, like the ones we’ve been talking about lately affecting linearity or matchability of arrows. For example, if linear types and unsaturated families are accepted as they stand, we would have `Int #1 -> @U Bool` (or something like that), whereas with this proposal we would have the more uniform `Int %1 %Unmatchable -> Bool`. Since the amount of modifiers is likely to increase in the future, I think it’s a great idea to agree and reserve such syntax, instead of coming up with different ways on each proposal. I thus recommend acceptance of this proposal. The proposal itself: (1) introduces syntax for modifiers in types and defines how to type/kind check them, (2) reserved such syntax for other uses in declarations and terms. I think the proposal still has its merits only with (1), even though I lean towards accepting both parts of it. Regards, Alejandro On 21 Nov 2020 at 10:07:18, Joachim Breitner wrote: > Dear Committee, > > this is your secretary speaking: > > A syntax for modifiers > has been proposed by Richard Eisenberg (this time it’s true) > https://github.com/ghc-proposals/ghc-proposals/pull/370 > > https://dfinity.slack.com/archives/C01BJ73A893/p1605922403340800?thread_ts=1605913774.336600&cid=C01BJ73A893 > > I’ll propose Alejandro as the shepherd, as he has looked at i > t in detail already. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Fri Nov 27 08:14:40 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 27 Nov 2020 09:14:40 +0100 Subject: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance In-Reply-To: References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de> Message-ID: I've got to say that I'm rather uncomfortable with the type-based meaning ascription of this proposal. That being said, we do need a lightweight way to add such modifiers to arrows (and anything which can appear to the left of an arrows such as fields of data constructors, whether in record notation or not (though I'm fine with requiring GADT notation when not a record, that's what we did with Linear Types)). There is a staggering amount of possible such modifiers which have been conceptualised. By far, this is the least awful such proposal that I've seen. It's the first time that such a proposal looks even remotely usable. So the pragmatic in me is inclined to accept as well. The need for such a lightweight mechanism to annotate terms, though, is quite a bit less clear to me. Because type disambiguation is rather novel in GHC, I'd rather be prudent in this area, and stage the term bits as future work. Keep the design, and revisit it once we have experience with the mechanism for arrow modifiers. On Thu, Nov 26, 2020 at 8:58 PM Alejandro Serrano Mena wrote: > Dear all, > This proposal suggests adding syntax for a general notion of modifiers, > like the ones we’ve been talking about lately affecting linearity or > matchability of arrows. For example, if linear types and unsaturated > families are accepted as they stand, we would have `Int #1 -> @U Bool` (or > something like that), whereas with this proposal we would have the more > uniform `Int %1 %Unmatchable -> Bool`. > > Since the amount of modifiers is likely to increase in the future, I think > it’s a great idea to agree and reserve such syntax, instead of coming up > with different ways on each proposal. I thus recommend acceptance of this > proposal. > > The proposal itself: > (1) introduces syntax for modifiers in types and defines how to type/kind > check them, > (2) reserved such syntax for other uses in declarations and terms. > > I think the proposal still has its merits only with (1), even though I > lean towards accepting both parts of it. > > Regards, > Alejandro > > On 21 Nov 2020 at 10:07:18, Joachim Breitner > wrote: > >> Dear Committee, >> >> this is your secretary speaking: >> >> A syntax for modifiers >> has been proposed by Richard Eisenberg (this time it’s true) >> https://github.com/ghc-proposals/ghc-proposals/pull/370 >> >> https://dfinity.slack.com/archives/C01BJ73A893/p1605922403340800?thread_ts=1605913774.336600&cid=C01BJ73A893 >> >> I’ll propose Alejandro as the shepherd, as he has looked at i >> t in detail already. >> >> 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 >> > _______________________________________________ > 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 Nov 27 09:46:27 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 27 Nov 2020 10:46:27 +0100 Subject: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance In-Reply-To: References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de> Message-ID: <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de> Hi, Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano Mena: > Dear all, > This proposal suggests adding syntax for a general notion of > modifiers, like the ones we’ve been talking about lately affecting > linearity or matchability of arrows. For example, if linear types and > unsaturated families are accepted as they stand, we would have `Int > #1 -> @U Bool` (or something like that), whereas with this proposal > we would have the more uniform `Int %1 %Unmatchable -> Bool`. > > Since the amount of modifiers is likely to increase in the future, I > think it’s a great idea to agree and reserve such syntax, instead of > coming up with different ways on each proposal. I thus recommend > acceptance of this proposal. > > The proposal itself: > (1) introduces syntax for modifiers in types and defines how to > type/kind check them, > (2) reserved such syntax for other uses in declarations and terms. > > I think the proposal still has its merits only with (1), even though > I lean towards accepting both parts of it. I like the idea of reserving syntax here, but parts of the proposal smell a bit like premature generalization to me. Are we confident that all annotations we eventually would like to use with this feature can be expressed as types of a kind that is an instance of Modifier? Or should we reserve the ability to have annotations that don't fit that model? Would we ever have annotation that may affect phases earlier than than typechecking? What if we want to use (%type e) and (%data e) to help with the SingleNamepace issues? Look like useful annotations to me, but I am not sure if they fit the framework proposed here. The fact that we special-case %1 supports that. The proposal explicitly has to state “No modifier polymorphism!”. But isn't that indication that using the type system to model the various modifiers might be the wrong tool? I wonder if there is a way where the %(…) on it’s own only reserve syntax, and the various uses of that syntax can be disambiguated _statically_ based on the content of …. Not great syntax, because not concise, enough, but morally I’d feel more at ease with Int %(multiplicity Many) -> Int Int %(multiplicity 1) -> Int Int %(multiplicity m) -> Int where multiplicity is a modifier keyword, to express the existing features (including implicit generalization of m). Then we can extend this to Int %oneShot -> Int and Int %(matchability M) -> Int and maybe even foo (%type [a]) -- where foo :: forall a -> () which is a modifier that So at the moment, I am inclined to reject this proposal, until I am convinced that we are not painting ourselves into a “all modifiers are types of special kinds and that’s all the syntax and behaviour we ever need” corner. Minor detail: If we can annotate infix use of the (->) “type operator”, should we also be able to annotate other infix operators, i.e. constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) infixexp ::= lexp {modifier} qop infixexp Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From bravit111 at gmail.com Sat Nov 28 16:13:05 2020 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Sat, 28 Nov 2020 19:13:05 +0300 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: Hi, This is my vote: -- Definitely 'yes' InstanceSigs: yes -- I have a special feeling about this one, -- it is extremely helpful when teaching BangPatterns: yes BinaryLiterals: yes NegativeLiterals: yes HexFloatLiterals: yes NumericUnderscores: yes DeriveDataTypeable: yes DeriveFoldable: yes DeriveFunctor: yes DeriveGeneric: yes DeriveLift: yes DeriveTraversable: yes DerivingStrategies: yes DerivingVia: yes GeneralisedNewtypeDeriving: yes EmptyCase: yes EmptyDataDecls: yes EmptyDataDeriving: yes ExplicitForAll: yes ConstraintKinds: yes DataKinds: yes FlexibleContexts: yes FlexibleInstances: yes GADTSyntax: yes GADTs: yes ImportQualifiedPost: yes MultiParamTypeClasses: yes NamedFieldPuns: yes RankNTypes: yes RecordWildCards: yes ScopedTypeVariables: yes StandaloneDeriving: yes StarIsType: yes TupleSections: yes TypeApplications: yes TypeFamilies: yes TypeOperators: yes TypeSynonymInstances: yes ViewPatterns: yes KindSignatures: yes LambdaCase: yes MonadFailDesugaring: yes -- Not now AllowAmbiguousTypes: no ApplicativeDo: no Arrows: no BlockArguments: no CApiFFI: no CPP: no CUSKs: no ConstrainedClassMethods: no DatatypeContexts: no DefaultSignatures: no DeriveAnyClass: no DisambiguateRecordFields: no DuplicateRecordFields: no ExistentialQuantification: no ExplicitNamespaces: no ExtendedDefaultRules: no ForeignFunctionInterface: no FunctionalDependencies: no GHCForeignImportPrim: no ImplicitParams: no ImpredicativeTypes: no IncoherentInstances: no InterruptibleFFI: no LexicalNegation: no LiberalTypeSynonyms: no LinearTypes: no MagicHash: no MonadComprehensions: no MonoLocalBinds: no MultiWayIf: no NPlusKPatterns: no NamedWildCards: no NoImplicitPrelude: no NoMonomorphismRestriction: no NoPatternGuards: no NoTraditionalRecordSyntax: no NondecreasingIndentation: no NullaryTypeClasses: no NumDecimals: no OverlappingInstances: no OverloadedLabels: no OverloadedLists: no OverloadedStrings: no PackageImports: no ParallelListComp: no PartialTypeSignatures: no PatternSynonyms: no PolyKinds: no PostfixOperators: no QualifiedDo: no QuantifiedConstraints: no QuasiQuotes: no RebindableSyntax: no RecursiveDo: no RoleAnnotations: no Safe: no StandaloneKindSignatures: no StaticPointers: no Strict: no StrictData: no TemplateHaskell: no TemplateHaskellQuotes: no TransformListComp: no Trustworthy: no TypeFamilyDependencies: no TypeInType: no UnboxedSums: no UnboxedTuples: no UndecidableInstances: no UndecidableSuperClasses: no UnicodeSyntax: no UnliftedFFITypes: no UnliftedNewtypes: no Unsafe: no Vitaly вт, 24 нояб. 2020 г. в 12:34, Joachim Breitner : > Dear Committee, > > the requested data (hackage and survey) is in, has been aggregated, > cooked, seasoned and is ready for consumption. 116 extensions are > waiting on your assessment, so time to vote! > > ## Procedure > > Please vote by email to this list, in a response to this thread. > > I want to make tallying easy and automatic, and my code will consider > an extension Foo voted for if you write "Foo: yes" on its own line. > This means you can include rationales, write "Foo: maybe" and "Foo: no" > to remind yourself and others that about where you are, and you can > safely quote other’s mails. For example, if you write: > > ---- begin > example ---- > > Easy ones: > > DeriveFooBar: yes > OverloadedBen: no > > These ones are tricky: > > ImplicitExceptions: yes > I know nobody likes that one, but I do. > > RandomEvaluationOrder: maybe > Not sure about this one, here is why… > > > > Richard wrote: > > DependentHaskell: yes > > Rationale: See my thesis > > I’m not convinced yet, tell me more, so > DependentHaskell: maybe > > ---- end example ---- > > then you have voted for DeriveFooBar and ImplicitExceptions. Only “yes” > matters, “no”, “maybe” and “later” are all ignored. > > I will shortly send my first ballot around. Also see the end of this > mail for a copy’n’paste template. > > You can update your vote as often as you want. Please always send your > full votes (I will only consider your latest email). I encourage you to > do that early, e.g. maybe start with a mail where you list the obvious > yes and nos, and keep some at maybe and then refine. > > The timeline says first votes should be in within two weeks, and then a > bit more to refine. But the earlier the merrier! > > The quota is 8. In particular, if everyone votes (and I hope everyone > will), an extension won’t make it this round if 4 don’t include it. > > ## Data > > Please see > > https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data > for the data, including explanations. It is intentionally not sorted by > the data, as the choice of ranking function would already be quite > influencing. > > You may want to play around with that data, e.g. sort it by your own > criteria etc. I looked long for an online service where I can upload > the data and allow you to explore it, but then I noticed that that's a > bit stupid, since we all probably can do it best with Haskell. > > So I made it easy to load the data into GHCi, see the instructions at > > https://github.com/nomeata/ghc-proposals-stats/blob/master/ext-stats/README.md > which allow you, for example, to do this > > *Main> mapM_ (\E{..} -> Text.Printf.printf "%s: %d\n" ext survey_no) $ > take 10 $ reverse $ sortOn (\E{..} -> survey_no) (M.elems exts) > AllowAmbiguousTypes: 195 > CPP: 192 > IncoherentInstances: 176 > Arrows: 156 > Strict: 153 > ImplicitParams: 147 > UndecidableInstances: 144 > OverlappingInstances: 144 > Unsafe: 139 > TemplateHaskell: 137 > > Of course, if someone wants to upload the data somewhere and share > that, that's also useful. > > > Let me know if some of this doesn't quite work for you, and should be > improved. Maybe we need a web form instead of mails? > > > ## PS: Blank ballot > > To start, you could copy the following into an email > > AllowAmbiguousTypes: maybe > ApplicativeDo: maybe > Arrows: maybe > BangPatterns: maybe > BinaryLiterals: maybe > BlockArguments: maybe > CApiFFI: maybe > CPP: maybe > CUSKs: maybe > ConstrainedClassMethods: maybe > ConstraintKinds: maybe > DataKinds: maybe > DatatypeContexts: maybe > DefaultSignatures: maybe > DeriveAnyClass: maybe > DeriveDataTypeable: maybe > DeriveFoldable: maybe > DeriveFunctor: maybe > DeriveGeneric: maybe > DeriveLift: maybe > DeriveTraversable: maybe > DerivingStrategies: maybe > DerivingVia: maybe > DisambiguateRecordFields: maybe > DuplicateRecordFields: maybe > EmptyCase: maybe > EmptyDataDecls: maybe > EmptyDataDeriving: maybe > ExistentialQuantification: maybe > ExplicitForAll: maybe > ExplicitNamespaces: maybe > ExtendedDefaultRules: maybe > FlexibleContexts: maybe > FlexibleInstances: maybe > ForeignFunctionInterface: maybe > FunctionalDependencies: maybe > GADTSyntax: maybe > GADTs: maybe > GHCForeignImportPrim: maybe > GeneralisedNewtypeDeriving: maybe > HexFloatLiterals: maybe > ImplicitParams: maybe > ImportQualifiedPost: maybe > ImpredicativeTypes: maybe > IncoherentInstances: maybe > InstanceSigs: maybe > InterruptibleFFI: maybe > KindSignatures: maybe > LambdaCase: maybe > LexicalNegation: maybe > LiberalTypeSynonyms: maybe > LinearTypes: maybe > MagicHash: maybe > MonadComprehensions: maybe > MonadFailDesugaring: maybe > MonoLocalBinds: maybe > MultiParamTypeClasses: maybe > MultiWayIf: maybe > NPlusKPatterns: maybe > NamedFieldPuns: maybe > NamedWildCards: maybe > NegativeLiterals: maybe > NoImplicitPrelude: maybe > NoMonomorphismRestriction: maybe > NoPatternGuards: maybe > NoTraditionalRecordSyntax: maybe > NondecreasingIndentation: maybe > NullaryTypeClasses: maybe > NumDecimals: maybe > NumericUnderscores: maybe > OverlappingInstances: maybe > OverloadedLabels: maybe > OverloadedLists: maybe > OverloadedStrings: maybe > PackageImports: maybe > ParallelListComp: maybe > PartialTypeSignatures: maybe > PatternSynonyms: maybe > PolyKinds: maybe > PostfixOperators: maybe > QualifiedDo: maybe > QuantifiedConstraints: maybe > QuasiQuotes: maybe > RankNTypes: maybe > RebindableSyntax: maybe > RecordWildCards: maybe > RecursiveDo: maybe > RoleAnnotations: maybe > Safe: maybe > ScopedTypeVariables: maybe > StandaloneDeriving: maybe > StandaloneKindSignatures: maybe > StarIsType: maybe > StaticPointers: maybe > Strict: maybe > StrictData: maybe > TemplateHaskell: maybe > TemplateHaskellQuotes: maybe > TransformListComp: maybe > Trustworthy: maybe > TupleSections: maybe > TypeApplications: maybe > TypeFamilies: maybe > TypeFamilyDependencies: maybe > TypeInType: maybe > TypeOperators: maybe > TypeSynonymInstances: maybe > UnboxedSums: maybe > UnboxedTuples: maybe > UndecidableInstances: maybe > UndecidableSuperClasses: maybe > UnicodeSyntax: maybe > UnliftedFFITypes: maybe > UnliftedNewtypes: maybe > Unsafe: maybe > ViewPatterns: maybe > > > > > -- > 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 Sun Nov 29 10:48:49 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 29 Nov 2020 10:48:49 +0000 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: My votes: ## Uncontroversial extensions I've been writing code with most of these enabled by default for quite some time now. It saves a lot of LANGUAGE pragmas. Other than RecordWildCards I doubt any of these are controversial. BangPatterns: yes BinaryLiterals: yes DataKinds: yes DeriveDataTypeable: yes DeriveGeneric: yes EmptyCase: yes ExistentialQuantification: yes FlexibleContexts: yes FlexibleInstances: yes GADTs: yes GeneralisedNewtypeDeriving: yes LambdaCase: yes MultiParamTypeClasses: yes MultiWayIf: yes NoMonomorphismRestriction: yes OverloadedStrings: yes PatternSynonyms: yes RankNTypes: yes RecordWildCards: yes ScopedTypeVariables: yes StandaloneDeriving: yes TupleSections: yes TypeFamilies: yes TypeSynonymInstances: yes NondecreasingIndentation: yes ConstrainedClassMethods: yes ConstraintKinds: yes DefaultSignatures: yes DeriveFoldable: yes DeriveFunctor: yes DeriveTraversable: yes DeriveAnyClass: yes EmptyDataDecls: yes EmptyDataDeriving: yes HexFloatLiterals: yes ImportQualifiedPost: yes InstanceSigs: yes KindSignatures: yes LiberalTypeSynonyms: yes NamedFieldPuns: yes (I don't personally like this, but I can't justify having RecordWildcards but not having this) NegativeLiterals: yes NumDecimals: yes PolyKinds: yes PostfixOperators: yes UnicodeSyntax: yes ## Extensions that are implied by others, or are irrelevant: GADTSyntax: yes ExplicitForAll: yes MonadFailDesugaring: irrelevant MonoLocalBinds: yes ## Extensions that are deprecated or exist for legacy reasons: DatatypeContexts: no NPlusKPatterns: no CUSKs: no NoPatternGuards: no ForeignFunctionInterface: yes (already implied by Haskell2010, why do we have this but NoPatternGuards?) NullaryTypeClasses: no OverlappingInstances: no IncoherentInstances: no TypeInType: no ## No to extensions that are too new to include in GHC2021: QualifiedDo: no LinearTypes: no BlockArguments: no LexicalNegation: no QuantifiedConstraints: no StandaloneKindSignatures: no StarIsType: no ## No to extensions that are opt-in by design: ApplicativeDo: no (can lead to non-deterministic behaviour with non-rule-abiding Applicative instances) PackageImports: no CPP: no DeriveLift: no (only makes sense with TemplateHaskell, which is opt-in) TemplateHaskell: no TemplateHaskellQuotes: no QuasiQuotes: no RebindableSyntax: no Safe: no Strict: no StrictData: no Trustworthy: no Unsafe: no ExtendedDefaultRules: no NoImplicitPrelude: no ## No to unsafe extensions: UndecidableInstances: no UndecidableSuperClasses: no ## No to low-level extensions, not intended to be on by default: UnboxedTuples: no UnboxedSums: no MagicHash: no UnliftedFFITypes: no UnliftedNewtypes: no GHCForeignImportPrim: no InterruptibleFFI: no ## No to record-related extensions Records are in flux, let's not do any of this in GHC2021. DisambiguateRecordFields: no DuplicateRecordFields: no NoTraditionalRecordSyntax: no OverloadedLabels: no ## The rest That leaves some tricky ones, I'm putting all these as "no" or "maybe"; we could conservatively just say "no" to all of them. I'm voting NO on these: Arrows: no (not widely used) ImplicitParams: no (not widely used; questionable semantics; functionality available with reflection package) ImpredicativeTypes: no (I don't think we want this on by default, right?) ParallelListComp: no (not widely used, most uses are covered by zip) StaticPointers: no (quite a niche extension, only really useful with Distributed Haskell) TransformListComp: no (not widely used) ViewPatterns: no (not widely used, and in my opinion not a good design) I'm undecided on these: AllowAmbiguousTypes: maybe TypeApplications: maybe CApiFFI: maybe (harmless, but a bit niche) DerivingVia: maybe (not very widely-used, quite new) DerivingStrategies: maybe (not very widely-used, quite new) FunctionalDependencies: maybe (slightly inclined to "no", given the overlap with TypeFamilies and the lack of widespread usage) ExplicitNamespaces: maybe (might change, so defer?) MonadComprehensions: maybe (does this make error messages worse?) PartialTypeSignatures: maybe NamedWildCards: maybe NumericUnderscores: maybe OverloadedLists: maybe (impact on error messages?) RecursiveDo: maybe (but introduced by a keyword so relatively harmless) RoleAnnotations: maybe (not widely used, but when you need it you need it) TypeFamilyDependencies: maybe (not widely used, but when you need it you need it) TypeOperators: maybe On Tue, 24 Nov 2020 at 09:34, Joachim Breitner wrote: > Dear Committee, > > the requested data (hackage and survey) is in, has been aggregated, > cooked, seasoned and is ready for consumption. 116 extensions are > waiting on your assessment, so time to vote! > > ## Procedure > > Please vote by email to this list, in a response to this thread. > > I want to make tallying easy and automatic, and my code will consider > an extension Foo voted for if you write "Foo: yes" on its own line. > This means you can include rationales, write "Foo: maybe" and "Foo: no" > to remind yourself and others that about where you are, and you can > safely quote other’s mails. For example, if you write: > > ---- begin > example ---- > > Easy ones: > > DeriveFooBar: yes > OverloadedBen: no > > These ones are tricky: > > ImplicitExceptions: yes > I know nobody likes that one, but I do. > > RandomEvaluationOrder: maybe > Not sure about this one, here is why… > > > > Richard wrote: > > DependentHaskell: yes > > Rationale: See my thesis > > I’m not convinced yet, tell me more, so > DependentHaskell: maybe > > ---- end example ---- > > then you have voted for DeriveFooBar and ImplicitExceptions. Only “yes” > matters, “no”, “maybe” and “later” are all ignored. > > I will shortly send my first ballot around. Also see the end of this > mail for a copy’n’paste template. > > You can update your vote as often as you want. Please always send your > full votes (I will only consider your latest email). I encourage you to > do that early, e.g. maybe start with a mail where you list the obvious > yes and nos, and keep some at maybe and then refine. > > The timeline says first votes should be in within two weeks, and then a > bit more to refine. But the earlier the merrier! > > The quota is 8. In particular, if everyone votes (and I hope everyone > will), an extension won’t make it this round if 4 don’t include it. > > ## Data > > Please see > > https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data > for the data, including explanations. It is intentionally not sorted by > the data, as the choice of ranking function would already be quite > influencing. > > You may want to play around with that data, e.g. sort it by your own > criteria etc. I looked long for an online service where I can upload > the data and allow you to explore it, but then I noticed that that's a > bit stupid, since we all probably can do it best with Haskell. > > So I made it easy to load the data into GHCi, see the instructions at > > https://github.com/nomeata/ghc-proposals-stats/blob/master/ext-stats/README.md > which allow you, for example, to do this > > *Main> mapM_ (\E{..} -> Text.Printf.printf "%s: %d\n" ext survey_no) $ > take 10 $ reverse $ sortOn (\E{..} -> survey_no) (M.elems exts) > AllowAmbiguousTypes: 195 > CPP: 192 > IncoherentInstances: 176 > Arrows: 156 > Strict: 153 > ImplicitParams: 147 > UndecidableInstances: 144 > OverlappingInstances: 144 > Unsafe: 139 > TemplateHaskell: 137 > > Of course, if someone wants to upload the data somewhere and share > that, that's also useful. > > > Let me know if some of this doesn't quite work for you, and should be > improved. Maybe we need a web form instead of mails? > > > ## PS: Blank ballot > > To start, you could copy the following into an email > > AllowAmbiguousTypes: maybe > ApplicativeDo: maybe > Arrows: maybe > BangPatterns: maybe > BinaryLiterals: maybe > BlockArguments: maybe > CApiFFI: maybe > CPP: maybe > CUSKs: maybe > ConstrainedClassMethods: maybe > ConstraintKinds: maybe > DataKinds: maybe > DatatypeContexts: maybe > DefaultSignatures: maybe > DeriveAnyClass: maybe > DeriveDataTypeable: maybe > DeriveFoldable: maybe > DeriveFunctor: maybe > DeriveGeneric: maybe > DeriveLift: maybe > DeriveTraversable: maybe > DerivingStrategies: maybe > DerivingVia: maybe > DisambiguateRecordFields: maybe > DuplicateRecordFields: maybe > EmptyCase: maybe > EmptyDataDecls: maybe > EmptyDataDeriving: maybe > ExistentialQuantification: maybe > ExplicitForAll: maybe > ExplicitNamespaces: maybe > ExtendedDefaultRules: maybe > FlexibleContexts: maybe > FlexibleInstances: maybe > ForeignFunctionInterface: maybe > FunctionalDependencies: maybe > GADTSyntax: maybe > GADTs: maybe > GHCForeignImportPrim: maybe > GeneralisedNewtypeDeriving: maybe > HexFloatLiterals: maybe > ImplicitParams: maybe > ImportQualifiedPost: maybe > ImpredicativeTypes: maybe > IncoherentInstances: maybe > InstanceSigs: maybe > InterruptibleFFI: maybe > KindSignatures: maybe > LambdaCase: maybe > LexicalNegation: maybe > LiberalTypeSynonyms: maybe > LinearTypes: maybe > MagicHash: maybe > MonadComprehensions: maybe > MonadFailDesugaring: maybe > MonoLocalBinds: maybe > MultiParamTypeClasses: maybe > MultiWayIf: maybe > NPlusKPatterns: maybe > NamedFieldPuns: maybe > NamedWildCards: maybe > NegativeLiterals: maybe > NoImplicitPrelude: maybe > NoMonomorphismRestriction: maybe > NoPatternGuards: maybe > NoTraditionalRecordSyntax: maybe > NondecreasingIndentation: maybe > NullaryTypeClasses: maybe > NumDecimals: maybe > NumericUnderscores: maybe > OverlappingInstances: maybe > OverloadedLabels: maybe > OverloadedLists: maybe > OverloadedStrings: maybe > PackageImports: maybe > ParallelListComp: maybe > PartialTypeSignatures: maybe > PatternSynonyms: maybe > PolyKinds: maybe > PostfixOperators: maybe > QualifiedDo: maybe > QuantifiedConstraints: maybe > QuasiQuotes: maybe > RankNTypes: maybe > RebindableSyntax: maybe > RecordWildCards: maybe > RecursiveDo: maybe > RoleAnnotations: maybe > Safe: maybe > ScopedTypeVariables: maybe > StandaloneDeriving: maybe > StandaloneKindSignatures: maybe > StarIsType: maybe > StaticPointers: maybe > Strict: maybe > StrictData: maybe > TemplateHaskell: maybe > TemplateHaskellQuotes: maybe > TransformListComp: maybe > Trustworthy: maybe > TupleSections: maybe > TypeApplications: maybe > TypeFamilies: maybe > TypeFamilyDependencies: maybe > TypeInType: maybe > TypeOperators: maybe > TypeSynonymInstances: maybe > UnboxedSums: maybe > UnboxedTuples: maybe > UndecidableInstances: maybe > UndecidableSuperClasses: maybe > UnicodeSyntax: maybe > UnliftedFFITypes: maybe > UnliftedNewtypes: maybe > Unsafe: maybe > ViewPatterns: maybe > > > > > -- > 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 Sun Nov 29 11:12:25 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 29 Nov 2020 11:12:25 +0000 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: On Wed, 25 Nov 2020 at 11:21, Spiwack, Arnaud wrote: > > ## OverloadedX > > These extensions can confuse type inference, yielding ambiguous type > variables message. And as much as I like them, I don't think it's safe > to include them yet. Not until we have a reasonable story for > defaulting literals. > > OverloadedLabels: no > OverloadedLists: no > OverloadedStrings: no > For what it's worth, I've been writing code with OverloadedStrings for several years now and in my experience it rarely causes a problem, even for beginners. The context almost always provides enough information to resolve the ambiguity. (admittedly I'm slightly surprised by this too, but experience has convinced me) I don't have much experience with OverloadedLists, but I'd be prepared to believe that it's a similar story there too. OverloadedLabels is really a new syntactic form and doesn't fall into the same category as the other two here. Cheers Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Nov 29 11:24:33 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 29 Nov 2020 12:24:33 +0100 Subject: [ghc-steering-committee] #380 GHC2021: Current status In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: Dear Comittee, for those who enjoy a little bit of random statistics on a weekend, let’s see how we are doing on the GHC20201 front. We got 5 votes already (thanks!). The table at https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data is updated to reflect these votes, and sorted by number of votes received. If we’d stop voting now, and if the comittee were indeed only these 5 people, we’d accept everything with 4 or 5 votes. That would be these 35 extensions: *Main> putStrLn $ intercalate ", " $ sort [ ext | E{..} <- M.elems exts, votes >= 4] BangPatterns, BinaryLiterals, ConstraintKinds, DataKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveLift, DeriveTraversable, DerivingStrategies, EmptyCase, EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts, FlexibleInstances, GADTSyntax, GADTs, GeneralisedNewtypeDeriving, HexFloatLiterals, InstanceSigs, KindSignatures, LambdaCase, MultiParamTypeClasses, NamedFieldPuns, NegativeLiterals, NumericUnderscores, RecordWildCards, StandaloneDeriving, TupleSections, TypeApplications, TypeFamilies, TypeOperators, ViewPatterns Of these, the most conlater on.tentious are related to literals, followed by RecordWildCards: *Main Data.List> mapM_ putStrLn [ printf "%s: %0.2f" ext cont | E{..} <- M.elems exts, votes >= 4, survey_yes > 0, let cont = fromIntegral survey_no / fromIntegral survey_yes, then sortOn by Down cont, then take 3 ] NegativeLiterals: 0.58 HexFloatLiterals: 0.52 RecordWildCards: 0.39 (I think this is the first time in my life that I am using -XTransformListComp. Quite neat actually, maybe I need to change my vote here ;-) …) A number of extensions already have 4 or more “no”-votes and (pending changes to the ballots), are out: *Main Data.List> putStrLn $ intercalate ", " $ sort [ ext | E{..} <- M.elems exts, votes_total - votes >= 4] AllowAmbiguousTypes, ApplicativeDo, Arrows, BlockArguments, CApiFFI, CPP, CUSKs, DatatypeContexts, DefaultSignatures, DisambiguateRecordFields, DuplicateRecordFields, ExplicitNamespaces, ExtendedDefaultRules, ForeignFunctionInterface, FunctionalDependencies, GHCForeignImportPrim, ImplicitParams, ImpredicativeTypes, IncoherentInstances, InterruptibleFFI, LexicalNegation, LiberalTypeSynonyms, LinearTypes, MagicHash, MonadComprehensions, MultiWayIf, NPlusKPatterns, NamedWildCards, NoImplicitPrelude, NoPatternGuards, NoTraditionalRecordSyntax, NullaryTypeClasses, OverlappingInstances, OverloadedLabels, OverloadedLists, OverloadedStrings, PackageImports, ParallelListComp, PartialTypeSignatures, PatternSynonyms, QualifiedDo, QuantifiedConstraints, QuasiQuotes, RebindableSyntax, RecursiveDo, RoleAnnotations, Safe, StandaloneKindSignatures, StaticPointers, Strict, StrictData, TemplateHaskell, TemplateHaskellQuotes, TransformListComp, Trustworthy, TypeFamilyDependencies, TypeInType, UnboxedSums, UnboxedTuples, UndecidableInstances, UndecidableSuperClasses, UnliftedFFITypes, UnliftedNewtypes, Unsafe The most popular of these is (and I don’t even have to look that up) OverloadedStrings. I expect we might have the most discussion around that one. *Main Data.List> mapM_ putStrLn [ printf "%s: %0.2f" ext pop | E{..} <- M.elems exts, votes_total - votes >= 4, let pop = fromIntegral survey_yes / fromIntegral survey_total , then sortOn by Down pop, then take 5] OverloadedStrings: 0.45 MultiWayIf: 0.22 FunctionalDependencies: 0.17 DefaultSignatures: 0.16 PatternSynonyms: 0.14 In terms of process it has become apparent that I should have been more careful about excluding deprecated extensions from the ballots, to avoid confusion. If the final tally on them will look confused, we’ll still apply common sense (e.g. ForeignFunctionInterface is implied by Haskell2010, as Simon Marlow points out, and we won't “accidentially” remove it.) Anyways, that’s just a peek preview; with less than half of the votes in, a few things can still change. Keep it coming! Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From marlowsd at gmail.com Sun Nov 29 11:40:25 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Sun, 29 Nov 2020 11:40:25 +0000 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: On Wed, 25 Nov 2020 at 11:21, Spiwack, Arnaud wrote: > PostfixOperators: maybe > I'd like to make a case for this extension, on the grounds that it's a complete no-brainer. The name "PostfixOperators" makes it sound a lot more scary than it actually is. In fact it's just a tiny generalisation to the definition of left sections. You could almost regard it as a typo in the Haskell report - if it had been noticed that this rule was unnecessarily restrictive, I'm fairly sure it would have been fixed at the time. https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PostfixOperators Cheers Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Sun Nov 29 20:14:47 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Sun, 29 Nov 2020 21:14:47 +0100 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: El dom, 29 nov 2020 a las 12:12, Simon Marlow () escribió: > On Wed, 25 Nov 2020 at 11:21, Spiwack, Arnaud > wrote: > >> >> ## OverloadedX >> >> These extensions can confuse type inference, yielding ambiguous type >> variables message. And as much as I like them, I don't think it's safe >> to include them yet. Not until we have a reasonable story for >> defaulting literals. >> >> OverloadedLabels: no >> OverloadedLists: no >> OverloadedStrings: no >> > > For what it's worth, I've been writing code with OverloadedStrings for > several years now and in my experience it rarely causes a problem, even for > beginners. The context almost always provides enough information to resolve > the ambiguity. (admittedly I'm slightly surprised by this too, but > experience has convinced me) > > I don't have much experience with OverloadedLists, but I'd be prepared to > believe that it's a similar story there too. > Adding to this, I think that both OverloadedStrings and OverloadedLists go very well with the idea of overloaded literals story that Haskell already has for numbers. Regards, Alejandro > OverloadedLabels is really a new syntactic form and doesn't fall into the > same category as the other two here. > > Cheers > Simon > _______________________________________________ > 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 Sun Nov 29 22:12:44 2020 From: eric at seidel.io (Eric Seidel) Date: Sun, 29 Nov 2020 17:12:44 -0500 Subject: [ghc-steering-committee] =?utf-8?q?=23370=3A_Syntax_for_Modifiers?= =?utf-8?q?=2C_Recommendation=3A_Acceptance?= In-Reply-To: <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de> References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de> <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de> Message-ID: <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com> I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself. On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote: > Hi, > > Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano > Mena: > > Dear all, > > This proposal suggests adding syntax for a general notion of > > modifiers, like the ones we’ve been talking about lately affecting > > linearity or matchability of arrows. For example, if linear types and > > unsaturated families are accepted as they stand, we would have `Int > > #1 -> @U Bool` (or something like that), whereas with this proposal > > we would have the more uniform `Int %1 %Unmatchable -> Bool`. > > > > Since the amount of modifiers is likely to increase in the future, I > > think it’s a great idea to agree and reserve such syntax, instead of > > coming up with different ways on each proposal. I thus recommend > > acceptance of this proposal. > > > > The proposal itself: > > (1) introduces syntax for modifiers in types and defines how to > > type/kind check them, > > (2) reserved such syntax for other uses in declarations and terms. > > > > I think the proposal still has its merits only with (1), even though > > I lean towards accepting both parts of it. > > I like the idea of reserving syntax here, but parts of the proposal > smell a bit like premature generalization to me. Are we confident that > all annotations we eventually would like to use with this feature can > be expressed as types of a kind that is an instance of Modifier? Or > should we reserve the ability to have annotations that don't fit that > model? > > Would we ever have annotation that may affect phases earlier than than > typechecking? What if we want to use (%type e) and (%data e) to help > with the SingleNamepace issues? Look like useful annotations to me, but > I am not sure if they fit the framework proposed here. > > The fact that we special-case %1 supports that. > > The proposal explicitly has to state “No modifier polymorphism!”. But > isn't that indication that using the type system to model the various > modifiers might be the wrong tool? > > I wonder if there is a way where the %(…) on it’s own only reserve > syntax, and the various uses of that syntax can be disambiguated > _statically_ based on the content of …. > > Not great syntax, because not concise, enough, but morally I’d feel > more at ease with > > Int %(multiplicity Many) -> Int > Int %(multiplicity 1) -> Int > Int %(multiplicity m) -> Int > > where multiplicity is a modifier keyword, to express the existing > features (including implicit generalization of m). Then we can extend > this to > > Int %oneShot -> Int > > and > > Int %(matchability M) -> Int > > and maybe even > > foo (%type [a]) -- where foo :: forall a -> () > > which is a modifier that > > > So at the moment, I am inclined to reject this proposal, until I am > convinced that we are not painting ourselves into a “all modifiers are > types of special kinds and that’s all the syntax and behaviour we ever > need” corner. > > Minor detail: If we can annotate infix use of the (->) “type operator”, > should we also be able to annotate other infix operators, i.e. > > constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) > infixexp ::= lexp {modifier} qop infixexp > > > > 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 Sun Nov 29 23:17:05 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun, 29 Nov 2020 15:17:05 -0800 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: Hello, these took me way too long :) Here we go: *Module System=============* ImportQualifiedPost: yes -- ^ This is relatively new, but it seems quite simple, and it does make -- things read nicer. -- | These are only needed under very special circumstances, -- so it's good to be explicit: PackageImports: no NoImplicitPrelude: no *Notation========* BlockArguments: yes -- ^ I use this all the time. MultiWayIf: yes -- ^ This is nice on occasion, and it does not seem to conflict with -- anything. Certainly nicer than the alternative `case () of _ | ... `: LambdaCase: maybe -- ^ Personally I don't use this, but I know a lot of folks like it, -- so I'd be OK with it being enabled. -- | The various literal notations seem useful when you need them -- and don't conflict with anything. BinaryLiterals: yes HexFloatLiterals: yes NumericUnderscores: yes NumDecimals: maybe -- ^ | Not too sure about this last one, I've never used, but it -- I could see it being useful on occasion. OverloadedStrings: yes -- ^ | I use this a lot, and would be OK with it being on all the time. OverloadedLists: maybe -- | ^ I've never used this, but I could see it potentially being useful. OverloadedLabels: no -- | ^ This one seems for experimenting with various new features -- (e.g., record selectors), so it seems reasonable to turn it on only -- when it is needed. EmptyCase: maybe -- ^ Seems like a nicer notation for forcing `Void` values. -- I agree that it is odd that it is strict. OTOH, it'd be quite useless -- if it was lazy, so I could go either way. -- | I haven't really used any of those, so I could go either way: PostfixOperators: maybe LexicalNegation: maybe UnicodeSyntax: maybe NegativeLiterals: no -- ^ It seems that `LexicalNegation` might be a nicer way to do this? TupleSections: maybe -- ^ I don't use this often, but I'd use it more often if it was on by default. ImplicitParams: no -- ^ I find these quite useful on occasion, but it does seem reasonable -- to be explicit when you need them. ParallelListComp: yes -- ^ I find these to be a very nice generalization to list comprehensions -- that makes some code way more readable than using `zip/zipWith`, just -- like comprehensions are often nicer than `map` or `concatMap` RecursiveDo: yes -- ^ Seems useful when you need it, and it doesn't clash with anything, -- so I see no reason to not have it on all the time. TransformListComp: no -- ^ In my mind these are just a bit too much syntactic sugar. Arrows: no -- ^ It's not used a lot, not terribly useful and overall feels "clunky". ApplicativeDo: maybe -- ^ I think the core of this extension is really useful, -- but I would prefer a simpler syntactic version of it, -- without the various transformations assuming that some laws hold. QualifiedDo: no -- ^ This is neat, but it is too new to be on by default. MonadComprehensions: maybe -- ^ I never really use these. -- On occasion I've wanted `ApplicativeComprehensions` though. NondecreasingIndentation: no -- ^ This always felt like a hack to me. RebindableSyntax: no -- ^ This is a very special case thing ExplicitNamespaces: maybe -- ^ We need this if we also want pattern synonyms. *Data Types==========* DatatypeContexts: no -- ^ These are not really used much, and usually don't do what people expect. ExistentialQuantification: yes -- ^ This is quite useful, and has been around for a long time. EmptyDataDecls: yes -- ^ Seems more consistent to allow this RoleAnnotations: no -- ^ This only makes sense with `GeneralisedNewtypeDeriving` which -- I don't think should be on by default. StrictData: no -- ^ This is very unHaskell :) GADTSyntax: maybe -- ^ I personally don't use this, but I know some folks like to write -- their `data` declarations in this notation. GADTs: no -- ^ These can be useful, but it seems reasonable to enable them when -- you need them, as they bring in quite a lot of machinery with them. *Patterns and Guards===================* BangPatterns: yes -- ^ Seem to be useful, and quite popular. ViewPatterns: yes -- ^ Useful on occasion, and I don't think calling out the extension -- explicitly helps anyone. PatternSynonyms: maybe -- ^ These are quite useful, but I am not sure how stable is theiry design. NoPatternGuards: no -- ^ Conflicts with Haskell2010 NPlusKPatterns: no -- ^ Conflicts with Haskell2010 *Records=======* -- | I find these two very useful when working with records, -- especially large ones, and declaring the extension really adds no -- information: NamedFieldPuns: yes RecordWildCards: yes -- | These seem to be largely about experimenting with new record system, and I don't think any of them are quite ready to be on by default: DisambiguateRecordFields: no DuplicateRecordFields: no NoTraditionalRecordSyntax: no *Deriving=======* -- | Declaring these as extensions explicitly adds very little information. DeriveGeneric: yes DeriveLift: yes DeriveDataTypeable: yes EmptyDataDeriving: yes -- ^ Useful for consistency StandaloneDeriving: yes -- ^ I find this quite useful on occasion, and does not conflict with anything -- | I think the rest of the deriving extensions are not particularly orthogonal at the moment, so I don't think we should have them on by default, at least not yet, even though I find some of them quite useful. DeriveFunctor: no DeriveFoldable: no DeriveTraversable: no DerivingStrategies: no DerivingVia: no GeneralisedNewtypeDeriving: no DeriveAnyClass: no *Class System============* MultiParamTypeClasses: yes -- ^ Seems like a natural extension and does not really conflict with anything NullaryTypeClasses: yes -- ^ Seems like a natural extension and does not really conflict with anything ConstraintKinds: maybe -- ^ These seem like a very nice fit with the rest of the kind system, -- so I think we can enable them. The reason I wrote `maybe` is due to -- the confusion between constraints and tuples. -- | These 3 seem to be quite common. There are some reasons to be careful -- when writing `FlexibleInstances`, but it seems that having the extension -- does not really help much with those. TypeSynonymInstances: yes FlexibleInstances: yes FlexibleContexts: yes -- | I haven't really used these much, so I don't have a strong opinion: ConstrainedClassMethods: maybe DefaultSignatures: maybe InstanceSigs: maybe ExtendedDefaultRules: maybe FunctionalDependencies: no -- ^ While I quite like the general idea here, I don't think we should -- have these on by default. QuantifiedConstraints: no -- ^ These seem neat, but are quite new to be on by default. UndecidableInstances: no -- ^ These are a very special case, and ideally should be specified -- on a per instance basis. IncoherentInstances: no -- ^ Why do we even have this? :) UndecidableSuperClasses: no -- ^ These are a very special case. OverlappingInstances: no -- ^ This has been subsumed by per-instance pragmas *Types=====* RankNTypes: yes -- ^ These are useful and have been around for a long time. The design -- seems to work well. -- | These two seem useful, but I am not sure if they should be on by default. -- If so, though, it makes sense to have both of them on. StandaloneKindSignatures: maybe KindSignatures: maybe LiberalTypeSynonyms: maybe -- ^ These seem useful, but can lead to some rather confusing situations -- where types that look "normal" don't behave as you'd expect -- (e..g, writing `[T]` fails because `T` happens to have `forall` in it) -- | These two go together and seem quite useful, especially when writing -- local type signatures. ScopedTypeVariables: yes ExplicitForAll: yes AllowAmbiguousTypes: no -- ^ Often these are unintentional, and are due to a mistake in the program. ImpredicativeTypes: no -- ^ These are being currently redesigned, so not ready. MonoLocalBinds: maybe -- ^ I don't know if this one is on by default or not already... NoMonomorphismRestriction: yes -- ^ The monomrphism restriction seems to cause a lot of confusion, and I -- am not sure that it's helped that much with efficiency -- | Doesn't really seem to be commonly used. PartialTypeSignatures: no NamedWildCards: no LinearTypes: no -- ^ Too new to be standardized TypeApplications: no -- ^ This one is quite useful, bit it seems that its design and how many users -- understand it don't match, so maybe there is more work to be done. -- | These are all related to type-level programming, and while I don't think -- they should be on by default, it might be useful to have a single flag that -- turns a bunch of them on. PolyKinds: no TypeOperators: no StarIsType: maybe TypeFamilies: no TypeFamilyDependencies: no DataKinds: no *FFI===* I don't think the FFI should be on by default, as it is used relatively infrequently, although it might be nice if `ForeignFunctionInterface` implied `CApiFFI` ForeignFunctionInterface: no CApiFFI: no GHCForeignImportPrim: no InterruptibleFFI: no UnliftedFFITypes: no StaticPointers: no *Low Level=========* These are for low-level hacking, so I don't think they should be on by default. However, I wouldn't mind having a flag that enabled all of them with a single extension (e.g., `UnliftedTypes`) UnboxedSums: no UnboxedTuples: no MagicHash: no UnliftedNewtypes: no *Macros======* CPP: no This is quite specialized, so it seems reasonable to be explicit about it. I don't think these should be on by default, but I wouldn't mind it if `TemplateHaskell` implied `QuasiQuotes`, so that when I use TH I just need to turn on a single extension.: TemplateHaskell: no TemplateHaskellQuotes: no QuasiQuotes: no *Other=====* -- | These are part of Safe Haskell and are there to be written explicitly Unsafe: no Safe: no Trustworthy: no Strict: no -- ^ This is not Haskell! :-) *Obsolete/Deprecated===================* CUSKs: no TypeInType: no MonadFailDesugaring: maybe On Tue, Nov 24, 2020 at 1:34 AM Joachim Breitner wrote: > Dear Committee, > > the requested data (hackage and survey) is in, has been aggregated, > cooked, seasoned and is ready for consumption. 116 extensions are > waiting on your assessment, so time to vote! > > ## Procedure > > Please vote by email to this list, in a response to this thread. > > I want to make tallying easy and automatic, and my code will consider > an extension Foo voted for if you write "Foo: yes" on its own line. > This means you can include rationales, write "Foo: maybe" and "Foo: no" > to remind yourself and others that about where you are, and you can > safely quote other’s mails. For example, if you write: > > ---- begin > example ---- > > Easy ones: > > DeriveFooBar: yes > OverloadedBen: no > > These ones are tricky: > > ImplicitExceptions: yes > I know nobody likes that one, but I do. > > RandomEvaluationOrder: maybe > Not sure about this one, here is why… > > > > Richard wrote: > > DependentHaskell: yes > > Rationale: See my thesis > > I’m not convinced yet, tell me more, so > DependentHaskell: maybe > > ---- end example ---- > > then you have voted for DeriveFooBar and ImplicitExceptions. Only “yes” > matters, “no”, “maybe” and “later” are all ignored. > > I will shortly send my first ballot around. Also see the end of this > mail for a copy’n’paste template. > > You can update your vote as often as you want. Please always send your > full votes (I will only consider your latest email). I encourage you to > do that early, e.g. maybe start with a mail where you list the obvious > yes and nos, and keep some at maybe and then refine. > > The timeline says first votes should be in within two weeks, and then a > bit more to refine. But the earlier the merrier! > > The quota is 8. In particular, if everyone votes (and I hope everyone > will), an extension won’t make it this round if 4 don’t include it. > > ## Data > > Please see > > https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data > for the data, including explanations. It is intentionally not sorted by > the data, as the choice of ranking function would already be quite > influencing. > > You may want to play around with that data, e.g. sort it by your own > criteria etc. I looked long for an online service where I can upload > the data and allow you to explore it, but then I noticed that that's a > bit stupid, since we all probably can do it best with Haskell. > > So I made it easy to load the data into GHCi, see the instructions at > > https://github.com/nomeata/ghc-proposals-stats/blob/master/ext-stats/README.md > which allow you, for example, to do this > > *Main> mapM_ (\E{..} -> Text.Printf.printf "%s: %d\n" ext survey_no) $ > take 10 $ reverse $ sortOn (\E{..} -> survey_no) (M.elems exts) > AllowAmbiguousTypes: 195 > CPP: 192 > IncoherentInstances: 176 > Arrows: 156 > Strict: 153 > ImplicitParams: 147 > UndecidableInstances: 144 > OverlappingInstances: 144 > Unsafe: 139 > TemplateHaskell: 137 > > Of course, if someone wants to upload the data somewhere and share > that, that's also useful. > > > Let me know if some of this doesn't quite work for you, and should be > improved. Maybe we need a web form instead of mails? > > > ## PS: Blank ballot > > To start, you could copy the following into an email > > AllowAmbiguousTypes: maybe > ApplicativeDo: maybe > Arrows: maybe > BangPatterns: maybe > BinaryLiterals: maybe > BlockArguments: maybe > CApiFFI: maybe > CPP: maybe > CUSKs: maybe > ConstrainedClassMethods: maybe > ConstraintKinds: maybe > DataKinds: maybe > DatatypeContexts: maybe > DefaultSignatures: maybe > DeriveAnyClass: maybe > DeriveDataTypeable: maybe > DeriveFoldable: maybe > DeriveFunctor: maybe > DeriveGeneric: maybe > DeriveLift: maybe > DeriveTraversable: maybe > DerivingStrategies: maybe > DerivingVia: maybe > DisambiguateRecordFields: maybe > DuplicateRecordFields: maybe > EmptyCase: maybe > EmptyDataDecls: maybe > EmptyDataDeriving: maybe > ExistentialQuantification: maybe > ExplicitForAll: maybe > ExplicitNamespaces: maybe > ExtendedDefaultRules: maybe > FlexibleContexts: maybe > FlexibleInstances: maybe > ForeignFunctionInterface: maybe > FunctionalDependencies: maybe > GADTSyntax: maybe > GADTs: maybe > GHCForeignImportPrim: maybe > GeneralisedNewtypeDeriving: maybe > HexFloatLiterals: maybe > ImplicitParams: maybe > ImportQualifiedPost: maybe > ImpredicativeTypes: maybe > IncoherentInstances: maybe > InstanceSigs: maybe > InterruptibleFFI: maybe > KindSignatures: maybe > LambdaCase: maybe > LexicalNegation: maybe > LiberalTypeSynonyms: maybe > LinearTypes: maybe > MagicHash: maybe > MonadComprehensions: maybe > MonadFailDesugaring: maybe > MonoLocalBinds: maybe > MultiParamTypeClasses: maybe > MultiWayIf: maybe > NPlusKPatterns: maybe > NamedFieldPuns: maybe > NamedWildCards: maybe > NegativeLiterals: maybe > NoImplicitPrelude: maybe > NoMonomorphismRestriction: maybe > NoPatternGuards: maybe > NoTraditionalRecordSyntax: maybe > NondecreasingIndentation: maybe > NullaryTypeClasses: maybe > NumDecimals: maybe > NumericUnderscores: maybe > OverlappingInstances: maybe > OverloadedLabels: maybe > OverloadedLists: maybe > OverloadedStrings: maybe > PackageImports: maybe > ParallelListComp: maybe > PartialTypeSignatures: maybe > PatternSynonyms: maybe > PolyKinds: maybe > PostfixOperators: maybe > QualifiedDo: maybe > QuantifiedConstraints: maybe > QuasiQuotes: maybe > RankNTypes: maybe > RebindableSyntax: maybe > RecordWildCards: maybe > RecursiveDo: maybe > RoleAnnotations: maybe > Safe: maybe > ScopedTypeVariables: maybe > StandaloneDeriving: maybe > StandaloneKindSignatures: maybe > StarIsType: maybe > StaticPointers: maybe > Strict: maybe > StrictData: maybe > TemplateHaskell: maybe > TemplateHaskellQuotes: maybe > TransformListComp: maybe > Trustworthy: maybe > TupleSections: maybe > TypeApplications: maybe > TypeFamilies: maybe > TypeFamilyDependencies: maybe > TypeInType: maybe > TypeOperators: maybe > TypeSynonymInstances: maybe > UnboxedSums: maybe > UnboxedTuples: maybe > UndecidableInstances: maybe > UndecidableSuperClasses: maybe > UnicodeSyntax: maybe > UnliftedFFITypes: maybe > UnliftedNewtypes: maybe > Unsafe: maybe > ViewPatterns: maybe > > > > > -- > 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 eric at seidel.io Mon Nov 30 01:53:14 2020 From: eric at seidel.io (Eric Seidel) Date: Sun, 29 Nov 2020 20:53:14 -0500 Subject: [ghc-steering-committee] =?utf-8?q?Please_review_=23313=3A_Delimi?= =?utf-8?q?ted_continuation_primops=2C_Shepherd=3A_Simon_Marlow?= In-Reply-To: References: <8f73b563dc640510a288261be00db36314669fff.camel@joachim-breitner.de> Message-ID: This is a very well-written and motivated proposal, and I love that it's just three new primops (really two, plus a tag to add some guard rails). I'm not very familiar with the literature on delimited continuations, but I support going with the most general formulation, especially for primops. I'm not sure we need to be able to detect all uses of the new primops with unsafePerformIO, it's already a deeply unsafe function. Just another thing that advanced users will need to keep in mind. On Mon, Nov 23, 2020, at 09:37, Simon Marlow wrote: > Committee, > > We have been asked to review > #313: Delimited continuation primops > > https://github.com/ghc-proposals/ghc-proposals/pull/313 > https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md > > *Summary* > > The proposal makes no language changes, it only adds three primops > . > > The main motivation is to support building efficient implementations of > Algebraic Effect systems, which depend on being able to efficiently > capture a continuation. Currently this is done explicitly, which > imposes a severe performance penalty. > > These primops are the minimal support needed to be able to capture a > continuation and apply it at runtime, together with some basic type > safety via the PromtTag type to ensure that at least we don't replace a > continuation with a computation of a different type. (there are other > ways to go wrong with these primops though, they're not a safe > interface by themselves: they need to be wrapped in a safe library). > > The primops are implemented by copying chunks of stack into the heap. > This is something that GHC's runtime already does a lot of, so it's not > a new concept, although it does require a new closure type and knock-on > changes across several files in the runtime (though it's mainly > mechanical). There's a prototype implementation here: > https://gitlab.haskell.org/lexi.lambda/ghc/-/compare/master...first-class-continuations?view=inline > > *Decision* > * > * > I'm going to tentatively recommend acceptance. > * This is a sensible choice for the primtives, being the most general > of the alternatives, as explained in the proposal. > > * Would the new primops impose a significant ongoing maintenance > burden? Having looked at the patch, although there are some missing > pieces, I don't think the new concepts impose any significant new > requirements on other parts of the runtime. > * I suspect there may be some difficulties around unsafePerformIO, so > I raised that on the github thread > > Thoughts? > > > > On Sat, 12 Sep 2020 at 22:59, Joachim Breitner wrote: > > Dear Committee, > > > > this is your secretary speaking: > > > > Delimited continuation primops > > has been proposed by Alexis King > > https://github.com/ghc-proposals/ghc-proposals/pull/313 > > https://github.com/lexi-lambda/ghc-proposals/blob/delimited-continuation-primops/proposals/0000-delimited-continuation-primops.md > > > > I’ll propose Simon Marlow 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 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From arnaud.spiwack at tweag.io Mon Nov 30 13:34:38 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Mon, 30 Nov 2020 14:34:38 +0100 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: On Sun, Nov 29, 2020 at 12:40 PM Simon Marlow wrote: > On Wed, 25 Nov 2020 at 11:21, Spiwack, Arnaud > wrote: > >> PostfixOperators: maybe >> > > I'd like to make a case for this extension, on the grounds that it's a > complete no-brainer. > > The name "PostfixOperators" makes it sound a lot more scary than it > actually is. In fact it's just a tiny generalisation to the definition of > left sections. You could almost regard it as a typo in the Haskell report - > if it had been noticed that this rule was unnecessarily restrictive, I'm > fairly sure it would have been fixed at the time. > > > https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#extension-PostfixOperators > It took me several readings to understand what this extension does, to be honest. I agree now, I'll change my vote. On Sun, Nov 29, 2020 at 9:14 PM Alejandro Serrano Mena wrote: > > > El dom, 29 nov 2020 a las 12:12, Simon Marlow () > escribió: > >> On Wed, 25 Nov 2020 at 11:21, Spiwack, Arnaud >> wrote: >> >>> >>> ## OverloadedX >>> >>> These extensions can confuse type inference, yielding ambiguous type >>> variables message. And as much as I like them, I don't think it's safe >>> to include them yet. Not until we have a reasonable story for >>> defaulting literals. >>> >>> OverloadedLabels: no >>> OverloadedLists: no >>> OverloadedStrings: no >>> >> >> For what it's worth, I've been writing code with OverloadedStrings for >> several years now and in my experience it rarely causes a problem, even for >> beginners. The context almost always provides enough information to resolve >> the ambiguity. (admittedly I'm slightly surprised by this too, but >> experience has convinced me) >> >> I don't have much experience with OverloadedLists, but I'd be prepared to >> believe that it's a similar story there too. >> > > Adding to this, I think that both OverloadedStrings and OverloadedLists go > very well with the idea of overloaded literals story that Haskell already > has for numbers. > On principle, I very much agree. In fact I almost always turn both OverloadedStrings and OverloadedList on. But it also almost always causes some type errors when I turn them on (well, ambiguity errors). Therefore, I'm a bit dubious at the idea of making them the default. Even though Alejandro's point is undeniable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Nov 30 16:54:27 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 30 Nov 2020 16:54:27 +0000 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: My votes. I'm using Iavor's categorisation. Many of these I don't feel strongly about. Simon Module System ============= ImportQualifiedPost: yes -- ^ This is relatively new, but it seems quite simple, and it does make -- things read nicer. -- | These are only needed under very special circumstances, -- so it's good to be explicit: PackageImports: no NoImplicitPrelude: no Notation ======== BlockArguments: no -- ^ I prefer the extra parens MultiWayIf: no LambdaCase: no -- ^ There is an on-going dicussion about \of, -- whose outcome I don't want to pre-judge -- | The various literal notations seem useful when you need them -- and don't conflict with anything. BinaryLiterals: yes HexFloatLiterals: yes NumericUnderscores: yes NumDecimals: maybe OverloadedStrings: yes OverloadedLists: yes -- | ^ These go together OverloadedLabels: no -- | ^ Still rather experimental EmptyCase: yes -- ^ Simple, useful, no conflicts PostfixOperators: yes LexicalNegation: maybe UnicodeSyntax: maybe NegativeLiterals: no -- ^ It seems that `LexicalNegation` might be a nicer way to do this? TupleSections: maybe -- ^ I don't use this often, but I'd use it more often if it was on by default. ImplicitParams: no -- ^ I find these quite useful on occasion, but it does seem reasonable -- to be explicit when you need them. ParallelListComp: yes -- ^ I find these to be a very nice generalization to list comprehensions -- that makes some code way more readable than using `zip/zipWith`, just -- like comprehensions are often nicer than `map` or `concatMap` RecursiveDo: yes -- ^ Seems useful when you need it, and it doesn't clash with anything, -- so I see no reason to not have it on all the time. TransformListComp: no -- ^ In my mind these are just a bit too much syntactic sugar. Arrows: no -- ^ Big feature; if you want it, ask for it ApplicativeDo: no -- ^ Does not seem to have settled yet QualifiedDo: no -- ^ This is neat, but it is too new to be on by default. MonadComprehensions: maybe -- ^ I never really use these. -- On occasion I've wanted `ApplicativeComprehensions` though. NondecreasingIndentation: no -- ^ This always felt like a hack to me. RebindableSyntax: no -- ^ Definitely not by default! ExplicitNamespaces: maybe -- ^ We need this if we also want pattern synonyms. Data Types ========== DatatypeContexts: no -- ^ These are not really used much, and usually don't do what people expect. ExistentialQuantification: yes -- ^ This is quite useful, and has been around for a long time. EmptyDataDecls: yes -- ^ Seems more consistent to allow this RoleAnnotations: yes -- ^ Useful in the same way that type signatures are StrictData: no -- ^ Obviously not by default GADTSyntax: yes -- ^ I personally don't use this, but I know some folks like to write -- their `data` declarations in this notation. GADTs: no -- ^ These can be useful, but it seems reasonable to enable them when -- you need them, as they bring in quite a lot of machinery with them. Patterns and Guards =================== BangPatterns: yes -- ^ Seem to be useful, and quite popular. ViewPatterns: yes -- ^ Useful on occasion, and I don't think calling out the extension -- explicitly helps anyone. PatternSynonyms: no -- ^ These are quite useful, but I am not sure how stable is their design. NoPatternGuards: no -- ^ Conflicts with Haskell2010 NPlusKPatterns: no -- ^ Conflicts with Haskell2010 Records ======= -- | Useful abbreviation NamedFieldPuns: yes --| Makes it harder to determine binding site RecordWildCards: no -- | These seem to be largely about experimenting with new record system, and I don't think any of them are quite ready to be on by default: DisambiguateRecordFields: no DuplicateRecordFields: no NoTraditionalRecordSyntax: no Deriving ======= -- | Declaring these as extensions explicitly adds very little information. EmptyDataDeriving: yes -- ^ Useful for consistency StandaloneDeriving: yes -- ^ I find this quite useful on occasion, and does not conflict with anything -- | Deriving particular classes -- No harm in these DeriveGeneric: yes DeriveLift: yes DeriveDataTypeable: yes DeriveFunctor: yes DeriveFoldable: yes DeriveTraversable: yes -- | Deriving methods -- I'm less convinced that these are stable DerivingStrategies: no DerivingVia: no GeneralisedNewtypeDeriving: no DeriveAnyClass: no Class System ============ MultiParamTypeClasses: yes -- ^ Seems like a natural extension and does not really conflict with anything NullaryTypeClasses: yes -- ^ Seems like a natural extension and does not really conflict with anything ConstraintKinds: yes -- ^ These seem like a very nice fit with the rest of the kind system, -- | These 3 seem to be quite common. There are some reasons to be careful -- when writing `FlexibleInstances`, but it seems that having the extension -- does not really help much with those. TypeSynonymInstances: yes FlexibleInstances: yes FlexibleContexts: yes -- | A simple and useful generalisation ConstrainedClassMethods: yes -- | A bit more complicated DefaultSignatures: no -- | Simple and useful InstanceSigs: yes -- | This is mainly for GHCi; don't want this on by default! ExtendedDefaultRules: no FunctionalDependencies: no -- ^ While I quite like the general idea here, I don't think we should -- have these on by default. QuantifiedConstraints: no -- ^ These seem neat, but are quite new to be on by default. UndecidableInstances: no -- ^ These are a very special case, and ideally should be specified -- on a per instance basis. IncoherentInstances: no -- ^ Why do we even have this? :) UndecidableSuperClasses: no -- ^ These are a very special case. OverlappingInstances: no -- ^ This has been subsumed by per-instance pragmas Types ===== RankNTypes: yes -- ^ These are useful and have been around for a long time. The design -- seems to work well. -- | These two seem useful, but I am not sure if they should be on by default. -- If so, though, it makes sense to have both of them on. StandaloneKindSignatures: yes KindSignatures: yes LiberalTypeSynonyms: maybe -- ^ These seem useful, but can lead to some rather confusing situations -- where types that look "normal" don't behave as you'd expect -- (e..g, writing `[T]` fails because `T` happens to have `forall` in it) -- | These two go together and seem quite useful, especially when writing -- local type signatures. ScopedTypeVariables: yes ExplicitForAll: yes AllowAmbiguousTypes: no -- ^ Often these are unintentional, and are due to a mistake in the program. ImpredicativeTypes: no -- ^ Fairly new MonoLocalBinds: yes -- ^ Switched on by TypeFamilies; let's have it all the time -- But debatable NoMonomorphismRestriction: yes -- ^ The monomrphism restriction seems to cause a lot of confusion, and I -- am not sure that it's helped that much with efficiency -- | Doesn't really seem to be commonly used. PartialTypeSignatures: no NamedWildCards: no LinearTypes: no -- ^ Too new to be standardized TypeApplications: yes -- ^ Super useful! -- | These are all related to type-level programming, and while I don't think -- they should be on by default, it might be useful to have a single flag that -- turns a bunch of them on. PolyKinds: yes TypeOperators: yes StarIsType: yes -- More complicated TypeFamilies: no TypeFamilyDependencies: no DataKinds: no FFI === I don't think the FFI should be on by default, as it is used relatively infrequently, although it might be nice if `ForeignFunctionInterface` implied `CApiFFI` ForeignFunctionInterface: no CApiFFI: no GHCForeignImportPrim: no InterruptibleFFI: no UnliftedFFITypes: no StaticPointers: no Low Level ========= These are for low-level hacking, so I don't think they should be on by default. However, I wouldn't mind having a flag that enabled all of them with a single extension (e.g., `UnliftedTypes`) UnboxedSums: no UnboxedTuples: no MagicHash: no UnliftedNewtypes: no Macros ====== CPP: no This is quite specialized, so it seems reasonable to be explicit about it. I don't think these should be on by default, but I wouldn't mind it if `TemplateHaskell` implied `QuasiQuotes`, so that when I use TH I just need to turn on a single extension.: TemplateHaskell: no TemplateHaskellQuotes: no QuasiQuotes: no Other ===== -- | These are part of Safe Haskell and are there to be written explicitly Unsafe: no Safe: no Trustworthy: no Strict: no -- ^ This is not Haskell! :-) Obsolete/Deprecated =================== CUSKs: no TypeInType: no MonadFailDesugaring: maybe From rae at richarde.dev Mon Nov 30 17:33:55 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 30 Nov 2020 17:33:55 +0000 Subject: [ghc-steering-committee] #380 GHC2021: Voting starts In-Reply-To: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> References: <4c563ff7355172bc58ea8484dfc5cd8d8f1a558e.camel@joachim-breitner.de> Message-ID: <010f01761a37d648-a39afd7a-8dd3-4985-928f-3a8921798a6d-000000@us-east-2.amazonses.com> I also adopted Iavor's very helpful categorization. I have not given any motivations below, as it's too difficult to read everyone's motivations inline. Instead, I give several varieties of "no" votes. Let's debate when someone disagrees with me. (To be clear: "obscure" just means that someone should manually opt in, not that the feature is really obscure.) Module System ============= ImportQualifiedPost: yes PackageImports: obscure NoImplicitPrelude: breaking Notation ======== BlockArguments: yes MultiWayIf: might change LambdaCase: might change BinaryLiterals: yes HexFloatLiterals: yes NumericUnderscores: yes NumDecimals: yes OverloadedStrings: bad for beginners OverloadedLists: bad for beginners OverloadedLabels: obscure EmptyCase: yes PostfixOperators: yes LexicalNegation: yes UnicodeSyntax: yes NegativeLiterals: superseded TupleSections: yes ImplicitParams: obscure ParallelListComp: yes RecursiveDo: obscure TransformListComp: obscure Arrows: obscure ApplicativeDo: breaking QualifiedDo: too fresh MonadComprehensions: bad for beginners NondecreasingIndentation: obscure RebindableSyntax: breaking ExplicitNamespaces: yes Data Types ========== DatatypeContexts: no ExistentialQuantification: yes EmptyDataDecls: yes RoleAnnotations: yes StrictData: breaking GADTSyntax: yes GADTs: obscure Patterns and Guards =================== BangPatterns: yes ViewPatterns: yes PatternSynonyms: too fresh NoPatternGuards: breaking NPlusKPatterns: deprecated Records ======= NamedFieldPuns: yes RecordWildCards: confusing DisambiguateRecordFields: yes DuplicateRecordFields: might change NoTraditionalRecordSyntax: no Deriving ======= DeriveGeneric: yes DeriveLift: yes DeriveDataTypeable: yes EmptyDataDeriving: yes StandaloneDeriving: yes DeriveFunctor: yes DeriveFoldable: yes DeriveTraversable: yes DerivingStrategies: yes DerivingVia: yes GeneralisedNewtypeDeriving: yes DeriveAnyClass: dangerous Class System ============ MultiParamTypeClasses: yes NullaryTypeClasses: superseded ConstraintKinds: yes TypeSynonymInstances: yes FlexibleInstances: yes FlexibleContexts: yes ConstrainedClassMethods: yes DefaultSignatures: yes InstanceSigs: yes ExtendedDefaultRules: might change FunctionalDependencies: obscure QuantifiedConstraints: too fresh UndecidableInstances: dangerous IncoherentInstances: dangerous UndecidableSuperClasses: dangerous OverlappingInstances: superseded Types ===== RankNTypes: yes StandaloneKindSignatures: yes KindSignatures: yes LiberalTypeSynonyms: confusing ScopedTypeVariables: might change ExplicitForAll: yes AllowAmbiguousTypes: dangerous ImpredicativeTypes: too fresh MonoLocalBinds: breaking NoMonomorphismRestriction: debate! PartialTypeSignatures: obscure NamedWildCards: yes LinearTypes: too fresh TypeApplications: yes PolyKinds: yes TypeOperators: yes StarIsType: deprecated TypeFamilies: obscure TypeFamilyDependencies: obscure DataKinds: might change FFI === ForeignFunctionInterface: obscure CApiFFI: obscure GHCForeignImportPrim: obscure InterruptibleFFI: obscure UnliftedFFITypes: obscure StaticPointers: obscure Low Level ========= UnboxedSums: obscure UnboxedTuples: obscure MagicHash: obscure UnliftedNewtypes: yes Macros ====== CPP: obscure TemplateHaskell: TH TemplateHaskellQuotes: yes QuasiQuotes: TH Other ===== Unsafe: no Safe: no Trustworthy: no Strict: no Obsolete/Deprecated =================== CUSKs: no TypeInType: no MonadFailDesugaring: maybe -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Mon Nov 30 19:36:44 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 30 Nov 2020 19:36:44 +0000 Subject: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance In-Reply-To: <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com> References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de> <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de> <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com> Message-ID: After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state. Regards, Alejandro On 29 Nov 2020 at 23:12:44, Eric Seidel wrote: > I left a few comments and questions on the PR itself, but I'm leaning > towards rejecting the proposal in its current form as well. This doesn't > (yet) feel like a generic mechanism, in particular because the only > modifier that has been specified would be deeply wired into GHC itself. > > On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote: > > Hi, > > > Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano > > Mena: > > > Dear all, > > > This proposal suggests adding syntax for a general notion of > > > modifiers, like the ones we’ve been talking about lately affecting > > > linearity or matchability of arrows. For example, if linear types and > > > unsaturated families are accepted as they stand, we would have `Int > > > #1 -> @U Bool` (or something like that), whereas with this proposal > > > we would have the more uniform `Int %1 %Unmatchable -> Bool`. > > > > > > Since the amount of modifiers is likely to increase in the future, I > > > think it’s a great idea to agree and reserve such syntax, instead of > > > coming up with different ways on each proposal. I thus recommend > > > acceptance of this proposal. > > > > > > The proposal itself: > > > (1) introduces syntax for modifiers in types and defines how to > > > type/kind check them, > > > (2) reserved such syntax for other uses in declarations and terms. > > > > > > I think the proposal still has its merits only with (1), even though > > > I lean towards accepting both parts of it. > > > I like the idea of reserving syntax here, but parts of the proposal > > smell a bit like premature generalization to me. Are we confident that > > all annotations we eventually would like to use with this feature can > > be expressed as types of a kind that is an instance of Modifier? Or > > should we reserve the ability to have annotations that don't fit that > > model? > > > Would we ever have annotation that may affect phases earlier than than > > typechecking? What if we want to use (%type e) and (%data e) to help > > with the SingleNamepace issues? Look like useful annotations to me, but > > I am not sure if they fit the framework proposed here. > > > The fact that we special-case %1 supports that. > > > The proposal explicitly has to state “No modifier polymorphism!”. But > > isn't that indication that using the type system to model the various > > modifiers might be the wrong tool? > > > I wonder if there is a way where the %(…) on it’s own only reserve > > syntax, and the various uses of that syntax can be disambiguated > > _statically_ based on the content of …. > > > Not great syntax, because not concise, enough, but morally I’d feel > > more at ease with > > > Int %(multiplicity Many) -> Int > > Int %(multiplicity 1) -> Int > > Int %(multiplicity m) -> Int > > > where multiplicity is a modifier keyword, to express the existing > > features (including implicit generalization of m). Then we can extend > > this to > > > Int %oneShot -> Int > > > and > > > Int %(matchability M) -> Int > > > and maybe even > > > foo (%type [a]) -- where foo :: forall a -> () > > > which is a modifier that > > > > So at the moment, I am inclined to reject this proposal, until I am > > convinced that we are not painting ourselves into a “all modifiers are > > types of special kinds and that’s all the syntax and behaviour we ever > > need” corner. > > > Minor detail: If we can annotate infix use of the (->) “type operator”, > > should we also be able to annotate other infix operators, i.e. > > > constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) > > infixexp ::= lexp {modifier} qop infixexp > > > > > 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 trupill at gmail.com Mon Nov 30 19:42:29 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 30 Nov 2020 19:42:29 +0000 Subject: [ghc-steering-committee] GHC2021: DeriveAnyClass Message-ID: Dear all, I’ve found as a surprise that several members of the Committee have voted against, or even marked as dangerous, the DeriveAnyClass extension. Given that I am a great fan of it, I would like to open the debate about the particular extension. In my case, most of my uses are to derive ToJSON and FromJSON from the Aeson package. I find it very nice to be able to pack all the information about auto-derived instances in a small block, instead of including Eq and Show in the deriving block, and then a few empty instance declarations below. This is definitely mainly a aesthetic reason. The other reason for adoption is that it makes classes such as Eq or Show less “special”, so one does not have to explain to beginners that some classes can be derived in this way, some others in that other way, and so on. So my other reason for inclusion would be a uniformity one. Regards, Alejandro -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Nov 30 19:52:26 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 30 Nov 2020 19:52:26 +0000 Subject: [ghc-steering-committee] #370: Syntax for Modifiers, Recommendation: Acceptance In-Reply-To: References: <657c7edd14fe9625623b849a71880cf211e3d027.camel@joachim-breitner.de> <315b4e252e3ef4bf227b68e78665086d558e3ba4.camel@joachim-breitner.de> <9d81675d-6bdb-455e-ae10-2a8a71d2f068@www.fastmail.com> Message-ID: <010f01761ab6a4e4-4bce122c-0daa-42ad-a7ea-d304b4080d53-000000@us-east-2.amazonses.com> To my surprise, I found myself leaning against. So I updated and simplified the proposal to remove Modifier. This makes modifiers a bit more magical, but more likely to actually work in practice. The type inference story previously may have been intractable. I've requested that the committee consider the updates in parallel with community feedback. Thanks, Richard > On Nov 30, 2020, at 2:36 PM, Alejandro Serrano Mena wrote: > > After some discussion in the GitHub thread, changes are going to arrive to the proposal. I think the best is to send the proposal back to the “Needs revision” state. > > Regards, > Alejandro > > On 29 Nov 2020 at 23:12:44, Eric Seidel > wrote: > I left a few comments and questions on the PR itself, but I'm leaning towards rejecting the proposal in its current form as well. This doesn't (yet) feel like a generic mechanism, in particular because the only modifier that has been specified would be deeply wired into GHC itself. > > On Fri, Nov 27, 2020, at 04:46, Joachim Breitner wrote: >> Hi, >> >> Am Donnerstag, den 26.11.2020, 14:58 -0500 schrieb Alejandro Serrano >> Mena: >> > Dear all, >> > This proposal suggests adding syntax for a general notion of >> > modifiers, like the ones we’ve been talking about lately affecting >> > linearity or matchability of arrows. For example, if linear types and >> > unsaturated families are accepted as they stand, we would have `Int >> > #1 -> @U Bool` (or something like that), whereas with this proposal >> > we would have the more uniform `Int %1 %Unmatchable -> Bool`. >> > >> > Since the amount of modifiers is likely to increase in the future, I >> > think it’s a great idea to agree and reserve such syntax, instead of >> > coming up with different ways on each proposal. I thus recommend >> > acceptance of this proposal. >> > >> > The proposal itself: >> > (1) introduces syntax for modifiers in types and defines how to >> > type/kind check them, >> > (2) reserved such syntax for other uses in declarations and terms. >> > >> > I think the proposal still has its merits only with (1), even though >> > I lean towards accepting both parts of it. >> >> I like the idea of reserving syntax here, but parts of the proposal >> smell a bit like premature generalization to me. Are we confident that >> all annotations we eventually would like to use with this feature can >> be expressed as types of a kind that is an instance of Modifier? Or >> should we reserve the ability to have annotations that don't fit that >> model? >> >> Would we ever have annotation that may affect phases earlier than than >> typechecking? What if we want to use (%type e) and (%data e) to help >> with the SingleNamepace issues? Look like useful annotations to me, but >> I am not sure if they fit the framework proposed here. >> >> The fact that we special-case %1 supports that. >> >> The proposal explicitly has to state “No modifier polymorphism!”. But >> isn't that indication that using the type system to model the various >> modifiers might be the wrong tool? >> >> I wonder if there is a way where the %(…) on it’s own only reserve >> syntax, and the various uses of that syntax can be disambiguated >> _statically_ based on the content of …. >> >> Not great syntax, because not concise, enough, but morally I’d feel >> more at ease with >> >> Int %(multiplicity Many) -> Int >> Int %(multiplicity 1) -> Int >> Int %(multiplicity m) -> Int >> >> where multiplicity is a modifier keyword, to express the existing >> features (including implicit generalization of m). Then we can extend >> this to >> >> Int %oneShot -> Int >> >> and >> >> Int %(matchability M) -> Int >> >> and maybe even >> >> foo (%type [a]) -- where foo :: forall a -> () >> >> which is a modifier that >> >> >> So at the moment, I am inclined to reject this proposal, until I am >> convinced that we are not painting ourselves into a “all modifiers are >> types of special kinds and that’s all the syntax and behaviour we ever >> need” corner. >> >> Minor detail: If we can annotate infix use of the (->) “type operator”, >> should we also be able to annotate other infix operators, i.e. >> >> constr ::= (btype | ! atype) {modifier} conop (btype | ! atype) >> infixexp ::= lexp {modifier} qop infixexp >> >> >> >> 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 rae at richarde.dev Mon Nov 30 20:02:19 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 30 Nov 2020 20:02:19 +0000 Subject: [ghc-steering-committee] GHC2021: DeriveAnyClass In-Reply-To: References: Message-ID: <010f01761abfb361-0d52c8ce-f1ed-4c73-9298-c93ad08d30ca-000000@us-east-2.amazonses.com> My worry with DeriveAnyClass that a user might try to derive a class not intended for use with DeriveAnyClass. For instance: > class Pretty a where -- render something for users, not debuggers > ppr :: a -> String > ppr x = pprs [x] > > pprs :: [a] -> String > pprs xs = "[" ++ intercalate "," (map ppr xs) ++ "]" > > instance Pretty a => Pretty [a] where > ppr xs = pprs xs > > instance Pretty Int where > ppr n = show n > > data T = MkT1 Int | MkT2 Bool > deriving Pretty With -XDeriveAnyClass, this compiles without any warnings -- and it seems like something a user might plausibly attempt. Attempting to ppr (MkT1 5) yields an infinitely long string. A more knowledgeable user would have written a MINIMAL pragma in Pretty (or perhaps designed the class differently), but not all users are experienced. If, say, we required an explicit deriving strategy to use DeriveAnyClass, or required a MINIMAL pragma, then I would feel differently. As it is, I think the extension is potentially dangerous, as it can create unexpected runtime behavior without warnings. Richard > On Nov 30, 2020, at 2:42 PM, Alejandro Serrano Mena wrote: > > Dear all, > I’ve found as a surprise that several members of the Committee have voted against, or even marked as dangerous, the DeriveAnyClass extension. Given that I am a great fan of it, I would like to open the debate about the particular extension. > > In my case, most of my uses are to derive ToJSON and FromJSON from the Aeson package. I find it very nice to be able to pack all the information about auto-derived instances in a small block, instead of including Eq and Show in the deriving block, and then a few empty instance declarations below. This is definitely mainly a aesthetic reason. > > The other reason for adoption is that it makes classes such as Eq or Show less “special”, so one does not have to explain to beginners that some classes can be derived in this way, some others in that other way, and so on. So my other reason for inclusion would be a uniformity one. > > Regards, > Alejandro > _______________________________________________ > 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 Mon Nov 30 20:56:55 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 30 Nov 2020 21:56:55 +0100 Subject: [ghc-steering-committee] GHC2021: DeriveAnyClass In-Reply-To: <010f01761abfb361-0d52c8ce-f1ed-4c73-9298-c93ad08d30ca-000000@us-east-2.amazonses.com> References: <010f01761abfb361-0d52c8ce-f1ed-4c73-9298-c93ad08d30ca-000000@us-east-2.amazonses.com> Message-ID: <9104c26169292fa0e256435aea8ed281f9c1d980.camel@joachim-breitner.de> Hi, I concur with Richard: DeriveAnyClass is convenient where it works, but too implicit and too magical for my taste. It’s a cute trick, but in general “just write an empty instance and hope for the best” isn't a particular convincing solution to this problem. There was a recent blog post, written tongue in cheek, about removing type class features in Haskell … here it is: https://www.parsonsmatt.org/2020/11/10/simplifying_deriving.html and the gist here is: With DerivingVia we don’t need DeriveAnyClass: newtype Generically a = Generically a instance (Generic a, GToJSON (Rep a)) => ToJSON (Generically a) where toJSON (Generically a) = gtoJSON a data X = X deriving stock Generic deriving ToJSON via Generically X And the last line is easier to understand and safer than DeriveAnyClass. In light of these alternatives, I am still inclined to not give DeriveAnyClass the seal of “harmless and uncontentious” :-) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/