From mail at joachim-breitner.de Thu Jul 1 19:06:06 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 01 Jul 2021 21:06:06 +0200 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: Hi, I understand the desire to have a constantly updated “dashboard”. But I don’t think a spreadsheed will work. At least not if your expectation is that we, collaboratively, keep it up to date. If we already fall behind our actual review commitments, surely we’ll fall behind additional red tape commitments. And then we’ll have a file that we can’t rely on because we wouldn’t be confident that it actually reflects reality. And it’s not that I hates manual solutions. In fact, my semi-regular “status” emails are fully manual! In a way you did more or less what I do every time I create these: I did through my email and curate the current status quo. This is tenable because it’s clear who does it (the secretary, instead of everybody), and because it’s an email there is no confusion as whether it is is up to date – is is up to date the moment I write it, and makes no promises about later states. So that’s a difference in frequency, form and ownership (at intervals vs. continous; push email vs. pull URL; collectively vs. secretarial). Your sheet also contains additional fields (Author, various dates) – maybe I should include them in the status email. I don’t want to stop us from trying out different procedures, though, so if there is a general sentiment that a wiki-like process (everyone collaboratively edits a common file) is worth exploring, we can do that of course. But I miss the “yes please and I definitely will keep it up to date” cries from our crowd :-) Ultimately, the best would be a tool that uses the Github API to create a dashboard (Note that most information on your sheet is already present in github, especially as all status changes are represented as label changes), maybe even with automatic nudging on github or email… The next best thing is someone (but someone, not somemany) doing that manually; maintaining a dashboard like yours, plus nudging. But who wants to do manually what can be done (mostly) automated… Cheers, Joachim Am Montag, dem 28.06.2021 um 09:56 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > I’m a bit concerned that we are falling down on our commitment to > decide about GHC proposals in a timely manner. > Part of the problem is that at any moment I don’t have a clear > snapshot in my head of what decisions are pending, and who is driving > them.  I know that Joachim hates manual solutions, but I have spent a > few minutes digging through my email to build >  * this spreadsheet giving the current status > You all have edit permissions.  It covers only the handful of > proposals that are in our court.   Can I suggest that we all use it > to keep ourselves on the ball?   E.g. as a shepherd you can use it to > record who you are waiting for, as I have done for #302. > You’ll notice that we are behind on every one of them.  Remember, if > there edits we want the author to make, we push it back, out of our > court.  It can re-enter when the author re-submits. > If our commitments are over-ambitious, let’s review them. > Tom: you are our official nudger.  Would you like to make you weekly > nudge into an email to the full committee, with a pointer to the > spreadsheet and your current understanding of who is responsible for > driving? > I hope this is helpful.  If not, let’s think of something else! > 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 mail at joachim-breitner.de Thu Jul 1 19:09:55 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 01 Jul 2021 21:09:55 +0200 Subject: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) In-Reply-To: <39EE5778-44EA-40AD-88C0-987AF3A4B132@gmail.com> References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com> <0849EAA1-2ABB-4CC7-8316-FED4311413E3@gmail.com> <1640632A-5806-4EE3-8E6F-CF2A6C2CF5B7@gmail.com> <39EE5778-44EA-40AD-88C0-987AF3A4B132@gmail.com> Message-ID: <69495c8bea06d444a5a3a7cfe21203c60d50c52d.camel@joachim-breitner.de> Hi, Am Montag, dem 28.06.2021 um 18:25 +0300 schrieb Vladislav Zavialov (int-index): > While (3) is my personal favorite, it has received some heavy pushback, and I don’t suppose it has any chance of getting accepted. Therefore, I guess I’m asking to add (2) we do ranked voting precisely to not have to spend time on such discussions. Including an option with little chance doesn’t affect the outcome, so just include it. And even a single member saying it’s their personal favorite is, IMHO, enough reason to include it on the ballot. Also, realistically, not all the committee members have probably made up their mind, and some will only look careful at whatever is on the ballet. So we can’t know whether it s has a chance until it is voted on. It’s also nice to all the people outside the committee who might favor this option to include it. TL;DR: Don't be stingy with the options :-) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Thu Jul 1 19:16:11 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 01 Jul 2021 21:16:11 +0200 Subject: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Partial Accept In-Reply-To: References: <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com> <1754f703-f87b-448b-bfd3-268226203b38@www.fastmail.com> <010f0179eca00f96-706787fc-ebda-4855-b38a-b7161d44f971-000000@us-east-2.amazonses.com> <77209cd3-2da0-4bda-8a09-a7870d7e9d22@www.fastmail.com> <7a913d64-b6a7-4d51-9b6c-7c6e9d2011d6@www.fastmail.com> <5813a08c390adf628f215ee4ba3fd22ef5a77d51.camel@joachim-breitner.de> <010f017a5ac7ed07-92163998-1078-4d7c-85aa-a34e30335f99-000000@us-east-2.amazonses.com> Message-ID: Hi, Am Dienstag, dem 29.06.2021 um 23:19 -0400 schrieb Eric Seidel: > On Tue, Jun 29, 2021, at 22:38, Richard Eisenberg wrote: > > Just to chime in now that I'm back in action: I'm reasonably happy with > > the final result here > > With Richard in support, that leaves Simon PJ opposed to explicit > imports [1]. So we have Richard opposed to implicit imports, Simon > opposed to explicit imports, and the rest of us (I believe) amenable > to either. a different way to phrase that question might be: Do we want these defaulting declarations to behave just exactly like named things, or exactly like typeclass instances, or do we afford a new class with it’s own exporting/importing behavior. Is that a fair assessment? So, it doesn't really work like named things, as you don’t refer to them in code. But also the same design constraints as for type class instances applies, because there is no coherence requirement (which, unless I am mistaken, is the reason why we need no way to _not_ import an instance). That implies to me that this feature should be designed without too much allusion to existing export/import behavior, and rather basing it on what makes the feature most useful. (sorry, this mail doesn’t get more concrete that this.) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Thu Jul 1 19:46:44 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 01 Jul 2021 21:46:44 +0200 Subject: [ghc-steering-committee] GHC Steering Committee Status Message-ID: <62be8790d993c1e6688cbfadc4ff0870d66a9c0e.camel@joachim-breitner.de> Dear Committee, I had some busy months, so this status update is a bit later than expected… but you were all reasonably busy without me, so that’s fine. Over the summer I’ll be away from a laptop for a few weeks, so more than usually please keep tabs on your open tasks, and listen to Tom's nudges. So here’s the delta since May 17th. * Simon suggests a better way to keep tabs on what’s going on. Please join the that discussion! * Iavor left the committee. 👋 * we were asked to review these proposals: #351: NoIncomplete, Shepherd: Vitaly #281: Visible 'forall' in terms, Shepherd: Richard #390: Fine-grained pragmas, Shepherd: Vitaly (back from revision) * we have a recommendation from the shepherd about: #409: Exportable named defaults (partial accept) #283: Local modules (again) (accept) #351: NoIncomplete (accept) #281: Visible "forall" in terms (accept) #412: Explicit Splice Imports (accept) * we have sent the following proposals back to revision #400: Constrained COMPLETE sets (but it’s back already) * we decided about the following proposals #378: support the design for dependent types (accept) We currently have to act on the following 9 proposals, up by 1. ## Waiting for committee decision #281: Visible 'forall' in types of terms, Shepherd: Richard Richard recommends to accep this. It kicked off a discussion about points that one could argue have been covered by #378 already. Conversation has stalled since a month. Simon M, Richard, can you make progress on your conversation? #283: Local modules, Shepherd: Arnaud Arnaud recommends to accepts, and wants more opinions. Please give it! #302: Lambda expressions with guards and multiple clauses, Shepherd: SPJ Committee is preparing a vote #351: NoIncomplete, Shepherd: Vitaly Looks like it’s going to be rejected, since people are partial to -Wpartial instead. Waiting for the author to concur. #392: Clarify modifiers design principle (Shepherd: Alejandro) One comment only so far, please add more. #409: Exportable named defaults, Shepherd: Eric Deliberations about import behavior is going on. #412: splice imports, Shepherd: Vladislav Positive feedback so far. Shall we accept it, Vladislav? ## Waiting for Shepherd action #390: Fine-grained pragmas, Shepherd: Vitaly Vitaly, this is back from revision. What do you think about it? #400: Constrained COMPLETE sets, Shepherd: Vladislav Waiting for recommendation. Vladislav, the author says they addressed your concerns, and it’s now again in your court. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From bravit111 at gmail.com Sun Jul 4 09:12:55 2021 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Sun, 4 Jul 2021 12:12:55 +0300 Subject: [ghc-steering-committee] #390: Fine-grained pragmas, recommendation: accept In-Reply-To: References: <989E9E72-9923-4870-B424-B1B2D07A738D@gmail.com> Message-ID: Dear Committee, I'm happy to repeat my recommendation to accept Alejandro's proposal which is now back from revision: Fine-grained pragmas for classes, families, and instances https://github.com/ghc-proposals/ghc-proposals/pull/390 https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md All the issues that arose in the previous discussion are now resolved. Does anyone have something to add? Vitaly сб, 13 мар. 2021 г. в 12:38, Vitaly Bragilevsky : > чт, 11 мар. 2021 г. в 16:31, Vladislav Zavialov (int-index) < > vlad.z.4096 at gmail.com>: > >> I like the proposal and I would be happy to vote for its acceptance. >> However, it requires a little bit of polishing up with regards to its use >> of modifiers. In particular, it seems to treat modifiers as built-in units, >> whereas the core idea behind modifiers is that they are based on actual >> promoted types (with the exception of %1). >> >> Hence it seems appropriate to send it back for revision until this point >> is addressed. >> > > Yes, I agree. There is also another issue. I think we need either a > deprecation story for UndecidableInstances, or a statement that it should > survive with some motivation behind that. > > So, I'm sending this proposal back to Alejandro for review and set the > "needs revision" label on GitHub. > > Vitaly > >> >> - Vlad >> >> > On 20 Feb 2021, at 14:34, Vitaly Bragilevsky >> wrote: >> > >> > Dear Committee, >> > >> > Our own Alejandro has been proposed >> > Fine-grained pragmas for classes, families, and instances >> > https://github.com/ghc-proposals/ghc-proposals/pull/390 >> > >> https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md >> > >> > His idea is to bring the flexibility of >> overlaps/overlapping/overlappable pragmas to termination checking, type >> inference, and constraint solving. Alejandro proposes to introduce the >> following %-modifiers (as in already accepted #370, >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-modifiers.rst >> ): >> > %NoTerminationCheck >> > %LiberalCoverage >> > %LiberalInjectivity >> > %Overlapping >> > %Overlappable >> > %Overlaps >> > to liberate conditions for classes and instances, type families, >> forall-types, etc. The first three modifiers can be used instead of the >> scary-sounding UndecidableInstances extension. The last three modifiers are >> supposed to be used instead of the overlap*-pragmas for instances we >> already have. Note that this proposal doesn't suggest deprecating those >> extensions and pragmas. >> > >> > I think that this proposal goes in the right direction and recommend >> accepting it. >> > >> > As far as I understand, all the committee members, including those with >> terms about to expire, have the right to either support this proposal or to >> raise a voice against it either here or at >> https://github.com/ghc-proposals/ghc-proposals/pull/390. >> > >> > Regards, >> > Vitaly >> > >> > >> > >> > _______________________________________________ >> > 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 Fri Jul 9 04:35:19 2021 From: eric at seidel.io (Eric Seidel) Date: Thu, 08 Jul 2021 22:35:19 -0600 Subject: [ghc-steering-committee] =?utf-8?q?=23409=3A_Exportable_named_def?= =?utf-8?q?aults=2C_Recommendation=3A_Partial_Accept?= In-Reply-To: References: <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com> <1754f703-f87b-448b-bfd3-268226203b38@www.fastmail.com> <010f0179eca00f96-706787fc-ebda-4855-b38a-b7161d44f971-000000@us-east-2.amazonses.com> <77209cd3-2da0-4bda-8a09-a7870d7e9d22@www.fastmail.com> <7a913d64-b6a7-4d51-9b6c-7c6e9d2011d6@www.fastmail.com> <5813a08c390adf628f215ee4ba3fd22ef5a77d51.camel@joachim-breitner.de> <010f017a5ac7ed07-92163998-1078-4d7c-85aa-a34e30335f99-000000@us-east-2.amazonses.com> Message-ID: On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote: > a different way to phrase that question might be: Do we want these > defaulting declarations to behave just exactly like named things, or > exactly like typeclass instances, or do we afford a new class with it’s > own exporting/importing behavior. Is that a fair assessment? Not entirely, I think. We currently have two types of import/export behavior: named things, and typeclass instances. The proposal as currently written places defaulting rules somewhere in between: defaulting rules are exported like named things, but imported like class instances. This is new, but not too foreign, as the behavior on both sides exactly matches existing behavior we're familiar with. It's just the combination that's new. Some people have expressed concerns about implicitly importing defaulting rules like instances, which led to my current recommendation that we treat them *exactly* like named things on both sides. I think importing defaulting rules like named things is unlikely to cause problems in practice, so this seems like a good compromise. Richard further suggested that defaulting rules should have to be explicitly mentioned in an import list to be imported, which is a new import behavior for which we have no existing intuition to guide us. In fact, our existing intuition around import lists would actively mislead us here. So the question is not just do we adopt existing behavior or do something new. There are three options that have been proposed. 1. Adopt existing behavior exactly. 2. Combine existing behaviors in a novel way. 3. Introduce an entirely new behavior. In general, I would say that as you move from (1) to (3), you need an increasingly strong justification. I don't think I can justify (3) in this case based on Richard's concerns about module changes impacting type inference in downstream modules. Does that make sense? From eric at seidel.io Fri Jul 9 04:38:09 2021 From: eric at seidel.io (Eric Seidel) Date: Thu, 08 Jul 2021 22:38:09 -0600 Subject: [ghc-steering-committee] =?utf-8?q?=23409=3A_Exportable_named_def?= =?utf-8?q?aults=2C_Recommendation=3A_Partial_Accept?= In-Reply-To: References: <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com> <1754f703-f87b-448b-bfd3-268226203b38@www.fastmail.com> <010f0179eca00f96-706787fc-ebda-4855-b38a-b7161d44f971-000000@us-east-2.amazonses.com> <77209cd3-2da0-4bda-8a09-a7870d7e9d22@www.fastmail.com> <7a913d64-b6a7-4d51-9b6c-7c6e9d2011d6@www.fastmail.com> <5813a08c390adf628f215ee4ba3fd22ef5a77d51.camel@joachim-breitner.de> <010f017a5ac7ed07-92163998-1078-4d7c-85aa-a34e30335f99-000000@us-east-2.amazonses.com> Message-ID: <54fdf1a3-8859-45c8-8353-31564a5dd462@www.fastmail.com> Simon, Richard, have you had a chance to discuss? If not, I'd be happy to set up a call between the three of us. On Wed, Jun 30, 2021, at 01:36, Simon Peyton Jones wrote: > OK i've added a comment to explain the delay. Richard, you and I can discuss. > > Simon > > | -----Original Message----- > | From: ghc-steering-committee On > | Behalf Of Eric Seidel > | Sent: 30 June 2021 04:19 > | To: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] #409: Exportable named defaults, > | Recommendation: Partial Accept > | > | On Tue, Jun 29, 2021, at 22:38, Richard Eisenberg wrote: > | > Just to chime in now that I'm back in action: I'm reasonably happy > | > with the final result here > | > | With Richard in support, that leaves Simon PJ opposed to explicit imports > | [1]. So we have Richard opposed to implicit imports, Simon opposed to > | explicit imports, and the rest of us (I believe) amenable to either. > | > | I think we have two options at this point: we can keep trying to achieve > | consensus, or we can take a vote. Richard, Simon, since the two of you seem > | to have the strongest opinions on the import question, do you think we can > | reach a consensus here? I'm happy to set up a call if it would help to > | discuss things live. > | > | > but still curious about whether the new warning will be on by default or > | not. > | > | I believe it should be off by default. The warning would interfere with > | Prelude replacements (and the Prelude itself, should it adopt > | ExportedDefaults), which I view as the biggest usecase for these extensions. > | > | Thanks! > | Eric > | > | [1]: > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com > | %2Fghc-proposals%2Fghc-proposals%2Fpull%2F409%23issuecomment- > | 864809405&data=04%7C01%7Csimonpj%40microsoft.com%7C5126784da503456fb1bb0 > | 8d93b760db0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637606200986942832% > | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > | LCJXVCI6Mn0%3D%7C3000&sdata=RqPy7fhDfWRyIdz7NEMWWwuWKLRRom8c%2BC3p%2BFYz > | H4Q%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%7C5126784da503456fb1bb0 > | 8d93b760db0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637606200986942832% > | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > | LCJXVCI6Mn0%3D%7C3000&sdata=ePQduxulLz%2FTmpGhfRjKxRJ1bRyRdorYEYnjyR96xb > | w%3D&reserved=0 > From simonpj at microsoft.com Fri Jul 9 13:02:07 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 9 Jul 2021 13:02:07 +0000 Subject: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Partial Accept In-Reply-To: <54fdf1a3-8859-45c8-8353-31564a5dd462@www.fastmail.com> References: <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com> <1754f703-f87b-448b-bfd3-268226203b38@www.fastmail.com> <010f0179eca00f96-706787fc-ebda-4855-b38a-b7161d44f971-000000@us-east-2.amazonses.com> <77209cd3-2da0-4bda-8a09-a7870d7e9d22@www.fastmail.com> <7a913d64-b6a7-4d51-9b6c-7c6e9d2011d6@www.fastmail.com> <5813a08c390adf628f215ee4ba3fd22ef5a77d51.camel@joachim-breitner.de> <010f017a5ac7ed07-92163998-1078-4d7c-85aa-a34e30335f99-000000@us-east-2.amazonses.com> <54fdf1a3-8859-45c8-8353-31564a5dd462@www.fastmail.com> Message-ID: We have discussed! Richard will post our conclusions. Simon | -----Original Message----- | From: Eric Seidel | Sent: 09 July 2021 05:38 | To: Simon Peyton Jones ; Richard Eisenberg | | Cc: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] #409: Exportable named defaults, | Recommendation: Partial Accept | | Simon, Richard, have you had a chance to discuss? If not, I'd be happy to | set up a call between the three of us. | | On Wed, Jun 30, 2021, at 01:36, Simon Peyton Jones wrote: | > OK i've added a comment to explain the delay. Richard, you and I can | discuss. | > | > Simon | > | > | -----Original Message----- | > | From: ghc-steering-committee | > | On Behalf Of Eric | > | Seidel | > | Sent: 30 June 2021 04:19 | > | To: ghc-steering-committee at haskell.org | > | Subject: Re: [ghc-steering-committee] #409: Exportable named | > | defaults, | > | Recommendation: Partial Accept | > | | > | On Tue, Jun 29, 2021, at 22:38, Richard Eisenberg wrote: | > | > Just to chime in now that I'm back in action: I'm reasonably | > | happy > with the final result here | > | | > | With Richard in support, that leaves Simon PJ opposed to explicit | > | imports [1]. So we have Richard opposed to implicit imports, Simon | > | opposed to explicit imports, and the rest of us (I believe) amenable to | either. | > | | > | I think we have two options at this point: we can keep trying to | > | achieve consensus, or we can take a vote. Richard, Simon, since the | > | two of you seem to have the strongest opinions on the import | > | question, do you think we can reach a consensus here? I'm happy to | > | set up a call if it would help to discuss things live. | > | | > | > but still curious about whether the new warning will be on by | > | default or not. | > | | > | I believe it should be off by default. The warning would interfere | > | with Prelude replacements (and the Prelude itself, should it adopt | > | ExportedDefaults), which I view as the biggest usecase for these | extensions. | > | | > | Thanks! | > | Eric | > | | > | [1]: | > | | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi | > | thub.com | > | %2Fghc-proposals%2Fghc-proposals%2Fpull%2F409%23issuecomment- | > | | > | 864809405&data=04%7C01%7Csimonpj%40microsoft.com%7C5126784da5034 | > | 56fb1bb0 | > | 8d93b760db0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63760620098 | > | 6942832% | > | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 | > | Ik1haWwi | > | LCJXVCI6Mn0%3D%7C3000&sdata=RqPy7fhDfWRyIdz7NEMWWwuWKLRRom8c%2BC | > | 3p%2BFYz | > | H4Q%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.haske | > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > | | > | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C5126784da5034 | > | 56fb1bb0 | > | 8d93b760db0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63760620098 | > | 6942832% | > | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 | > | Ik1haWwi | > | LCJXVCI6Mn0%3D%7C3000&sdata=ePQduxulLz%2FTmpGhfRjKxRJ1bRyRdorYEY | > | njyR96xb | > | w%3D&reserved=0 | > From simonpj at microsoft.com Fri Jul 9 13:38:45 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 9 Jul 2021 13:38:45 +0000 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: Good points. How about this: when you do the work for your monthly email, you update the spreadsheet, including a prominent date saying "this was true on date X". Zero extra work for you. That way I can have a bookmark to a table that shows a decent approximation to the status quo. I find it hard to grep back through mountains of email, be sure I'm looking at the latest status update from you, etc. It's enough friction that I just don't do it. Tom, our "nudger" will find that useful -- and will doubtless update it if he knows the status has changed (e.g he nudges someone and they say "oh I did that"). The rest of us (esp shepherds) can use it as an aide memoire. (What proposals am I responsible for?) Would that be ok? Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Joachim Breitner | Sent: 01 July 2021 20:06 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] GHC proposals | | Hi, | | I understand the desire to have a constantly updated "dashboard". But I | don't think a spreadsheed will work. At least not if your expectation is | that we, collaboratively, keep it up to date. If we already fall behind our | actual review commitments, surely we'll fall behind additional red tape | commitments. And then we'll have a file that we can't rely on because we | wouldn't be confident that it actually reflects reality. | | And it's not that I hates manual solutions. In fact, my semi-regular | "status" emails are fully manual! In a way you did more or less what I do | every time I create these: I did through my email and curate the current | status quo. This is tenable because it's clear who does it (the secretary, | instead of everybody), and because it's an email there is no confusion as | whether it is is up to date - is is up to date the moment I write it, and | makes no promises about later states. | | So that's a difference in frequency, form and ownership (at intervals vs. | continous; push email vs. pull URL; collectively vs. secretarial). | Your sheet also contains additional fields (Author, various dates) - maybe I | should include them in the status email. | | I don't want to stop us from trying out different procedures, though, so if | there is a general sentiment that a wiki-like process (everyone | collaboratively edits a common file) is worth exploring, we can do that of | course. But I miss the "yes please and I definitely will keep it up to date" | cries from our crowd :-) | | Ultimately, the best would be a tool that uses the Github API to create a | dashboard (Note that most information on your sheet is already present in | github, especially as all status changes are represented as label changes), | maybe even with automatic nudging on github or email. | | The next best thing is someone (but someone, not somemany) doing that | manually; maintaining a dashboard like yours, plus nudging. But who wants to | do manually what can be done (mostly) automated. | | | Cheers, | Joachim | | | Am Montag, dem 28.06.2021 um 09:56 +0000 schrieb Simon Peyton Jones via | ghc-steering-committee: | > I'm a bit concerned that we are falling down on our commitment to | > decide about GHC proposals in a timely manner. | > Part of the problem is that at any moment I don't have a clear | > snapshot in my head of what decisions are pending, and who is driving | > them.  I know that Joachim hates manual solutions, but I have spent a | > few minutes digging through my email to build | >  * this spreadsheet giving the current status You all have edit | > permissions.  It covers only the handful of proposals that are in our | > court.   Can I suggest that we all use it to keep ourselves on the | > ball?   E.g. as a shepherd you can use it to record who you are | > waiting for, as I have done for #302. | > You'll notice that we are behind on every one of them.  Remember, if | > there edits we want the author to make, we push it back, out of our | > court.  It can re-enter when the author re-submits. | > If our commitments are over-ambitious, let's review them. | > Tom: you are our official nudger.  Would you like to make you weekly | > nudge into an email to the full committee, with a pointer to the | > spreadsheet and your current understanding of who is responsible for | > driving? | > I hope this is helpful.  If not, let's think of something else! | > Simon | > _______________________________________________ | > 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%7C339ecde3cd0345bb56c008d93c | > c3520b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637607632780784446 | > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I | > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hBK7hEfFzJhRh3iYskV8MCwHpr2jMYC | > c6Ed7fCUu0ro%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%7C339ecde3cd0345bb | 56c008d93cc3520b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63760763278079 | 4437%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vn6ZhpdEb9QPd5KIMw6Wmg3QO7u51PJVNhlTSQO | nJBQ%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%7C339ecde3cd0345bb56c00 | 8d93cc3520b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637607632780794437% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=EmSqsU2w3ARP3hXLA3xshhOt6zw%2Bn8LVx3qAy7sIGl | g%3D&reserved=0 From cgibbard at gmail.com Fri Jul 9 16:51:16 2021 From: cgibbard at gmail.com (Cale Gibbard) Date: Fri, 9 Jul 2021 12:51:16 -0400 Subject: [ghc-steering-committee] Stepping down for now Message-ID: I've been having trouble finding time and energy to keep track of GHC steering committee stuff of late, so it's probably best if my place was assigned to someone else. I'll still be around of course, given that my work with Obsidian has me doing GHC development right now, but it's hard to do that, and then also find spare time for this. Thanks! - Cale -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sat Jul 10 09:52:01 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 10 Jul 2021 09:52:01 +0000 (UTC) Subject: [ghc-steering-committee] Stepping down for now In-Reply-To: References: Message-ID: <31ab6c37-9e19-4cb1-b363-7068338a0e03@joachim-breitner.de> Dear Cale, thanks for your service, it was appreciated and helpful. We are still 10 members strong, so no immediate need for new members. Next expected call for nominations will be in September. Cheers, Joachim -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Sun Jul 11 01:47:45 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Sun, 11 Jul 2021 01:47:45 +0000 Subject: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Partial Accept In-Reply-To: References: <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com> <1754f703-f87b-448b-bfd3-268226203b38@www.fastmail.com> <010f0179eca00f96-706787fc-ebda-4855-b38a-b7161d44f971-000000@us-east-2.amazonses.com> <77209cd3-2da0-4bda-8a09-a7870d7e9d22@www.fastmail.com> <7a913d64-b6a7-4d51-9b6c-7c6e9d2011d6@www.fastmail.com> <5813a08c390adf628f215ee4ba3fd22ef5a77d51.camel@joachim-breitner.de> <010f017a5ac7ed07-92163998-1078-4d7c-85aa-a34e30335f99-000000@us-east-2.amazonses.com> Message-ID: <010f017a933fbbe9-f5144cde-aba7-4f6c-a2b9-3f3918c8c741-000000@us-east-2.amazonses.com> > On Jul 9, 2021, at 12:35 AM, Eric Seidel wrote: > > On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote: >> a different way to phrase that question might be: Do we want these >> defaulting declarations to behave just exactly like named things, or >> exactly like typeclass instances, or do we afford a new class with it’s >> own exporting/importing behavior. Is that a fair assessment? > > Not entirely, I think. > > We currently have two types of import/export behavior: > named things, and typeclass instances. The proposal as currently > written places defaulting rules somewhere in between: defaulting > rules are exported like named things, but imported like class instances. > This is new, but not too foreign, as the behavior on both sides exactly > matches existing behavior we're familiar with. It's just the combination > that's new. This doesn't match my understanding of the proposal. It looks to me that, as written in the proposal, exports of a `default` would have to be explicit. That is, a module starting with `module M where ...` would not export any defaults. This fact is a bit implied in the proposal ("This proposal does not modify that behaviour: a default declaration by itself does not apply outside its module."), but it's my best understanding. --- Simon and I have discussed. We both came to an agreement that imports should have to be explicit. GHC currently has two import/export strategies. Strategy 1: Always. In the Always strategy, an entity is always exported from a module and always brought into scope from an imported module. The Always strategy is used for type and class instances. Strategy 2: Public. In the Public strategy, an entity is exported by default (no export list) or when explicitly included in an export list. It is brought into scope from an importing module by default (no import list) or when explicitly included in an import list. A Public entity may be excluded from scope by a `hiding` clause. All top-level named entities are exported/imported via the Public strategy. I propose (with Simon's support) Strategy 3: Private. In the Private strategy. an entity is exported only when explicitly included in an export list, and it is brought into scope from an imported module only when explicitly included in the import list. I propose we use Private for `default` declarations (only). Reasons: * Changing defaulting behavior really can launch the rockets. Suppose T has a Num instance whose fromInteger uses unsafePerformIO to launch the rockets. Then including T in an import list could make a very innocent-looking `x = 5` declaration launch the rockets. * GHC currently supports an option -ddump-minimal-imports, which displays import lists describing what symbols must be brought into scope from an imported module. If a `import M` import statement brought defaulting behavior into scope, then going from `import M` to `import M (foo, bar)` might deleteriously change defaulting behavior, thus invalidating the work of -ddump-minimal-imports. * The proposal as written does not describe how `module` exports work with named defaults. For example, what happens in `module B (module A) where import A`? Normally, that re-exports all names in scope both as `A.blah` and as `blah`. But, of course, a default isn't named in this way. So is the default exported? By requiring explicit inclusion in the export list, the Private strategy sidesteps this question. * This is a more conservative choice. We can always revisit this in the light of experience. However, if defaults were always imported, it would be much more disruptive to make them imported only by request. We have rightly identified that using the Private strategy would potentially reduce the usefulness of this idea, especially with alternative Preludes. As far as I know, GHC does not currently officially support having an alternative Prelude. That is, an "alternative Prelude" is really just disabling the import of base.Prelude and then importing some other module. However, we could imagine a compiler flag that specifies another package (or module name) to use as the Prelude... and then we could also specify how it is imported. For example, we could say that the Prelude is imported with > import Prelude > import Prelude ( default(..) ) where the second line says to grab all the defaults. I think this would be reasonable, but not necessary in the first version of this current proposal. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun Jul 11 18:50:34 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 11 Jul 2021 20:50:34 +0200 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: Hi, we might be converging on something here… it seems that a stable URL that summarizes the status quo is a core desire here. I’d try to avoid adding more communication venues (we already have Github and the mailing list). But how about whenever I send around the summary mail, I also paste the status quo into the page at https://github.com/ghc-proposals/ghc-proposals/wiki/Status I’ll tweak the markup next time so that it works well both in email and as rendered markdown. BTW, if you want up-to-date information on proposals under discussion, the links “List of proposals waiting for shepherd recommendation” and “List of proposals waiting for committee decision” right in the beginning of https://github.com/ghc-proposals/ghc-proposals could be a good starting point. Cheers, Joachim Am Freitag, dem 09.07.2021 um 13:38 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > Good points. > > How about this: when you do the work for your monthly email, you update the spreadsheet, including a prominent date saying "this was true on date X". Zero extra work for you. > > That way I can have a bookmark to a table that shows a decent approximation to the status quo. I find it hard to grep back through mountains of email, be sure I'm looking at the latest status update from you, etc. It's enough friction that I just don't do it. > > Tom, our "nudger" will find that useful -- and will doubtless update it if he knows the status has changed (e.g he nudges someone and they say "oh I did that"). > > The rest of us (esp shepherds) can use it as an aide memoire. (What proposals am I responsible for?) > > Would that be ok? > > Simon > > > -----Original Message----- > > From: ghc-steering-committee On > > Behalf Of Joachim Breitner > > Sent: 01 July 2021 20:06 > > To: ghc-steering-committee at haskell.org > > Subject: Re: [ghc-steering-committee] GHC proposals > > > > Hi, > > > > I understand the desire to have a constantly updated "dashboard". But I > > don't think a spreadsheed will work. At least not if your expectation is > > that we, collaboratively, keep it up to date. If we already fall behind our > > actual review commitments, surely we'll fall behind additional red tape > > commitments. And then we'll have a file that we can't rely on because we > > wouldn't be confident that it actually reflects reality. > > > > And it's not that I hates manual solutions. In fact, my semi-regular > > "status" emails are fully manual! In a way you did more or less what I do > > every time I create these: I did through my email and curate the current > > status quo. This is tenable because it's clear who does it (the secretary, > > instead of everybody), and because it's an email there is no confusion as > > whether it is is up to date - is is up to date the moment I write it, and > > makes no promises about later states. > > > > So that's a difference in frequency, form and ownership (at intervals vs. > > continous; push email vs. pull URL; collectively vs. secretarial). > > Your sheet also contains additional fields (Author, various dates) - maybe I > > should include them in the status email. > > > > I don't want to stop us from trying out different procedures, though, so if > > there is a general sentiment that a wiki-like process (everyone > > collaboratively edits a common file) is worth exploring, we can do that of > > course. But I miss the "yes please and I definitely will keep it up to date" > > cries from our crowd :-) > > > > Ultimately, the best would be a tool that uses the Github API to create a > > dashboard (Note that most information on your sheet is already present in > > github, especially as all status changes are represented as label changes), > > maybe even with automatic nudging on github or email. > > > > The next best thing is someone (but someone, not somemany) doing that > > manually; maintaining a dashboard like yours, plus nudging. But who wants to > > do manually what can be done (mostly) automated. > > > > > > Cheers, > > Joachim > > > > > > Am Montag, dem 28.06.2021 um 09:56 +0000 schrieb Simon Peyton Jones via > > ghc-steering-committee: > > > I'm a bit concerned that we are falling down on our commitment to > > > decide about GHC proposals in a timely manner. > > > Part of the problem is that at any moment I don't have a clear > > > snapshot in my head of what decisions are pending, and who is driving > > > them.  I know that Joachim hates manual solutions, but I have spent a > > > few minutes digging through my email to build > > >  * this spreadsheet giving the current status You all have edit > > > permissions.  It covers only the handful of proposals that are in our > > > court.   Can I suggest that we all use it to keep ourselves on the > > > ball?   E.g. as a shepherd you can use it to record who you are > > > waiting for, as I have done for #302. > > > You'll notice that we are behind on every one of them.  Remember, if > > > there edits we want the author to make, we push it back, out of our > > > court.  It can re-enter when the author re-submits. > > > If our commitments are over-ambitious, let's review them. > > > Tom: you are our official nudger.  Would you like to make you weekly > > > nudge into an email to the full committee, with a pointer to the > > > spreadsheet and your current understanding of who is responsible for > > > driving? > > > I hope this is helpful.  If not, let's think of something else! > > > Simon > > > _______________________________________________ > > > 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%7C339ecde3cd0345bb56c008d93c > > > c3520b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637607632780784446 > > > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > > > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hBK7hEfFzJhRh3iYskV8MCwHpr2jMYC > > > c6Ed7fCUu0ro%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%7C339ecde3cd0345bb > > 56c008d93cc3520b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63760763278079 > > 4437%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > > haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vn6ZhpdEb9QPd5KIMw6Wmg3QO7u51PJVNhlTSQO > > nJBQ%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%7C339ecde3cd0345bb56c00 > > 8d93cc3520b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637607632780794437% > > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi > > LCJXVCI6Mn0%3D%7C3000&sdata=EmSqsU2w3ARP3hXLA3xshhOt6zw%2Bn8LVx3qAy7sIGl > > g%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 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Mon Jul 12 07:39:29 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 12 Jul 2021 07:39:29 +0000 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: | we might be converging on something here. it seems that a stable URL that | summarizes the status quo is a core desire here. Yes, that's right, thanks. Plus * Editable by us all * Citing key dates * when it entered the committee's bailiwick, * when our action is due * Clickable link to proposal A table seems perfect. A block of text less so. That's why I chose a spreadsheet format. | BTW, if you want up-to-date information on proposals under discussion, the | links "List of proposals waiting for shepherd recommendation" and "List of | proposals waiting for committee decision" right in the beginning of... | is a good starting point It's a good starting point, but it doesn't give the above key info. Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Joachim Breitner | Sent: 11 July 2021 19:51 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] GHC proposals | | Hi, | | we might be converging on something here. it seems that a stable URL that | summarizes the status quo is a core desire here. | | I'd try to avoid adding more communication venues (we already have Github | and the mailing list). But how about whenever I send around the summary | mail, I also paste the status quo into the page at | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com | %2Fghc-proposals%2Fghc- | proposals%2Fwiki%2FStatus&data=04%7C01%7Csimonpj%40microsoft.com%7C12780 | b1684b64d7bdd6608d9449cd3c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637 | 616262730032384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi | LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Fl4qCZ4RAds8kYrr2890zoz5uu | 1aVcC5nTh2P6%2FiY24%3D&reserved=0 | | I'll tweak the markup next time so that it works well both in email and as | rendered markdown. | | BTW, if you want up-to-date information on proposals under discussion, the | links "List of proposals waiting for shepherd recommendation" and "List of | proposals waiting for committee decision" right in the beginning of | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com | %2Fghc-proposals%2Fghc- | proposals&data=04%7C01%7Csimonpj%40microsoft.com%7C12780b1684b64d7bdd660 | 8d9449cd3c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637616262730032384% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C1000&sdata=KYnxkG13G3RK6RQUp%2Bt3T0kHMpvslIbRBsDGKCRWdt | 4%3D&reserved=0 could be a good starting point. | | | Cheers, | Joachim | | Am Freitag, dem 09.07.2021 um 13:38 +0000 schrieb Simon Peyton Jones via | ghc-steering-committee: | > Good points. | > | > How about this: when you do the work for your monthly email, you update | the spreadsheet, including a prominent date saying "this was true on date | X". Zero extra work for you. | > | > That way I can have a bookmark to a table that shows a decent | approximation to the status quo. I find it hard to grep back through | mountains of email, be sure I'm looking at the latest status update from | you, etc. It's enough friction that I just don't do it. | > | > Tom, our "nudger" will find that useful -- and will doubtless update it if | he knows the status has changed (e.g he nudges someone and they say "oh I | did that"). | > | > The rest of us (esp shepherds) can use it as an aide memoire. (What | > proposals am I responsible for?) | > | > Would that be ok? | > | > Simon | > | > > -----Original Message----- | > > From: ghc-steering-committee | > > On Behalf Of Joachim | > > Breitner | > > Sent: 01 July 2021 20:06 | > > To: ghc-steering-committee at haskell.org | > > Subject: Re: [ghc-steering-committee] GHC proposals | > > | > > Hi, | > > | > > I understand the desire to have a constantly updated "dashboard". | > > But I don't think a spreadsheed will work. At least not if your | > > expectation is that we, collaboratively, keep it up to date. If we | > > already fall behind our actual review commitments, surely we'll | > > fall behind additional red tape commitments. And then we'll have a | > > file that we can't rely on because we wouldn't be confident that it | actually reflects reality. | > > | > > And it's not that I hates manual solutions. In fact, my | > > semi-regular "status" emails are fully manual! In a way you did | > > more or less what I do every time I create these: I did through my | > > email and curate the current status quo. This is tenable because | > > it's clear who does it (the secretary, instead of everybody), and | > > because it's an email there is no confusion as whether it is is up | > > to date - is is up to date the moment I write it, and makes no promises | about later states. | > > | > > So that's a difference in frequency, form and ownership (at intervals | vs. | > > continous; push email vs. pull URL; collectively vs. secretarial). | > > Your sheet also contains additional fields (Author, various dates) | > > - maybe I should include them in the status email. | > > | > > I don't want to stop us from trying out different procedures, | > > though, so if there is a general sentiment that a wiki-like process | > > (everyone collaboratively edits a common file) is worth exploring, | > > we can do that of course. But I miss the "yes please and I definitely | will keep it up to date" | > > cries from our crowd :-) | > > | > > Ultimately, the best would be a tool that uses the Github API to | > > create a dashboard (Note that most information on your sheet is | > > already present in github, especially as all status changes are | > > represented as label changes), maybe even with automatic nudging on | github or email. | > > | > > The next best thing is someone (but someone, not somemany) doing | > > that manually; maintaining a dashboard like yours, plus nudging. | > > But who wants to do manually what can be done (mostly) automated. | > > | > > | > > Cheers, | > > Joachim | > > | > > | > > Am Montag, dem 28.06.2021 um 09:56 +0000 schrieb Simon Peyton Jones | > > via | > > ghc-steering-committee: | > > > I'm a bit concerned that we are falling down on our commitment to | > > > decide about GHC proposals in a timely manner. | > > > Part of the problem is that at any moment I don't have a clear > | > > snapshot in my head of what decisions are pending, and who is | > > driving > them.  I know that Joachim hates manual solutions, but I | > > have spent a > few minutes digging through my email to build >  * | > > this spreadsheet giving the current status You all have edit > | > > permissions.  It covers only the handful of proposals that are in | > > our > court.   Can I suggest that we all use it to keep ourselves | > > on the > ball?   E.g. as a shepherd you can use it to record who | > > you are > waiting for, as I have done for #302. | > > > You'll notice that we are behind on every one of them.  Remember, | > > if > there edits we want the author to make, we push it back, out | > > of our > court.  It can re-enter when the author re-submits. | > > > If our commitments are over-ambitious, let's review them. | > > > Tom: you are our official nudger.  Would you like to make you | > > weekly > nudge into an email to the full committee, with a pointer | > > to the > spreadsheet and your current understanding of who is | > > responsible for > driving? | > > > I hope this is helpful.  If not, let's think of something else! | > > > Simon | > > > _______________________________________________ | > > > 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-committee | > > &a > | > > mp;data=04%7C01%7Csimonpj%40microsoft.com%7C339ecde3cd0345bb56c008d9 | > > 3c > | > > c3520b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376076327807844 | > > 46 > | > > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI | > > 6I > | > > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hBK7hEfFzJhRh3iYskV8MCwHpr2jM | > > YC | > > > c6Ed7fCUu0ro%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%7C339ecde3 | > > cd0345bb | > > | > > 56c008d93cc3520b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637607 | > > 63278079 | > > | > > 4437%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ | > > BTiI6Ik1 | > > haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vn6ZhpdEb9QPd5KIMw6Wmg3QO7u51PJ | > > VNhlTSQO | > > nJBQ%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.haske | > > ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > > | > > committee&data=04%7C01%7Csimonpj%40microsoft.com%7C339ecde3cd034 | > > 5bb56c00 | > > 8d93cc3520b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63760763278 | > > 0794437% | > > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 | > > Ik1haWwi | > > LCJXVCI6Mn0%3D%7C3000&sdata=EmSqsU2w3ARP3hXLA3xshhOt6zw%2Bn8LVx3 | > > qAy7sIGl | > > g%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%7C12780b1684b64d7bdd6608d944 | > 9cd3c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637616262730032384 | > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I | > k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=si1nlH3Y%2BVSIU9q3pDaSLfCqIOXAG | > Y8bxX2l3thWatA%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%7C12780b1684b64d7b | dd6608d9449cd3c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63761626273003 | 2384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ao2perWppuz85dmuTZUZRZ0ogtDOUW3EZ2b00rH | wgPc%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%7C12780b1684b64d7bdd660 | 8d9449cd3c9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637616262730032384% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C1000&sdata=si1nlH3Y%2BVSIU9q3pDaSLfCqIOXAGY8bxX2l3thWat | A%3D&reserved=0 From mail at joachim-breitner.de Mon Jul 12 07:53:05 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 12 Jul 2021 09:53:05 +0200 Subject: [ghc-steering-committee] GHC proposals In-Reply-To: References: Message-ID: Hi, Am Montag, dem 12.07.2021 um 07:39 +0000 schrieb Simon Peyton Jones: > >  we might be converging on something here. it seems that a stable > > URL that > >  summarizes the status quo is a core desire here. > > Yes, that's right, thanks. Plus > > * Editable by us all > * Citing key dates >     * when it entered the committee's bailiwick, >     * when our action is due > * Clickable link to proposal > > A table seems perfect. A block of text less so. That's why I chose > a spreadsheet format. > Yes, absolutely. I’ll experiment with a better layout and extra data next round. (and silently hope that someone who knows their way around Githubs API will step up and say “all this manual work is silly, here is my 100loc Haskell program that generates this report for you”.) Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Mon Jul 12 08:09:19 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 12 Jul 2021 08:09:19 +0000 Subject: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Partial Accept In-Reply-To: <010f017a933fbbe9-f5144cde-aba7-4f6c-a2b9-3f3918c8c741-000000@us-east-2.amazonses.com> References: <010f0179a51e4333-c762d7af-6f7e-4036-a04b-4ed60afd81ca-000000@us-east-2.amazonses.com> <1754f703-f87b-448b-bfd3-268226203b38@www.fastmail.com> <010f0179eca00f96-706787fc-ebda-4855-b38a-b7161d44f971-000000@us-east-2.amazonses.com> <77209cd3-2da0-4bda-8a09-a7870d7e9d22@www.fastmail.com> <7a913d64-b6a7-4d51-9b6c-7c6e9d2011d6@www.fastmail.com> <5813a08c390adf628f215ee4ba3fd22ef5a77d51.camel@joachim-breitner.de> <010f017a5ac7ed07-92163998-1078-4d7c-85aa-a34e30335f99-000000@us-east-2.amazonses.com> <010f017a933fbbe9-f5144cde-aba7-4f6c-a2b9-3f3918c8c741-000000@us-east-2.amazonses.com> Message-ID: I have added this as a comment in the GitHub repo, since others may want to express an opinion Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 11 July 2021 02:48 To: Eric Seidel Cc: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Partial Accept On Jul 9, 2021, at 12:35 AM, Eric Seidel > wrote: On Thu, Jul 1, 2021, at 13:16, Joachim Breitner wrote: a different way to phrase that question might be: Do we want these defaulting declarations to behave just exactly like named things, or exactly like typeclass instances, or do we afford a new class with it’s own exporting/importing behavior. Is that a fair assessment? Not entirely, I think. We currently have two types of import/export behavior: named things, and typeclass instances. The proposal as currently written places defaulting rules somewhere in between: defaulting rules are exported like named things, but imported like class instances. This is new, but not too foreign, as the behavior on both sides exactly matches existing behavior we're familiar with. It's just the combination that's new. This doesn't match my understanding of the proposal. It looks to me that, as written in the proposal, exports of a `default` would have to be explicit. That is, a module starting with `module M where ...` would not export any defaults. This fact is a bit implied in the proposal ("This proposal does not modify that behaviour: a default declaration by itself does not apply outside its module."), but it's my best understanding. --- Simon and I have discussed. We both came to an agreement that imports should have to be explicit. GHC currently has two import/export strategies. Strategy 1: Always. In the Always strategy, an entity is always exported from a module and always brought into scope from an imported module. The Always strategy is used for type and class instances. Strategy 2: Public. In the Public strategy, an entity is exported by default (no export list) or when explicitly included in an export list. It is brought into scope from an importing module by default (no import list) or when explicitly included in an import list. A Public entity may be excluded from scope by a `hiding` clause. All top-level named entities are exported/imported via the Public strategy. I propose (with Simon's support) Strategy 3: Private. In the Private strategy. an entity is exported only when explicitly included in an export list, and it is brought into scope from an imported module only when explicitly included in the import list. I propose we use Private for `default` declarations (only). Reasons: * Changing defaulting behavior really can launch the rockets. Suppose T has a Num instance whose fromInteger uses unsafePerformIO to launch the rockets. Then including T in an import list could make a very innocent-looking `x = 5` declaration launch the rockets. * GHC currently supports an option -ddump-minimal-imports, which displays import lists describing what symbols must be brought into scope from an imported module. If a `import M` import statement brought defaulting behavior into scope, then going from `import M` to `import M (foo, bar)` might deleteriously change defaulting behavior, thus invalidating the work of -ddump-minimal-imports. * The proposal as written does not describe how `module` exports work with named defaults. For example, what happens in `module B (module A) where import A`? Normally, that re-exports all names in scope both as `A.blah` and as `blah`. But, of course, a default isn't named in this way. So is the default exported? By requiring explicit inclusion in the export list, the Private strategy sidesteps this question. * This is a more conservative choice. We can always revisit this in the light of experience. However, if defaults were always imported, it would be much more disruptive to make them imported only by request. We have rightly identified that using the Private strategy would potentially reduce the usefulness of this idea, especially with alternative Preludes. As far as I know, GHC does not currently officially support having an alternative Prelude. That is, an "alternative Prelude" is really just disabling the import of base.Prelude and then importing some other module. However, we could imagine a compiler flag that specifies another package (or module name) to use as the Prelude... and then we could also specify how it is imported. For example, we could say that the Prelude is imported with > import Prelude > import Prelude ( default(..) ) where the second line says to grab all the defaults. I think this would be reasonable, but not necessary in the first version of this current proposal. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Mon Jul 12 13:52:01 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 12 Jul 2021 13:52:01 +0000 Subject: [ghc-steering-committee] #390: Fine-grained pragmas, recommendation: accept In-Reply-To: References: <989E9E72-9923-4870-B424-B1B2D07A738D@gmail.com> Message-ID: <010f017a9afd2eea-bbac2727-573e-4423-a5a9-fc69d9b16703-000000@us-east-2.amazonses.com> I'm happy with this updated proposal, though I've made a small suggestion about making the ;s optional. Regardless of whether this suggestion is taken, I support acceptance. Thanks, Richard > On Jul 4, 2021, at 5:12 AM, Vitaly Bragilevsky wrote: > > Dear Committee, > > I'm happy to repeat my recommendation to accept Alejandro's proposal which is now back from revision: > Fine-grained pragmas for classes, families, and instances > https://github.com/ghc-proposals/ghc-proposals/pull/390 > https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md > > All the issues that arose in the previous discussion are now resolved. Does anyone have something to add? > > Vitaly > > > > сб, 13 мар. 2021 г. в 12:38, Vitaly Bragilevsky >: > чт, 11 мар. 2021 г. в 16:31, Vladislav Zavialov (int-index) >: > I like the proposal and I would be happy to vote for its acceptance. However, it requires a little bit of polishing up with regards to its use of modifiers. In particular, it seems to treat modifiers as built-in units, whereas the core idea behind modifiers is that they are based on actual promoted types (with the exception of %1). > > Hence it seems appropriate to send it back for revision until this point is addressed. > > Yes, I agree. There is also another issue. I think we need either a deprecation story for UndecidableInstances, or a statement that it should survive with some motivation behind that. > > So, I'm sending this proposal back to Alejandro for review and set the "needs revision" label on GitHub. > > Vitaly > > - Vlad > > > On 20 Feb 2021, at 14:34, Vitaly Bragilevsky > wrote: > > > > Dear Committee, > > > > Our own Alejandro has been proposed > > Fine-grained pragmas for classes, families, and instances > > https://github.com/ghc-proposals/ghc-proposals/pull/390 > > https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md > > > > His idea is to bring the flexibility of overlaps/overlapping/overlappable pragmas to termination checking, type inference, and constraint solving. Alejandro proposes to introduce the following %-modifiers (as in already accepted #370, https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-modifiers.rst ): > > %NoTerminationCheck > > %LiberalCoverage > > %LiberalInjectivity > > %Overlapping > > %Overlappable > > %Overlaps > > to liberate conditions for classes and instances, type families, forall-types, etc. The first three modifiers can be used instead of the scary-sounding UndecidableInstances extension. The last three modifiers are supposed to be used instead of the overlap*-pragmas for instances we already have. Note that this proposal doesn't suggest deprecating those extensions and pragmas. > > > > I think that this proposal goes in the right direction and recommend accepting it. > > > > As far as I understand, all the committee members, including those with terms about to expire, have the right to either support this proposal or to raise a voice against it either here or at https://github.com/ghc-proposals/ghc-proposals/pull/390 . > > > > Regards, > > Vitaly > > > > > > > > _______________________________________________ > > 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 Fri Jul 16 15:21:53 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 16 Jul 2021 15:21:53 +0000 Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote Message-ID: Friends Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL deadline. I have not heard from Tom or Vitaly, I think, but I'll take silence for agreement with the ballot list. So it is time to vote! Please go here, and vote. Feel free to add pros/cons to the list on that page. Please vote by next Thursday, 22 July, at the latest. It's a balance of judgement, for sure, not technically complicated. Simon From: Simon Peyton Jones Sent: 28 June 2021 10:45 To: ghc-steering-committee at haskell.org Cc: Simon Peyton Jones Subject: RE: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) Dear Steering Committee Two weeks ago I asked * Are there any other alternatives you strongly want on the ballot? I got these responses * Joachim, Simon, Alejandro, Arnaud: nothing to add * Vitaly, Eric, Tom, Richard, Vlad: no response I'd love to hear from the five of you, please. I want to get a decision on this, and I can't do that if I don't hear from you. Thanks Simon From: ghc-steering-committee > On Behalf Of Simon Peyton Jones via ghc-steering-committee Sent: 15 June 2021 13:52 To: Joachim Breitner >; ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) | I'd like to reassing shepherding of this one. | | It seems to be clear that we want "something like this", there are many ways | to skin the cat, so it comes down to opinion and what we need is a decision | (or a call to votes). As with anything that's possibly quite opinionated, | it's good to have an authorative voice, so in this case, Simon PJ. | | Simon, can you either come up with a "all things considered, I think this | variant is the (narrowly) the best" recommendation or, alternative, a | "please vote on the following options" verdict? OK, to remind everyone * Here is the proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md * Here is the discussion: https://github.com/ghc-proposals/ghc-proposals/pull/302 The basic idea is to extend to lambda all the facilities that you get with function definitions, especially multiple patterns and guards. This seems clearly a good idea, whose only obstacle is syntactic. There are no conceptual or specification challenges. The only point at issue is that of concrete syntax. The proposal offers four possible syntactic options. After reviewing, I propose to discard (2) and (3) leaving these alternatives * Option (1) \cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } * Lives alongside \case, but allows multiple patterns * Other keywords are possible, but I think it must be a variant on \case * Option (4) Same, but use \case as the keyword * Incompatible with existing \case => extended transition period, unhappy users * \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens forever, which in the common case of a one argument lambda see clunky. * Option (X). Reject the proposal. Personally I favour (1). I'm relaxed about having multiple ways of saying the thing (think of let vs where), and I see no harm provided the two constructs look and behave the same. I've decided I like \cases precisely because it's the plural of \case, which is exactly what is going on. I think we'll end up having to vote on this, which is fine when it's a judgement call about syntax. But first: * Are there any other alternatives you strongly want on the ballot? I say "strongly" because I don't want to open up a big new debate... we at the stage of trying to narrow options. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Sat Jul 17 02:29:14 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Sat, 17 Jul 2021 02:29:14 +0000 Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote In-Reply-To: References: Message-ID: <010f017ab24be02f-4da9cf57-fd31-4084-8264-ec08f862cc0b-000000@us-east-2.amazonses.com> I'm struggling with this one, so I'll procrastinate by asking two clarifying questions: 1. Why does (2) not subsume MultiWayIf? The example in the MultiWayIf note seems to work just fine with syntax (2). 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I correct in saying that we'll lose \case{}? I said I'm struggling, so I will explain why: I really want this new syntax, and I would advocate a coding style that uses it often. But I'm quite concerned about language bloat, and I don't like adding a new construct without also planning to remove redundant ones. I'm not sure how to balance these two desires. Perhaps a night's sleep will yield insight. Richard > On Jul 16, 2021, at 11:21 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > Friends > > Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL deadline. > > I have not heard from Tom or Vitaly, I think, but I’ll take silence for agreement with the ballot list. > > So it is time to vote! > > Please go here , and vote. > > Feel free to add pros/cons to the list on that page. > > Please vote by next Thursday, 22 July, at the latest. It’s a balance of judgement, for sure, not technically complicated. > > Simon > > > > From: Simon Peyton Jones > > Sent: 28 June 2021 10:45 > To: ghc-steering-committee at haskell.org > Cc: Simon Peyton Jones > > Subject: RE: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) > > > Dear Steering Committee > > Two weeks ago I asked > > Are there any other alternatives you strongly want on the ballot? > > > I got these responses > > Joachim, Simon, Alejandro, Arnaud: nothing to add > Vitaly, Eric, Tom, Richard, Vlad: no response > I’d love to hear from the five of you, please. I want to get a decision on this, and I can’t do that if I don’t hear from you. > > Thanks > > Simon > > > > From: ghc-steering-committee > On Behalf Of Simon Peyton Jones via ghc-steering-committee > Sent: 15 June 2021 13:52 > To: Joachim Breitner >; ghc-steering-committee at haskell.org > Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) > > > | I’d like to reassing shepherding of this one. > | > | It seems to be clear that we want “something like this”, there are many ways > | to skin the cat, so it comes down to opinion and what we need is a decision > | (or a call to votes). As with anything that’s possibly quite opinionated, > | it’s good to have an authorative voice, so in this case, Simon PJ. > | > | Simon, can you either come up with a “all things considered, I think this > | variant is the (narrowly) the best” recommendation or, alternative, a > | “please vote on the following options” verdict? > > OK, to remind everyone > Here is the proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md > Here is the discussion: https://github.com/ghc-proposals/ghc-proposals/pull/302 > > The basic idea is to extend to lambda all the facilities that you get with function definitions, especially multiple patterns and guards. This seems clearly a good idea, whose only obstacle is syntactic. There are no conceptual or specification challenges. The only point at issue is that of concrete syntax. > > The proposal offers four possible syntactic options. After reviewing, I propose to discard (2) and (3) leaving these alternatives > > Option (1) \cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } > Lives alongside \case, but allows multiple patterns > Other keywords are possible, but I think it must be a variant on \case > Option (4) Same, but use \case as the keyword > Incompatible with existing \case => extended transition period, unhappy users > \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens forever, which in the common case of a one argument lambda see clunky. > Option (X). Reject the proposal. > > > Personally I favour (1). I’m relaxed about having multiple ways of saying the thing (think of let vs where), and I see no harm provided the two constructs look and behave the same. I’ve decided I like \cases precisely because it’s the plural of \case, which is exactly what is going on. > > I think we’ll end up having to vote on this, which is fine when it’s a judgement call about syntax. But first: > > Are there any other alternatives you strongly want on the ballot? > I say “strongly” because I don’t want to open up a big new debate… we at the stage of trying to narrow options. > > 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 marlowsd at gmail.com Sat Jul 17 11:21:10 2021 From: marlowsd at gmail.com (Simon Marlow) Date: Sat, 17 Jul 2021 12:21:10 +0100 Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote In-Reply-To: <010f017ab24be02f-4da9cf57-fd31-4084-8264-ec08f862cc0b-000000@us-east-2.amazonses.com> References: <010f017ab24be02f-4da9cf57-fd31-4084-8264-ec08f862cc0b-000000@us-east-2.amazonses.com> Message-ID: Hi Richard - I'm curious about the coding style that you would advocate that uses it often. Can you give an example? Personally I thought I would use \case when we introduced it, but in practice I find I want it rarely enough that I actually don't use it even in the places where it would be marginally shorter, purely because I'm optimising for code readability and I don't think \case helps (one could go either way on that though). I do find MultiWayIf to be useful in practice - it looks nice, its meaning is obvious, and it helps code readability. But as I've said before I would never use it if it was called \cases :) Cheers Simon On Sat, 17 Jul 2021 at 03:29, Richard Eisenberg wrote: > I'm struggling with this one, so I'll procrastinate by asking two > clarifying questions: > > 1. Why does (2) not subsume MultiWayIf? The example in the MultiWayIf note > seems to work just fine with syntax (2). > > 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I > correct in saying that we'll lose \case{}? > > I said I'm struggling, so I will explain why: I really want this new > syntax, and I would advocate a coding style that uses it often. But I'm > quite concerned about language bloat, and I don't like adding a new > construct without also planning to remove redundant ones. I'm not sure how > to balance these two desires. Perhaps a night's sleep will yield insight. > > Richard > > On Jul 16, 2021, at 11:21 AM, Simon Peyton Jones via > ghc-steering-committee wrote: > > Friends > > Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL > deadline. > > I have not heard from Tom or Vitaly, I think, but I’ll take silence for > agreement with the ballot list. > > So it is time to vote! > > Please go here > , > and vote. > > Feel free to add pros/cons to the list on that page. > > *Please vote by next Thursday, 22 July, at the latest*. It’s a balance > of judgement, for sure, not technically complicated. > > Simon > > > *From:* Simon Peyton Jones > *Sent:* 28 June 2021 10:45 > *To:* ghc-steering-committee at haskell.org > *Cc:* Simon Peyton Jones > *Subject:* RE: [ghc-steering-committee] Proposal #302: `\of` (New > Shepherd: Simon PJ) > > > > Dear Steering Committee > > Two weeks ago I asked > > - *Are there any other alternatives you strongly want on the ballot?* > > > > I got these responses > > - Joachim, Simon, Alejandro, Arnaud: nothing to add > - Vitaly, Eric, Tom, Richard, Vlad: no response > > I’d love to hear from the five of you, please. I want to get a decision > on this, and I can’t do that if I don’t hear from you. > > Thanks > > Simon > > > *From:* ghc-steering-committee > *On Behalf Of *Simon Peyton Jones via ghc-steering-committee > *Sent:* 15 June 2021 13:52 > *To:* Joachim Breitner ; > ghc-steering-committee at haskell.org > *Subject:* Re: [ghc-steering-committee] Proposal #302: `\of` (New > Shepherd: Simon PJ) > > > | I’d like to reassing shepherding of this one. > | > | It seems to be clear that we want “something like this”, there are many > ways > | to skin the cat, so it comes down to opinion and what we need is a > decision > | (or a call to votes). As with anything that’s possibly quite > opinionated, > | it’s good to have an authorative voice, so in this case, Simon PJ. > | > | Simon, can you either come up with a “all things considered, I think > this > | variant is the (narrowly) the best” recommendation or, alternative, a > | “please vote on the following options” verdict? > > OK, to remind everyone > > - Here is the proposal: > https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md > > - Here is the discussion: > https://github.com/ghc-proposals/ghc-proposals/pull/302 > > > > The basic idea is to extend to lambda all the facilities that you get with > function definitions, especially multiple patterns and guards. This seems > clearly a good idea, whose only obstacle is syntactic. There are no > conceptual or specification challenges. The only point at issue is that of > concrete syntax. > > The proposal offers four possible syntactic options. After reviewing, I > propose to discard (2) and (3) leaving these alternatives > > > - *Option (1) *\cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } > > > - Lives alongside \case, but allows multiple patterns > - Other keywords are possible, but I think it must be a variant on > \case > > > - *Option (4)* Same, but use \case as the keyword > > > - Incompatible with existing \case => extended transition period, > unhappy users > - \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens > forever, which in the common case of a one argument lambda see clunky. > > > - *Option (X).* Reject the proposal. > > > > Personally I favour (1). I’m relaxed about having multiple ways of > saying the thing (think of let vs where), and I see no harm provided the > two constructs look and behave the same. I’ve decided I like \cases > precisely because it’s the plural of \case, which is exactly what is going > on. > > I think we’ll end up having to vote on this, which is fine when it’s a > judgement call about syntax. But first: > > - *Are there any other alternatives you strongly want on the ballot?* > > I say “strongly” because I don’t want to open up a big new debate… we at > the stage of trying to narrow options. > > 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 lists at richarde.dev Sat Jul 17 18:22:29 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Sat, 17 Jul 2021 18:22:29 +0000 Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote In-Reply-To: References: <010f017ab24be02f-4da9cf57-fd31-4084-8264-ec08f862cc0b-000000@us-east-2.amazonses.com> Message-ID: <010f017ab5b49728-bce646f6-dc11-4661-8432-f7239d653129-000000@us-east-2.amazonses.com> > On Jul 17, 2021, at 7:21 AM, Simon Marlow wrote: > > Hi Richard - I'm curious about the coding style that you would advocate that uses it often. Can you give an example? > Sure: > not :: Bool -> Bool > not = \cases > False -> True > True -> False > > filter :: (a -> Bool) -> [a] -> [a] > filter = \cases > _ [] -> [] > pred (x : xs) | pred x -> x : filter pred xs > | otherwise -> filter pred xs This style has a few advantages over the more typical one: - The name is not repeated each time, which is otherwise a refactoring hazard. - The indentation of each line does not depend on the name, which is otherwise a separate refactoring hazard. - It is possible to define a helper function in a where clause that scopes over the whole function. Alternative version of filter > filter :: (a -> Bool) -> [a] -> [a] > filter pred = \cases > [] -> [] > (x : xs) | pred x -> x : filtered > | otherwise -> filtered > where filtered = filter pred xs This alternative has further advantages: - It is clear which parameters are matched against and which are not (assuming the matched parameters go last). - A `where` clause can scope over the whole function, or an individual match, depending on its indentation level. A style more at odds with history might be > filter :: forall a. (a -> Bool) -> [a] -> [a] = \cases > ... which is even less repetitive. Would I *require* any of this for all of Haskell? Never. But it's appealing to me in its concision and expressive power. Richard From simonpj at microsoft.com Mon Jul 19 09:53:19 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 19 Jul 2021 09:53:19 +0000 Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote In-Reply-To: <010f017ab24be02f-4da9cf57-fd31-4084-8264-ec08f862cc0b-000000@us-east-2.amazonses.com> References: <010f017ab24be02f-4da9cf57-fd31-4084-8264-ec08f862cc0b-000000@us-east-2.amazonses.com> Message-ID: Thanks Richard. Personally, I'm very relaxed about adding an extra keyword to get more convenience. Haskell very consciously doesn't adhere to "there should be one way to do one thing". (Think let vs where, case vs if, and many others.) I'm relaxed, provided it carries low cognitive and explanatory overhead. And I think that is true of adding \cases to an existing \case. Another example: we could remove MultiWayIf if we had \cases. And yet, when there are zero args "if" is quite ergonomic. It's not 100% obvious to me that that it is worth removing it. Leaving it in, (1) give "if" = arity 0, \case = arity 1, \cases = any arity. Your questions are well targeted. 1. Why does (2) not subsume MultiWayIf? The example in the MultiWayIf note seems to work just fine with syntax (2). The proposal explicitly says n>=1 in the BNF. But I think you are right... n=0 would also be unambiguous. 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I correct in saying that we'll lose \case{}? Yes that too is true, and is a strike against (2) and (4). I have updated the voting page to reflect these observations. Simon From: Richard Eisenberg Sent: 17 July 2021 03:29 To: Simon Peyton Jones Cc: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote I'm struggling with this one, so I'll procrastinate by asking two clarifying questions: 1. Why does (2) not subsume MultiWayIf? The example in the MultiWayIf note seems to work just fine with syntax (2). 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I correct in saying that we'll lose \case{}? I said I'm struggling, so I will explain why: I really want this new syntax, and I would advocate a coding style that uses it often. But I'm quite concerned about language bloat, and I don't like adding a new construct without also planning to remove redundant ones. I'm not sure how to balance these two desires. Perhaps a night's sleep will yield insight. Richard On Jul 16, 2021, at 11:21 AM, Simon Peyton Jones via ghc-steering-committee > wrote: Friends Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL deadline. I have not heard from Tom or Vitaly, I think, but I'll take silence for agreement with the ballot list. So it is time to vote! Please go here, and vote. Feel free to add pros/cons to the list on that page. Please vote by next Thursday, 22 July, at the latest. It's a balance of judgement, for sure, not technically complicated. Simon From: Simon Peyton Jones > Sent: 28 June 2021 10:45 To: ghc-steering-committee at haskell.org Cc: Simon Peyton Jones > Subject: RE: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) Dear Steering Committee Two weeks ago I asked * Are there any other alternatives you strongly want on the ballot? I got these responses * Joachim, Simon, Alejandro, Arnaud: nothing to add * Vitaly, Eric, Tom, Richard, Vlad: no response I'd love to hear from the five of you, please. I want to get a decision on this, and I can't do that if I don't hear from you. Thanks Simon From: ghc-steering-committee > On Behalf Of Simon Peyton Jones via ghc-steering-committee Sent: 15 June 2021 13:52 To: Joachim Breitner >; ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) | I'd like to reassing shepherding of this one. | | It seems to be clear that we want "something like this", there are many ways | to skin the cat, so it comes down to opinion and what we need is a decision | (or a call to votes). As with anything that's possibly quite opinionated, | it's good to have an authorative voice, so in this case, Simon PJ. | | Simon, can you either come up with a "all things considered, I think this | variant is the (narrowly) the best" recommendation or, alternative, a | "please vote on the following options" verdict? OK, to remind everyone * Here is the proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md * Here is the discussion: https://github.com/ghc-proposals/ghc-proposals/pull/302 The basic idea is to extend to lambda all the facilities that you get with function definitions, especially multiple patterns and guards. This seems clearly a good idea, whose only obstacle is syntactic. There are no conceptual or specification challenges. The only point at issue is that of concrete syntax. The proposal offers four possible syntactic options. After reviewing, I propose to discard (2) and (3) leaving these alternatives * Option (1) \cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } * Lives alongside \case, but allows multiple patterns * Other keywords are possible, but I think it must be a variant on \case * Option (4) Same, but use \case as the keyword * Incompatible with existing \case => extended transition period, unhappy users * \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens forever, which in the common case of a one argument lambda see clunky. * Option (X). Reject the proposal. Personally I favour (1). I'm relaxed about having multiple ways of saying the thing (think of let vs where), and I see no harm provided the two constructs look and behave the same. I've decided I like \cases precisely because it's the plural of \case, which is exactly what is going on. I think we'll end up having to vote on this, which is fine when it's a judgement call about syntax. But first: * Are there any other alternatives you strongly want on the ballot? I say "strongly" because I don't want to open up a big new debate... we at the stage of trying to narrow options. 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 rae at richarde.dev Mon Jul 19 19:22:03 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 19 Jul 2021 19:22:03 +0000 Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept In-Reply-To: References: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com> Message-ID: <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> This thread has trailed off, having escaped the pen while the shepherd (me) was distracted (first by travel, then by POPL). I'd like to resume it. You may wish to refresh yourself on the content of the proposal, which I summarize in https://mail.haskell.org/pipermail/ghc-steering-committee/2021-May/002454.html My recommendation remains to accept, for the same reasons it was originally. This proposal is somewhat controversial (it has garnered 278 comments!), and so it would be ideal to hear opinions from as many of you as possible, even if the opinion is just to accept the recommendation. Simon M wrote the last email in the thread before the hiatus, with a few questions. I'll attempt these now: > On Jun 7, 2021, at 4:19 AM, Simon Marlow wrote: > > As a user I usually need to know whether I'm looking at a type or a term in the code. For doing renaming in your head, it makes a difference whether you're looking at a type or a term: the namespaces are different. > > Is it reasonable for that to apply to visible type application too? That is, are we assuming that the user knows they're looking at a type, or are we assuming that the user "shouldn't need to care", or something else? My answer: "shouldn't need to care". This is enshrined in the Syntactic Unification Principle (SUP) in https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst: > Syntactic Unification Principle (SUP). In the absence of punning, there is no difference between type-syntax and term-syntax. Here, "punning" means having the same identifier in scope in both terms and types. Forgetting about the possibility of punning, users shouldn't care about whether they're writing a term or a type. All syntax will have equivalent meanings in the two environments. The *only* challenge is around namespacing -- and the LSP says that, in a term, names should correspond to term-level entities. > > What could we do if we were allowed to treat types differently? Well, we already do various bits of magic in T2T. But we could also use different name resolution rules. That doesn't necessarily mean we have to defer renaming until during type checking: we could resolve each name twice, once for the term context and once for the type context, and then pick one of these later when we apply the T2T mapping. (earlier Vlad objected to this idea on the grounds that it might introduce spurious recursive dependencies, though). We *could* do this, yes, but it's in violation of the LSP (and, perhaps, the SUP). Of course, we wrote the LSP and can choose to break it, but, like Simon PJ, I think the ability to resolve names in the absence of type-checking is very valuable to readers of code. -------------- One development on the GitHub tracker that may be of interest: @AntC2 proposes a migration trick to allow functions to migrate from today's world to a world with this new feature. The key example is sizeOf. Today, we have > sizeOf :: Storable a => a -> Int where the argument to sizeOf is always unevaluated and ignored. The proposal under consideration would allow this to change to > sizeOf' :: forall a -> Storable a => Int (NB: do not get distracted by the movement of the constraint, which will be invisible at usage sites) The problem is that we would have to make sizeOf' a new function, likely exported from a new library, in order not to clash. This is annoying. So @AntC2 proposes (in my paraphrasing, which @AntC2 has agreed with): * With -XNoRequiredTypeArguments, if a function f takes a required type argument of kind Type, then instead you can pass an arbitrary expression. f is called with the type of that expression; the expression is never evaluated. This would allow, e.g. sizeOf True to work with both the old and the new types. I am against this little addition, because it's narrowly applicable and has negative educational consequences (that is, someone encountering the type written for sizeOf' but then seeing sizeOf' True work correctly will be quite befuddled and likely form a misunderstanding of how forall -> works). Yet I can see this idea's appeal, thus my mentioning it here. ------------------ It would be great if I could hear from everyone on the committee in the next two weeks with their opinion about accepting this proposal. Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Jul 19 20:18:00 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 19 Jul 2021 20:18:00 +0000 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> Message-ID: <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than that), Arnaud is in support, but the rest of you have been quiet. Thanks! Richard > On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud wrote: > > Dear all, > > Let me raise this proposal again. Very few of us have opined, and while I'd usually be happy to consider silence as assent, this is a rather large proposal which may require a few more pairs of eyes. Please consider giving this one a read and share your thoughts. If you can't do so right now, please let me know when you will be able to, so that we can plan accordingly. > > This is an important proposal, I'm keen on seeing its design finalised. > > /Arnaud > > On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg > wrote: > > >> On May 26, 2021, at 3:28 AM, Spiwack, Arnaud > wrote: >> >> I'm realising that I inverted additional options 1 and 3 in my reply. To spell things out: I'm in favour of the namespace introduced for every datatype and such; and weakly in favour of anonymous modules, for which I prefer the `_` syntax than simply omitting the name. > > Oh, good. I was very confused here, but I decided not to push on it. I'm similarly weakly in favor of (1), but I can't get myself to decide firmly on whether to go with alternative (7). Going with (7) is a little more consistent with other features, but it adds more symbols to the source text that could otherwise be omitted. So I'm pretty ambivalent. > > Richard > >> >> On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg > wrote: >> >> >>> On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena > wrote: >>> >>> - I am not sure of the benefit of allowing (1), compared with the possible surprise of users. >>> - I do not fully understand (2). >>> - I think (3) would be great, if we ensure that nothing changes if I don’t use “qualified”, even if -XLocalModules is on. >> >> If in the language, I would use (1) -- anonymous local modules -- regularly, when defining a function or class instance with a bunch of "local" helper functions. Of course, if we can't omit the module name, I will suffer no great harm. >> >> I cannot offer the guarantee you seek in (3), but I don't think you want it. (If nothing changes, then the feature has no effect!) Here is a scenario where (3) could cause trouble: >> >>> import Data.Set as Set ( abcde ) >>> >>> data Set = Mk { abcdf :: Int } >>> >>> blah = Set.abcdf >> >> Previously, GHC would have suggested that you perhaps misspelled abcde. Now, you'll get (presumably) a type error. >> >> Here's another case: >> >>> import Data.Set as Set ( Set ) >>> >>> data Set = Mk >>> >>> x :: Set.Set >> >> Everything is happy today, but with -XLocalModules (and (3)), the type of x is an ambiguous name. >> >> Any example that causes trouble, though, will have something in common: an imported module name (possibly via an alias) that matches a locally defined type name. I would imagine this pattern is rare in practice, and that the benefit of (3) would outweigh the number of times that a problem like this bites. >> >> I, too, could live without (2). >> >> Richard > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at richarde.dev Mon Jul 19 20:26:08 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 19 Jul 2021 20:26:08 +0000 Subject: [ghc-steering-committee] Proposal #412: Explicit Splice Imports; rec: accept In-Reply-To: References: Message-ID: <010f017ac0728427-77a68b3e-a9c5-4d68-9f62-0b89d9f6756d-000000@us-east-2.amazonses.com> I support acceptance of the proposal. RIchard > On Jun 17, 2021, at 9:13 AM, Spiwack, Arnaud wrote: > > I agree with the sentiment so far: this is a well constructed proposal which makes a good case for the fine details of the proposed specification. The goal is also quite desirable (it has been brought up by other before, such as http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-gets-right/ or https://github.com/ghc-proposals/ghc-proposals/pull/243 ). > > On Tue, Jun 15, 2021 at 9:02 AM Alejandro Serrano Mena > wrote: > Dear all, > I like the proposal, and I think my life will automatically improve with this. > > Alejandro > > El 14 jun 2021 16:09:06, Vladislav Zavialov (int-index) > escribió: > Dear Committee, > > Proposal #412 "Explicit Splice Imports” by Matthew Pickering has been submitted for our consideration. > > Read it here: https://github.com/mpickering/ghc-proposals/blob/splice-imports/proposals/0000-splice-imports.rst > Discussion here: https://github.com/ghc-proposals/ghc-proposals/pull/412 > > The goals of this proposal are to (1) improve parallel compilation, (2) speed up -fno-code and IDEs that rely on it, (3) reduce binary sizes or at least reduce linking overhead, (4) create phase separation useful for cross-compilation. > > All of the above are achieved by introducing a new form of import called a splice-import. Compare: > > import M > import splice H > > Under this proposal, names imported from M can *not* be used in top-level Template Haskell splices, whereas names imported from H can be used *only* in Template Haskell splices. > > At this point I will note that I do not particularly like the proposed syntax, which looks as if we’re importing a splice rather than importing names for use in splices. In the “Alternatives” section, you will find several other options such as “import {-# SPLICE #-} M”, “import for splice H”, “$(import H)”, and so on. That said, let us not get bogged down in the discussion of syntax before we agree on the semantics. If we choose to accept the proposal, I will organize a vote on the syntax. > > Regarding the semantics, I believe the general idea behind the proposal is good, and I recommend acceptance. It provides a way for the programmer to specify the intended usage of an import (whether it is for normal programming or metaprogramming), and GHC can use this information to build the program more effectively (more parallelism, less linking). In ways that I do not entirely understand, it is allegedly good for future work on cross-compilation. > > Let me know what you think. > > - Vlad > _______________________________________________ > 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 Tue Jul 20 06:19:26 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 20 Jul 2021 06:19:26 +0000 (UTC) Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> Message-ID: I am morally sympathetic to the overall goal, but didn't find the time to scrutinize the details. Usually in that case I hope that the other committee members due the due diligence and hope I can just follow along. Is that helpful? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomjharding at live.co.uk Wed Jul 21 11:07:00 2021 From: tomjharding at live.co.uk (Tom Harding) Date: Wed, 21 Jul 2021 11:07:00 +0000 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> Message-ID: I may well have said this before, but I’m enthusiastically in support of this proposal. In fact the first five motivating examples are things I could use regularly. I particularly like the `import Foo ( Foo, module Foo )` idiom, as it will almost halve the import blocks I have at the moment. Not sure that I can add much beyond what has already been discussed here, other than to say it’s a +1 from me! Thanks, Tom > On 20 Jul 2021, at 07:19, Joachim Breitner wrote: > > I am morally sympathetic to the overall goal, but didn't find the time to scrutinize the details. Usually in that case I hope that the other committee members due the due diligence and hope I can just follow along. Is that helpful? > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From simonpj at microsoft.com Wed Jul 21 12:30:51 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 21 Jul 2021 12:30:51 +0000 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> Message-ID: To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3) 1. Import and export of qualified names. This seems like the Main Point. 2. Local import (in a let/where). This seems low pain but low gain. 3. Local modules. This is the one I'm struggling with. There is more on the (tail end of the) PR https://github.com/ghc-proposals/ghc-proposals/pull/283 I am open to being educated. I would love to hear from other members of the committee. Tom’s thumbs-up seemed to about (1), without saying anything about (2) and (3). One mechanism (if my categorisation is correct) could be to ask everyone to vote (yes/no/maybe) on all of 1,2,3. Arnaud, you are our shepherd. Your sheep await your command. Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 19 July 2021 21:18 To: Spiwack, Arnaud Cc: GHC Steering Committee Subject: Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than that), Arnaud is in support, but the rest of you have been quiet. Thanks! Richard On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud > wrote: Dear all, Let me raise this proposal again. Very few of us have opined, and while I'd usually be happy to consider silence as assent, this is a rather large proposal which may require a few more pairs of eyes. Please consider giving this one a read and share your thoughts. If you can't do so right now, please let me know when you will be able to, so that we can plan accordingly. This is an important proposal, I'm keen on seeing its design finalised. /Arnaud On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg > wrote: On May 26, 2021, at 3:28 AM, Spiwack, Arnaud > wrote: I'm realising that I inverted additional options 1 and 3 in my reply. To spell things out: I'm in favour of the namespace introduced for every datatype and such; and weakly in favour of anonymous modules, for which I prefer the `_` syntax than simply omitting the name. Oh, good. I was very confused here, but I decided not to push on it. I'm similarly weakly in favor of (1), but I can't get myself to decide firmly on whether to go with alternative (7). Going with (7) is a little more consistent with other features, but it adds more symbols to the source text that could otherwise be omitted. So I'm pretty ambivalent. Richard On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg > wrote: On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena > wrote: - I am not sure of the benefit of allowing (1), compared with the possible surprise of users. - I do not fully understand (2). - I think (3) would be great, if we ensure that nothing changes if I don’t use “qualified”, even if -XLocalModules is on. If in the language, I would use (1) -- anonymous local modules -- regularly, when defining a function or class instance with a bunch of "local" helper functions. Of course, if we can't omit the module name, I will suffer no great harm. I cannot offer the guarantee you seek in (3), but I don't think you want it. (If nothing changes, then the feature has no effect!) Here is a scenario where (3) could cause trouble: import Data.Set as Set ( abcde ) data Set = Mk { abcdf :: Int } blah = Set.abcdf Previously, GHC would have suggested that you perhaps misspelled abcde. Now, you'll get (presumably) a type error. Here's another case: import Data.Set as Set ( Set ) data Set = Mk x :: Set.Set Everything is happy today, but with -XLocalModules (and (3)), the type of x is an ambiguous name. Any example that causes trouble, though, will have something in common: an imported module name (possibly via an alias) that matches a locally defined type name. I would imagine this pattern is rare in practice, and that the benefit of (3) would outweigh the number of times that a problem like this bites. I, too, could live without (2). Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Thu Jul 22 13:39:22 2021 From: eric at seidel.io (Eric Seidel) Date: Thu, 22 Jul 2021 09:39:22 -0400 Subject: [ghc-steering-committee] =?utf-8?q?Proposal_=23302=3A_Multiway_la?= =?utf-8?q?mbda=3A_time_to_vote?= In-Reply-To: References: <010f017ab24be02f-4da9cf57-fd31-4084-8264-ec08f862cc0b-000000@us-east-2.amazonses.com> Message-ID: On Mon, Jul 19, 2021, at 05:53, Simon Peyton Jones via ghc-steering-committee wrote: > 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I > correct in saying that we'll lose \case{}? > > Yes that too is true, and is a strike against (2) and (4). I'm confused, the proposal explicitly says > If no clauses are given, i.e. the expression in question if \case {}, how many arguments this expression should take is ambiguous. However, currently, with -XEmptyCase, this expression is already valid and takes a single argument. Thus, to maintain backwards compatibility and for lack of a better option, this proposal does not alter the behavior of this expression. https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md#alternative-2-comma-separated-case What's the problem with this solution? \case {} can still be instantiated at any arity, but it will explode after applying a single argument. From simonpj at microsoft.com Thu Jul 22 15:34:11 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 22 Jul 2021 15:34:11 +0000 Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote In-Reply-To: References: <010f017ab24be02f-4da9cf57-fd31-4084-8264-ec08f862cc0b-000000@us-east-2.amazonses.com> Message-ID: | > 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I | > correct in saying that we'll lose \case{}? | > | > Yes that too is true, and is a strike against (2) and (4). | | I'm confused, the proposal explicitly says Aha, yes, you are right. Under (2) and (4), * if you supply *any* clauses the thing desugars to a lambda with the arity specified by the clauses * if you supply *no* clauses, the thing desugars to a lambda with arity 1, namely \x. case x of {} I'll modify the voting page. Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Eric Seidel | Sent: 22 July 2021 14:39 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda: time | to vote | | On Mon, Jul 19, 2021, at 05:53, Simon Peyton Jones via ghc-steering- | committee wrote: | > 2. (2) and (4) seem to lose \case{}, which is useful in practice. Am I | > correct in saying that we'll lose \case{}? | > | > Yes that too is true, and is a strike against (2) and (4). | | I'm confused, the proposal explicitly says | | > If no clauses are given, i.e. the expression in question if \case {}, how | many arguments this expression should take is ambiguous. However, currently, | with -XEmptyCase, this expression is already valid and takes a single | argument. Thus, to maintain backwards compatibility and for lack of a better | option, this proposal does not alter the behavior of this expression. | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com | %2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F0000-lambda- | layout.md%23alternative-2-comma-separated- | case&data=04%7C01%7Csimonpj%40microsoft.com%7C14976dfa458c469a46a008d94d | 1633d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637625580724196361%7CUnk | nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV | CI6Mn0%3D%7C3000&sdata=skhFsQ4rI354wZVyBFJndPfeWHAyba79MznmPNmlxIA%3D&am | p;reserved=0 | | What's the problem with this solution? \case {} can still be instantiated at | any arity, but it will explode after applying a single argument. | _______________________________________________ | 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%7C14976dfa458c469a46a00 | 8d94d1633d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637625580724196361% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=4exfYaewnD%2BqnYd%2BI64VRlsTtX2QnN8X0pukt17r | ZfA%3D&reserved=0 From simonpj at microsoft.com Thu Jul 22 15:36:13 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 22 Jul 2021 15:36:13 +0000 Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote In-Reply-To: References: Message-ID: Vlad, Alejandro, Arnaud Today is the deadline. Please vote! Thanks Simon From: Simon Peyton Jones Sent: 16 July 2021 16:22 To: ghc-steering-committee at haskell.org Cc: Simon Peyton Jones Subject: Proposal #302: Multiway lambda: time to vote Friends Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL deadline. I have not heard from Tom or Vitaly, I think, but I'll take silence for agreement with the ballot list. So it is time to vote! Please go here, and vote. Feel free to add pros/cons to the list on that page. Please vote by next Thursday, 22 July, at the latest. It's a balance of judgement, for sure, not technically complicated. Simon From: Simon Peyton Jones > Sent: 28 June 2021 10:45 To: ghc-steering-committee at haskell.org Cc: Simon Peyton Jones > Subject: RE: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) Dear Steering Committee Two weeks ago I asked * Are there any other alternatives you strongly want on the ballot? I got these responses * Joachim, Simon, Alejandro, Arnaud: nothing to add * Vitaly, Eric, Tom, Richard, Vlad: no response I'd love to hear from the five of you, please. I want to get a decision on this, and I can't do that if I don't hear from you. Thanks Simon From: ghc-steering-committee > On Behalf Of Simon Peyton Jones via ghc-steering-committee Sent: 15 June 2021 13:52 To: Joachim Breitner >; ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Proposal #302: `\of` (New Shepherd: Simon PJ) | I'd like to reassing shepherding of this one. | | It seems to be clear that we want "something like this", there are many ways | to skin the cat, so it comes down to opinion and what we need is a decision | (or a call to votes). As with anything that's possibly quite opinionated, | it's good to have an authorative voice, so in this case, Simon PJ. | | Simon, can you either come up with a "all things considered, I think this | variant is the (narrowly) the best" recommendation or, alternative, a | "please vote on the following options" verdict? OK, to remind everyone * Here is the proposal: https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md * Here is the discussion: https://github.com/ghc-proposals/ghc-proposals/pull/302 The basic idea is to extend to lambda all the facilities that you get with function definitions, especially multiple patterns and guards. This seems clearly a good idea, whose only obstacle is syntactic. There are no conceptual or specification challenges. The only point at issue is that of concrete syntax. The proposal offers four possible syntactic options. After reviewing, I propose to discard (2) and (3) leaving these alternatives * Option (1) \cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } * Lives alongside \case, but allows multiple patterns * Other keywords are possible, but I think it must be a variant on \case * Option (4) Same, but use \case as the keyword * Incompatible with existing \case => extended transition period, unhappy users * \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens forever, which in the common case of a one argument lambda see clunky. * Option (X). Reject the proposal. Personally I favour (1). I'm relaxed about having multiple ways of saying the thing (think of let vs where), and I see no harm provided the two constructs look and behave the same. I've decided I like \cases precisely because it's the plural of \case, which is exactly what is going on. I think we'll end up having to vote on this, which is fine when it's a judgement call about syntax. But first: * Are there any other alternatives you strongly want on the ballot? I say "strongly" because I don't want to open up a big new debate... we at the stage of trying to narrow options. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Thu Jul 22 16:40:07 2021 From: eric at seidel.io (Eric Seidel) Date: Thu, 22 Jul 2021 12:40:07 -0400 Subject: [ghc-steering-committee] =?utf-8?q?Proposal_=23302=3A_Multiway_la?= =?utf-8?q?mbda=3A_time=09to_vote?= In-Reply-To: References: Message-ID: <6653de3b-0d6e-43da-9218-6850284d7067@www.fastmail.com> Let me make a last minute argument *against (1)*. My issue with (1) is similar to what Richard and Simon M have already raised, that we're adding a new piece of syntax that is redundant in principle with the existing \case. By that I mean that main reason for adding syntax for multi-arg case is concerns around back compat. If we could go back in time and revise the original \case syntax to support multiple arguments, would we still end up with a single-arg construct and a multi-arg construct? I think probably not. I do find \case itself useful, and would like to see it gain the ability to take multiple arguments, which is why I support (2). But it feels very clumsy to have to think about how many arguments we're taking when choosing syntax. This is a much smaller and local issue than choosing between let and where (which have a much larger affect on the overall code structure and layout), and so for me it doesn't rise to the level of warranting multiple choices of syntax. On Thu, Jul 22, 2021, at 11:36, Simon Peyton Jones via ghc-steering-committee wrote: > > Vlad, Alejandro, Arnaud > Today is the deadline. Please vote > ! > Thanks > Simon > > *From:* Simon Peyton Jones > *Sent:* 16 July 2021 16:22 > *To:* ghc-steering-committee at haskell.org > *Cc:* Simon Peyton Jones > *Subject:* Proposal #302: Multiway lambda: time to vote > > Friends > Sorry to be slow on #302: multi-way lambda. I was diverted by the > POPL deadline. > I have not heard from Tom or Vitaly, I think, but I’ll take silence for > agreement with the ballot list. > So it is time to vote! > Please go here > , and vote. > Feel free to add pros/cons to the list on that page. > *Please vote by next Thursday, 22 July, at the latest*. It’s a balance > of judgement, for sure, not technically complicated. > Simon > > *From:* Simon Peyton Jones > *Sent:* 28 June 2021 10:45 > *To:* ghc-steering-committee at haskell.org > *Cc:* Simon Peyton Jones > *Subject:* RE: [ghc-steering-committee] Proposal #302: `\of` (New > Shepherd: Simon PJ) > > Dear Steering Committee > Two weeks ago I asked > * *Are there any other alternatives you *strongly* want on the ballot?* > > I got these responses > * Joachim, Simon, Alejandro, Arnaud: nothing to add > * Vitaly, Eric, Tom, Richard, Vlad: no response > I’d love to hear from the five of you, please. I want to get a > decision on this, and I can’t do that if I don’t hear from you. > Thanks > Simon > > *From:* ghc-steering-committee > *On Behalf Of *Simon > Peyton Jones via ghc-steering-committee > *Sent:* 15 June 2021 13:52 > *To:* Joachim Breitner ; > ghc-steering-committee at haskell.org > *Subject:* Re: [ghc-steering-committee] Proposal #302: `\of` (New > Shepherd: Simon PJ) > > | I’d like to reassing shepherding of this one. > > | > > | It seems to be clear that we want “something like this”, there are many ways > > | to skin the cat, so it comes down to opinion and what we need is a decision > > | (or a call to votes). As with anything that’s possibly quite opinionated, > > | it’s good to have an authorative voice, so in this case, Simon PJ. > > | > > | Simon, can you either come up with a “all things considered, I think this > > | variant is the (narrowly) the best” recommendation or, alternative, a > > | “please vote on the following options” verdict? > > > > OK, to remind everyone > > * Here is the proposal: > https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md > * Here is the discussion: > https://github.com/ghc-proposals/ghc-proposals/pull/302 > > > > The basic idea is to extend to lambda all the facilities that you get > with function definitions, especially multiple patterns and guards. > This seems clearly a good idea, whose only obstacle is syntactic. > There are no conceptual or specification challenges. The only point at > issue is that of concrete syntax. > > > > The proposal offers four possible syntactic options. After reviewing, > I propose to discard (2) and (3) leaving these alternatives > > > > * *Option (1) *\cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } > * Lives alongside \case, but allows multiple patterns > * Other keywords are possible, but I think it must be a variant on > \case > * *Option (4)* Same, but use \case as the keyword > * Incompatible with existing \case => extended transition period, > unhappy users > * \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens > forever, which in the common case of a one argument lambda see clunky. > * *Option (X).* Reject the proposal. > > Personally I favour (1). I’m relaxed about having multiple ways of > saying the thing (think of let vs where), and I see no harm provided > the two constructs look and behave the same. I’ve decided I like > \cases precisely because it’s the plural of \case, which is exactly > what is going on. > I think we’ll end up having to vote on this, which is fine when it’s a > judgement call about syntax. But first: > * *Are there any other alternatives you *strongly* want on the ballot?* > I say “strongly” because I don’t want to open up a big new debate… we > at the stage of trying to narrow options. > Thanks > Simon > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From simonpj at microsoft.com Thu Jul 22 16:54:49 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 22 Jul 2021 16:54:49 +0000 Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote In-Reply-To: <6653de3b-0d6e-43da-9218-6850284d7067@www.fastmail.com> References: <6653de3b-0d6e-43da-9218-6850284d7067@www.fastmail.com> Message-ID: Thanks Eric | adding syntax for multi-arg case is concerns around back compat. If we could | go back in time and revise the original \case syntax to support multiple | arguments, would we still end up with a single-arg construct and a multi-arg | construct? I think probably not. Actually I don't agree. I think we might well have \case (for 1) and \cases (for 0-n) because * the cognitive overhead is vanishingly small (especially given the singular/plural form * the absence of parens in the very common case of \case is extremely convenient I actively like the signal that \cases gives me, up front, "here comes an nary lambda", rather than the very quiet commas of (2). Whereas I know that \case is always unary. Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Eric Seidel | Sent: 22 July 2021 17:40 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Proposal #302: Multiway lambda: time | to vote | | Let me make a last minute argument *against (1)*. | | My issue with (1) is similar to what Richard and Simon M have already | raised, that we're adding a new piece of syntax that is redundant in | principle with the existing \case. By that I mean that main reason for | adding syntax for multi-arg case is concerns around back compat. If we could | go back in time and revise the original \case syntax to support multiple | arguments, would we still end up with a single-arg construct and a multi-arg | construct? I think probably not. | | I do find \case itself useful, and would like to see it gain the ability to | take multiple arguments, which is why I support (2). But it feels very | clumsy to have to think about how many arguments we're taking when choosing | syntax. This is a much smaller and local issue than choosing between let and | where (which have a much larger affect on the overall code structure and | layout), and so for me it doesn't rise to the level of warranting multiple | choices of syntax. | | On Thu, Jul 22, 2021, at 11:36, Simon Peyton Jones via ghc-steering- | committee wrote: | > | > Vlad, Alejandro, Arnaud | > Today is the deadline. Please vote | > | ! | > Thanks | > Simon | > | > *From:* Simon Peyton Jones | > *Sent:* 16 July 2021 16:22 | > *To:* ghc-steering-committee at haskell.org | > *Cc:* Simon Peyton Jones | > *Subject:* Proposal #302: Multiway lambda: time to vote | > | > Friends | > Sorry to be slow on #302: multi-way lambda. I was diverted by the | > POPL deadline. | > I have not heard from Tom or Vitaly, I think, but I'll take silence | > for agreement with the ballot list. | > So it is time to vote! | > Please go here | > | , and vote. | > Feel free to add pros/cons to the list on that page. | > *Please vote by next Thursday, 22 July, at the latest*. It's a | > balance of judgement, for sure, not technically complicated. | > Simon | > | > *From:* Simon Peyton Jones | > *Sent:* 28 June 2021 10:45 | > *To:* ghc-steering-committee at haskell.org | > *Cc:* Simon Peyton Jones | > *Subject:* RE: [ghc-steering-committee] Proposal #302: `\of` (New | > Shepherd: Simon PJ) | > | > Dear Steering Committee | > Two weeks ago I asked | > * *Are there any other alternatives you *strongly* want on the | > ballot?* | > | > I got these responses | > * Joachim, Simon, Alejandro, Arnaud: nothing to add | > * Vitaly, Eric, Tom, Richard, Vlad: no response I'd love to hear from | > the five of you, please. I want to get a decision on this, and I | > can't do that if I don't hear from you. | > Thanks | > Simon | > | > *From:* ghc-steering-committee | > *On Behalf Of *Simon | > Peyton Jones via ghc-steering-committee | > *Sent:* 15 June 2021 13:52 | > *To:* Joachim Breitner ; | > ghc-steering-committee at haskell.org | > *Subject:* Re: [ghc-steering-committee] Proposal #302: `\of` (New | > Shepherd: Simon PJ) | > | > | I'd like to reassing shepherding of this one. | > | > | | > | > | It seems to be clear that we want "something like this", there are | > | many ways | > | > | to skin the cat, so it comes down to opinion and what we need is a | > | decision | > | > | (or a call to votes). As with anything that's possibly quite | > | opinionated, | > | > | it's good to have an authorative voice, so in this case, Simon PJ. | > | > | | > | > | Simon, can you either come up with a "all things considered, I | > | think this | > | > | variant is the (narrowly) the best" recommendation or, alternative, | > | a | > | > | "please vote on the following options" verdict? | > | > | > | > OK, to remind everyone | > | > * Here is the proposal: | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | > ub.com%2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2F | > 0000-lambda-layout.md&data=04%7C01%7Csimonpj%40microsoft.com%7C330 | > 56874189e46ad8d5e08d94d2f7635%7C72f988bf86f141af91ab2d7cd011db47%7C1%7 | > C0%7C637625689263054559%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLC | > JQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Cd%2FnJ | > abIxYklNI7vnWZzIjD72%2BMnRYWvAzo7mgZ0Fk%3D&reserved=0 | > hub.com%2FJakobBruenker%2Fghc-proposals%2Fblob%2Fpatch-1%2Fproposals%2 | > F0000-lambda-layout.md&data=04%7C01%7Csimonpj%40microsoft.com%7C4ae55d | > 76732448a0c3a508d93a1955ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% | > 7C637604702751348160%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | > joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Hvxpaew8S333OX7 | > IvW9cfD003mLSZxpjRdjOotGVZMA%3D&reserved=0> | > * Here is the discussion: | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | > ub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302&data=04%7C01%7 | > Csimonpj%40microsoft.com%7C33056874189e46ad8d5e08d94d2f7635%7C72f988bf | > 86f141af91ab2d7cd011db47%7C1%7C0%7C637625689263054559%7CUnknown%7CTWFp | > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn | > 0%3D%7C3000&sdata=QUFXbh%2BZO0wyiZeHPkO46I2dFHJoFeAbxgDq5S3LhlU%3D | > &reserved=0 | > hub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F302&data=04%7C01%7Csi | > monpj%40microsoft.com%7C4ae55d76732448a0c3a508d93a1955ed%7C72f988bf86f | > 141af91ab2d7cd011db47%7C1%7C0%7C637604702751358154%7CUnknown%7CTWFpbGZ | > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 | > D%7C1000&sdata=1aYsUzlUaixOxNvW2%2FEkLNbImFD7yLBT273QFA76ZEI%3D&reserv | > ed=0> | > | > | > The basic idea is to extend to lambda all the facilities that you get | > with function definitions, especially multiple patterns and guards. | > This seems clearly a good idea, whose only obstacle is syntactic. | > There are no conceptual or specification challenges. The only point | > at issue is that of concrete syntax. | > | > | > | > The proposal offers four possible syntactic options. After reviewing, | > I propose to discard (2) and (3) leaving these alternatives | > | > | > | > * *Option (1) *\cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } | > * Lives alongside \case, but allows multiple patterns | > * Other keywords are possible, but I think it must be a variant on | > \case | > * *Option (4)* Same, but use \case as the keyword | > * Incompatible with existing \case => extended transition period, | > unhappy users | > * \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens | > forever, which in the common case of a one argument lambda see clunky. | > * *Option (X).* Reject the proposal. | > | > Personally I favour (1). I'm relaxed about having multiple ways of | > saying the thing (think of let vs where), and I see no harm provided | > the two constructs look and behave the same. I've decided I like | > \cases precisely because it's the plural of \case, which is exactly | > what is going on. | > I think we'll end up having to vote on this, which is fine when it's a | > judgement call about syntax. But first: | > * *Are there any other alternatives you *strongly* want on the | > ballot?* I say "strongly" because I don't want to open up a big new | > debate... we at the stage of trying to narrow options. | > Thanks | > Simon | > _______________________________________________ | > 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%7C33056874189e46ad8d5e08d94d | > 2f7635%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637625689263054559 | > %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I | > k1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1xK4Ihtf6wnYuoQoIHYmGAmRS1aUnAY | > uiopPd01PNwE%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%7C33056874189e46ad8d5e0 | 8d94d2f7635%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637625689263054559% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C3000&sdata=1xK4Ihtf6wnYuoQoIHYmGAmRS1aUnAYuiopPd01PNwE% | 3D&reserved=0 From arnaud.spiwack at tweag.io Fri Jul 23 06:22:29 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 23 Jul 2021 08:22:29 +0200 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> Message-ID: Dear all, I know that this proposal is a bit long, but it also deserves your attention. I feel it's going to be easier to set a bit of time to review the proposal if I give a deadline. So let's say the following: I'll be on holiday starting two weeks from now (6th August), can I have everybody's opinion by then? --- Recapitulating the opinions so far - I'm personally pretty enthusiastic about the entire proposal - Tom voiced quite enthusiastic support for what Simon PJ calls (1), and (3) - Simon PJ wants (1), is not against (2), is mildly against (3) - Joachim suspends his judgement (which is fine, but hopefully not too many of us do this :-) ). On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones wrote: > To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3) > > 1. Import and export of qualified names. This seems like the Main > Point. > 2. Local import (in a let/where). This seems low pain but low gain. > 3. Local modules. This is the one I'm struggling with. > > There is more on the (tail end of the) PR > https://github.com/ghc-proposals/ghc-proposals/pull/283 > > > > I am open to being educated. > > > I would love to hear from other members of the committee. Tom’s thumbs-up > seemed to about (1), without saying anything about (2) and (3). > > > > One mechanism (if my categorisation is correct) could be to ask everyone > to vote (yes/no/maybe) on all of 1,2,3. > > > > Arnaud, you are our shepherd. Your sheep await your command. > > > > Simon > > > > *From:* ghc-steering-committee > *On Behalf Of *Richard Eisenberg > *Sent:* 19 July 2021 21:18 > *To:* Spiwack, Arnaud > *Cc:* GHC Steering Committee > *Subject:* Re: [ghc-steering-committee] #283: Local modules (again), > recommendation: accept > > > > Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than > that), Arnaud is in support, but the rest of you have been quiet. > > > > Thanks! > > Richard > > > > On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud > wrote: > > > > Dear all, > > > > Let me raise this proposal again. Very few of us have opined, and while > I'd usually be happy to consider silence as assent, this is a rather large > proposal which may require a few more pairs of eyes. Please consider giving > this one a read and share your thoughts. If you can't do so right now, > please let me know when you will be able to, so that we can plan > accordingly. > > > > This is an important proposal, I'm keen on seeing its design finalised. > > > > /Arnaud > > > > On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg > wrote: > > > > > > On May 26, 2021, at 3:28 AM, Spiwack, Arnaud > wrote: > > > > I'm realising that I inverted additional options 1 and 3 in my reply. To > spell things out: I'm in favour of the namespace introduced for every > datatype and such; and weakly in favour of anonymous modules, for which I > prefer the `_` syntax than simply omitting the name. > > > > Oh, good. I was very confused here, but I decided not to push on it. I'm > similarly weakly in favor of (1), but I can't get myself to decide firmly > on whether to go with alternative (7). Going with (7) is a little more > consistent with other features, but it adds more symbols to the source text > that could otherwise be omitted. So I'm pretty ambivalent. > > > > Richard > > > > > > On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg > wrote: > > > > > > On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena > wrote: > > > > - I am not sure of the benefit of allowing (1), compared with the possible > surprise of users. > > - I do not fully understand (2). > > - I think (3) would be great, if we ensure that nothing changes if I don’t > use “qualified”, even if -XLocalModules is on. > > > > If in the language, I would use (1) -- anonymous local modules -- > regularly, when defining a function or class instance with a bunch of > "local" helper functions. Of course, if we can't omit the module name, I > will suffer no great harm. > > > > I cannot offer the guarantee you seek in (3), but I don't think you want > it. (If nothing changes, then the feature has no effect!) Here is a > scenario where (3) could cause trouble: > > > > import Data.Set as Set ( abcde ) > > > > data Set = Mk { abcdf :: Int } > > > > blah = Set.abcdf > > > > Previously, GHC would have suggested that you perhaps misspelled abcde. > Now, you'll get (presumably) a type error. > > > > Here's another case: > > > > import Data.Set as Set ( Set ) > > > > data Set = Mk > > > > x :: Set.Set > > > > Everything is happy today, but with -XLocalModules (and (3)), the type of > x is an ambiguous name. > > > > Any example that causes trouble, though, will have something in common: an > imported module name (possibly via an alias) that matches a locally defined > type name. I would imagine this pattern is rare in practice, and that the > benefit of (3) would outweigh the number of times that a problem like this > bites. > > > > I, too, could live without (2). > > > > Richard > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Fri Jul 23 07:21:10 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 23 Jul 2021 07:21:10 +0000 Subject: [ghc-steering-committee] Proposal #302: Multiway lambda: time to vote In-Reply-To: References: Message-ID: Hi everybody, I’ve just casted my vote (I was on holidays with no easy access to reading these long-is threads), hopefully it’s not too late. Alejandro El 22 jul 2021 17:36:13, Simon Peyton Jones escribió: > Vlad, Alejandro, Arnaud > > Today is the deadline. Please vote > > ! > > Thanks > > Simon > > > > *From:* Simon Peyton Jones > *Sent:* 16 July 2021 16:22 > *To:* ghc-steering-committee at haskell.org > *Cc:* Simon Peyton Jones > *Subject:* Proposal #302: Multiway lambda: time to vote > > > > Friends > > Sorry to be slow on #302: multi-way lambda. I was diverted by the POPL > deadline. > > I have not heard from Tom or Vitaly, I think, but I’ll take silence for > agreement with the ballot list. > > So it is time to vote! > > Please go here > , > and vote. > > Feel free to add pros/cons to the list on that page. > > *Please vote by next Thursday, 22 July, at the latest*. It’s a balance > of judgement, for sure, not technically complicated. > > Simon > > > > *From:* Simon Peyton Jones > *Sent:* 28 June 2021 10:45 > *To:* ghc-steering-committee at haskell.org > *Cc:* Simon Peyton Jones > *Subject:* RE: [ghc-steering-committee] Proposal #302: `\of` (New > Shepherd: Simon PJ) > > > > Dear Steering Committee > > Two weeks ago I asked > > - *Are there any other alternatives you strongly want on the ballot?* > > > > I got these responses > > - Joachim, Simon, Alejandro, Arnaud: nothing to add > - Vitaly, Eric, Tom, Richard, Vlad: no response > > I’d love to hear from the five of you, please. I want to get a decision > on this, and I can’t do that if I don’t hear from you. > > Thanks > > Simon > > > > *From:* ghc-steering-committee > *On Behalf Of *Simon Peyton Jones via ghc-steering-committee > *Sent:* 15 June 2021 13:52 > *To:* Joachim Breitner ; > ghc-steering-committee at haskell.org > *Subject:* Re: [ghc-steering-committee] Proposal #302: `\of` (New > Shepherd: Simon PJ) > > > > | I’d like to reassing shepherding of this one. > > | > > | It seems to be clear that we want “something like this”, there are many > ways > > | to skin the cat, so it comes down to opinion and what we need is a > decision > > | (or a call to votes). As with anything that’s possibly quite > opinionated, > > | it’s good to have an authorative voice, so in this case, Simon PJ. > > | > > | Simon, can you either come up with a “all things considered, I think > this > > | variant is the (narrowly) the best” recommendation or, alternative, a > > | “please vote on the following options” verdict? > > > > OK, to remind everyone > > - Here is the proposal: > https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-lambda-layout.md > > - Here is the discussion: > https://github.com/ghc-proposals/ghc-proposals/pull/302 > > > > > The basic idea is to extend to lambda all the facilities that you get with > function definitions, especially multiple patterns and guards. This seems > clearly a good idea, whose only obstacle is syntactic. There are no > conceptual or specification challenges. The only point at issue is that of > concrete syntax. > > > > The proposal offers four possible syntactic options. After reviewing, I > propose to discard (2) and (3) leaving these alternatives > > > > - *Option (1) *\cases { p1 p2 -> rhs1; q1 q2 -> rhs2 } > - Lives alongside \case, but allows multiple patterns > - Other keywords are possible, but I think it must be a variant on > \case > - *Option (4)* Same, but use \case as the keyword > - Incompatible with existing \case => extended transition period, > unhappy users > - \case { (Just x) -> rhs1; Nothing -> rhs2 } will require parens > forever, which in the common case of a one argument lambda see clunky. > - *Option (X).* Reject the proposal. > > > > Personally I favour (1). I’m relaxed about having multiple ways of > saying the thing (think of let vs where), and I see no harm provided the > two constructs look and behave the same. I’ve decided I like \cases > precisely because it’s the plural of \case, which is exactly what is going > on. > > I think we’ll end up having to vote on this, which is fine when it’s a > judgement call about syntax. But first: > > - *Are there any other alternatives you strongly want on the ballot?* > > I say “strongly” because I don’t want to open up a big new debate… we at > the stage of trying to narrow options. > > Thanks > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Fri Jul 23 07:44:21 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 23 Jul 2021 07:44:21 +0000 Subject: [ghc-steering-committee] #390: Fine-grained pragmas, recommendation: accept In-Reply-To: <010f017a9afd2eea-bbac2727-573e-4423-a5a9-fc69d9b16703-000000@us-east-2.amazonses.com> References: <989E9E72-9923-4870-B424-B1B2D07A738D@gmail.com> <010f017a9afd2eea-bbac2727-573e-4423-a5a9-fc69d9b16703-000000@us-east-2.amazonses.com> Message-ID: Dear all, I’ve just updated the proposal following a great suggestion by Vlad. Unfortunately, I don’t know enough about GHC’s parsing machinery to answer the question posed by Richard. I’ll repeat it in case somebody in the Committee can shed some light on it: The proposal use ; to separate the modifiers from the declarations. > Combined with the layout rule this allows us to write in two forms: > > > %NoTerminationCheck ; instance C Int where ... > > %NoTerminationCheck > > instance C Int where … > > Would it be possible to allow the modifier to simply precede the > `instance` without turning the parser into a mess? > Regards, Alejandro El 12 jul 2021 15:52:01, Richard Eisenberg escribió: > I'm happy with this updated proposal, though I've made a small suggestion > about making the ;s optional. > > Regardless of whether this suggestion is taken, I support acceptance. > > Thanks, > Richard > > On Jul 4, 2021, at 5:12 AM, Vitaly Bragilevsky > wrote: > > Dear Committee, > > I'm happy to repeat my recommendation to accept Alejandro's proposal which > is now back from revision: > Fine-grained pragmas for classes, families, and instances > https://github.com/ghc-proposals/ghc-proposals/pull/390 > > https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md > > All the issues that arose in the previous discussion are now resolved. > Does anyone have something to add? > > Vitaly > > > > сб, 13 мар. 2021 г. в 12:38, Vitaly Bragilevsky : > >> чт, 11 мар. 2021 г. в 16:31, Vladislav Zavialov (int-index) < >> vlad.z.4096 at gmail.com>: >> >>> I like the proposal and I would be happy to vote for its acceptance. >>> However, it requires a little bit of polishing up with regards to its use >>> of modifiers. In particular, it seems to treat modifiers as built-in units, >>> whereas the core idea behind modifiers is that they are based on actual >>> promoted types (with the exception of %1). >>> >>> Hence it seems appropriate to send it back for revision until this point >>> is addressed. >>> >> >> Yes, I agree. There is also another issue. I think we need either a >> deprecation story for UndecidableInstances, or a statement that it should >> survive with some motivation behind that. >> >> So, I'm sending this proposal back to Alejandro for review and set the >> "needs revision" label on GitHub. >> >> Vitaly >> >>> >>> - Vlad >>> >>> > On 20 Feb 2021, at 14:34, Vitaly Bragilevsky >>> wrote: >>> > >>> > Dear Committee, >>> > >>> > Our own Alejandro has been proposed >>> > Fine-grained pragmas for classes, families, and instances >>> > https://github.com/ghc-proposals/ghc-proposals/pull/390 >>> > >>> https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/0000-fine-grained-undecidable.md >>> > >>> > His idea is to bring the flexibility of >>> overlaps/overlapping/overlappable pragmas to termination checking, type >>> inference, and constraint solving. Alejandro proposes to introduce the >>> following %-modifiers (as in already accepted #370, >>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0370-modifiers.rst >>> ): >>> > %NoTerminationCheck >>> > %LiberalCoverage >>> > %LiberalInjectivity >>> > %Overlapping >>> > %Overlappable >>> > %Overlaps >>> > to liberate conditions for classes and instances, type families, >>> forall-types, etc. The first three modifiers can be used instead of the >>> scary-sounding UndecidableInstances extension. The last three modifiers are >>> supposed to be used instead of the overlap*-pragmas for instances we >>> already have. Note that this proposal doesn't suggest deprecating those >>> extensions and pragmas. >>> > >>> > I think that this proposal goes in the right direction and recommend >>> accepting it. >>> > >>> > As far as I understand, all the committee members, including those >>> with terms about to expire, have the right to either support this proposal >>> or to raise a voice against it either here or at >>> https://github.com/ghc-proposals/ghc-proposals/pull/390. >>> > >>> > Regards, >>> > Vitaly >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 Jul 23 07:53:34 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 23 Jul 2021 07:53:34 +0000 Subject: [ghc-steering-committee] #392: Clarify modifiers design principle (recommendation: acceptance) In-Reply-To: References: Message-ID: Dear all, Richard has now updated the proposal, but only Arnaud has commented on it. I think this requires a few more eyes, since it will permeate the language once people start using linear types, and we are already thinking about introducing modifiers in other parts. In fact, I’ve realised that there’s a (grammar) conflict between this proposal and https://github.com/ghc-proposals/ghc-proposals/pull/390 (the fine-grained pragmas for type classes and instances). This proposal defines topdecl ::= {modifier} 'type' simpletype '=' type | {modifier} 'data' [context '=>'] simpletype ['=' constrs] [deriving] | {modifier} 'newtype' [context '=>'] simpletype = newconstr [deriving] | {modifier} 'class' [scontext '=>'] tycls tyvar ['where' cdecls] | {modifier} 'instance' [scontext '=>'] qtycls inst ['where' idecls] But #390 defines (note the ; at the end of the modifiers block): modifiers : {- empty -} | ('%' qtycon)* ';' cl_decl : modifiers 'class' tycl_hdr fds where_cls I guess we should sort this out before accepting any of them. Alejandro El 28 jun 2021 21:26:45, Alejandro Serrano Mena escribió: > Richard, will you take care of making those small changes to the proposal? > That way we could mark this as accepted. > > Regards, > Alejandro > > El 28 jun 2021 9:01:28, Spiwack, Arnaud > escribió: > >> Yes, I believe that Richard and I are in agreement now. I don't think all >> the conclusions have been added to the proposal yet, though; but whatever's >> left, it's fairly minor. >> >> On Thu, Jun 24, 2021 at 1:29 PM Alejandro Serrano Mena >> wrote: >> >>> Dear all, >>> This discussion has been dormant for some time, but it’s time to revive >>> it! >>> >>> Richard, Arnaud, did you manage to reach conclusion about the >>> modification to the proposal? >>> >>> Apart from that, is there any other concern about the proposal? As I >>> said in my original message, this is a very small amendment to an >>> already-existing proposal, so if we accepted the previous one I see no >>> problem in this one. I’ll wait until Richard and Arnaud get back on the >>> issue, and then assume that silence for a week is acceptance. >>> >>> Regards, >>> Alejandro >>> >>> El 11 jun 2021 14:55:41, Spiwack, Arnaud >>> escribió: >>> >>>> I think that my discussion with Richard has come to a conclusion (it >>>> should incur a small modification to the proposal). >>>> >>>> It is a very small (amendment to a) proposal, let's find a consensus on >>>> this one quickly. >>>> >>>> >>>> On Wed, May 12, 2021 at 11:26 AM Spiwack, Arnaud < >>>> arnaud.spiwack at tweag.io> wrote: >>>> >>>>> I've commented on the PR [ >>>>> https://github.com/ghc-proposals/ghc-proposals/pull/392#pullrequestreview-657652189 >>>>> ] the changes on the syntax of lambda expressions are not motivated at all, >>>>> I think at the very least there should be a discussion in the Alternatives >>>>> section. >>>>> >>>>> But mostly, I'm worried about the implications/interactions that these >>>>> changes have with linear types. >>>>> >>>>> (I'll be off for the rest of the week starting tonight, so I'll be >>>>> back on this conversation on Monday, most likely) >>>>> >>>>> On Tue, May 11, 2021 at 10:10 AM Alejandro Serrano Mena < >>>>> trupill at gmail.com> wrote: >>>>> >>>>>> Dear Committee, >>>>>> This proposal seems a natural extension of #370, covering some >>>>>> additional cases (modifiers to classes and other declarations) that we’ve >>>>>> found along the way. My recommendation is acceptance. >>>>>> >>>>>> Regards, >>>>>> Alejandro >>>>>> >>>>>> On 4 May 2021 at 09:41:56, Joachim Breitner >>>>>> wrote: >>>>>> >>>>>>> Dear Committe, >>>>>>> >>>>>>> Clarify modifiers design principle >>>>>>> has been proposed by Richard >>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/392 >>>>>>> >>>>>>> This is an amendmend to #370, see the PR description for links to >>>>>>> diffs >>>>>>> etc. >>>>>>> >>>>>>> I propose Alejandro as the shepherd, as he shepherded #370 before. >>>>>>> >>>>>>> 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 trupill at gmail.com Fri Jul 23 09:50:14 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 23 Jul 2021 02:50:14 -0700 Subject: [ghc-steering-committee] Scoping of types Message-ID: Dear Committee, There’s a lot happening right now in the GHC proposals repo about scoping of types in different elements in the language. Richard asked for our decision in #238, but following a very good suggestion from Joachim, I think it’s better to give an overview on what’s going on. In my opinion, this should lead to a consolidation of the different proposals into a unified design. *Current status* In Haskell 2010 there’s no way to refer to type variables introduced in a type signature. For a long time, GHC has shipped with -XScopedTypeVariables, which introduced scoping for types by prepending them with `forall`. We could then use it in other types, or as part of a type application if -XTypeApplications is on. > id :: forall a. a -> a > id x = f @a x > where f y = y In the past 3 years we’ve accepted two proposals which extend this ability: - First to patterns https://github.com/ghc-proposals/ghc-proposals/pull/126, so we can write `id @a x = …` - Then to lambdas https://github.com/ghc-proposals/ghc-proposals/pull/155, so we can write `id = \@a x -> …` *What is going on* It seems that the accepted proposals were not quite right. We have two on-going proposals to *amend* the current ones: - https://github.com/ghc-proposals/ghc-proposals/pull/291 proposes simplifications to type variable patterns. As I understand this would make type variables in patterns behave like term variables (cannot be repeated, occurrences in inner scopes shadow the outer one, and so on). - https://github.com/ghc-proposals/ghc-proposals/pull/238 introduces -XTypeAbstractions, which make the combination of `forall` and `\@a` behave “as it should be”. But to be honest, I do not fully grasp the problems before, so neither how this amendment solves the problem; there’s a pointer to the GHC issue tracker where some incompatibility is discussed https://gitlab.haskell.org/ghc/ghc/-/issues/16734#note_203412 - https://github.com/ghc-proposals/ghc-proposals/pull/420 amends the current behaviour of signatures in patterns (what happens if I write `id (x :: a)` ). So we have different ways to introduce new type variables: `f :: forall a. …`, `f @a = …`, `f = \@a -> …`, `f (x :: a) = …`; and it’s very unclear what the scoping mechanism for each one should be. I think the problem is characterised very well in the following comment by Simon PJ https://github.com/ghc-proposals/ghc-proposals/pull/291#issuecomment-726715932 Note that this problem is arising in other places, too. For example #281, which adds visible `forall a -> ` ( https://github.com/ghc-proposals/ghc-proposals/pull/281) is also talking about name resolution (see https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-884810016 for an example). *How should we proceed* Personally, I am a bit worried about having divergent designs on this matter, and the fact that no fewer than 2 amendments are being proposed (!) For me, the best would be to come up with a unified design of how scoping works for types, covering all possible ways to introduce and resolve them. I am happy to help with this. Another important point seems to be how far we want to get from the current status quo (-XScopedTypeVariables make a type variable in a signature scope in its body, type variables in pattern signatures are always fresh), and how that fits with the overall -XDependentHaskell initiative. Kind regards, Alejandro -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Fri Jul 23 10:00:40 2021 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 23 Jul 2021 11:00:40 +0100 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> Message-ID: Just so I'm not completely silent: in the past I was generally in favour but had some suggestions. It looks like the proposal has undergone a lot of rewrites since I last reviewed it (or perhaps I just don't remember it all that well), I've started to go through it again but this is a biggie! I think a deadline is a good idea. Cheers Simon On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud wrote: > Dear all, > > I know that this proposal is a bit long, but it also deserves your > attention. > > I feel it's going to be easier to set a bit of time to review the proposal > if I give a deadline. So let's say the following: I'll be on holiday > starting two weeks from now (6th August), can I have everybody's opinion by > then? > > --- > > Recapitulating the opinions so far > > - I'm personally pretty enthusiastic about the entire proposal > - Tom voiced quite enthusiastic support for what Simon PJ calls (1), > and (3) > - Simon PJ wants (1), is not against (2), is mildly against (3) > - Joachim suspends his judgement (which is fine, but hopefully not too > many of us do this :-) ). > > > On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones > wrote: > >> To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3) >> >> 1. Import and export of qualified names. This seems like the Main >> Point. >> 2. Local import (in a let/where). This seems low pain but low gain. >> 3. Local modules. This is the one I'm struggling with. >> >> There is more on the (tail end of the) PR >> https://github.com/ghc-proposals/ghc-proposals/pull/283 >> >> >> >> I am open to being educated. >> >> >> I would love to hear from other members of the committee. Tom’s >> thumbs-up seemed to about (1), without saying anything about (2) and (3). >> >> >> >> One mechanism (if my categorisation is correct) could be to ask everyone >> to vote (yes/no/maybe) on all of 1,2,3. >> >> >> >> Arnaud, you are our shepherd. Your sheep await your command. >> >> >> >> Simon >> >> >> >> *From:* ghc-steering-committee < >> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard >> Eisenberg >> *Sent:* 19 July 2021 21:18 >> *To:* Spiwack, Arnaud >> *Cc:* GHC Steering Committee >> *Subject:* Re: [ghc-steering-committee] #283: Local modules (again), >> recommendation: accept >> >> >> >> Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than >> that), Arnaud is in support, but the rest of you have been quiet. >> >> >> >> Thanks! >> >> Richard >> >> >> >> On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud >> wrote: >> >> >> >> Dear all, >> >> >> >> Let me raise this proposal again. Very few of us have opined, and while >> I'd usually be happy to consider silence as assent, this is a rather large >> proposal which may require a few more pairs of eyes. Please consider giving >> this one a read and share your thoughts. If you can't do so right now, >> please let me know when you will be able to, so that we can plan >> accordingly. >> >> >> >> This is an important proposal, I'm keen on seeing its design finalised. >> >> >> >> /Arnaud >> >> >> >> On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg >> wrote: >> >> >> >> >> >> On May 26, 2021, at 3:28 AM, Spiwack, Arnaud >> wrote: >> >> >> >> I'm realising that I inverted additional options 1 and 3 in my reply. To >> spell things out: I'm in favour of the namespace introduced for every >> datatype and such; and weakly in favour of anonymous modules, for which I >> prefer the `_` syntax than simply omitting the name. >> >> >> >> Oh, good. I was very confused here, but I decided not to push on it. I'm >> similarly weakly in favor of (1), but I can't get myself to decide firmly >> on whether to go with alternative (7). Going with (7) is a little more >> consistent with other features, but it adds more symbols to the source text >> that could otherwise be omitted. So I'm pretty ambivalent. >> >> >> >> Richard >> >> >> >> >> >> On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg >> wrote: >> >> >> >> >> >> On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena >> wrote: >> >> >> >> - I am not sure of the benefit of allowing (1), compared with the >> possible surprise of users. >> >> - I do not fully understand (2). >> >> - I think (3) would be great, if we ensure that nothing changes if I >> don’t use “qualified”, even if -XLocalModules is on. >> >> >> >> If in the language, I would use (1) -- anonymous local modules -- >> regularly, when defining a function or class instance with a bunch of >> "local" helper functions. Of course, if we can't omit the module name, I >> will suffer no great harm. >> >> >> >> I cannot offer the guarantee you seek in (3), but I don't think you want >> it. (If nothing changes, then the feature has no effect!) Here is a >> scenario where (3) could cause trouble: >> >> >> >> import Data.Set as Set ( abcde ) >> >> >> >> data Set = Mk { abcdf :: Int } >> >> >> >> blah = Set.abcdf >> >> >> >> Previously, GHC would have suggested that you perhaps misspelled abcde. >> Now, you'll get (presumably) a type error. >> >> >> >> Here's another case: >> >> >> >> import Data.Set as Set ( Set ) >> >> >> >> data Set = Mk >> >> >> >> x :: Set.Set >> >> >> >> Everything is happy today, but with -XLocalModules (and (3)), the type of >> x is an ambiguous name. >> >> >> >> Any example that causes trouble, though, will have something in common: >> an imported module name (possibly via an alias) that matches a locally >> defined type name. I would imagine this pattern is rare in practice, and >> that the benefit of (3) would outweigh the number of times that a problem >> like this bites. >> >> >> >> I, too, could live without (2). >> >> >> >> 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 eric at seidel.io Fri Jul 23 11:04:03 2021 From: eric at seidel.io (Eric Seidel) Date: Fri, 23 Jul 2021 07:04:03 -0400 Subject: [ghc-steering-committee] =?utf-8?q?Proposal_=23302=3A_Multiway_la?= =?utf-8?q?mbda=3A_time=09to_vote?= In-Reply-To: References: <6653de3b-0d6e-43da-9218-6850284d7067@www.fastmail.com> Message-ID: <180b678d-6973-4d2a-9ace-1db60e7dfb6d@www.fastmail.com> On Thu, Jul 22, 2021, at 12:54, Simon Peyton Jones wrote: > Thanks Eric > > | adding syntax for multi-arg case is concerns around back compat. If we could > | go back in time and revise the original \case syntax to support multiple > | arguments, would we still end up with a single-arg construct and a multi-arg > | construct? I think probably not. > > Actually I don't agree. I think we might well have \case (for 1) and > \cases (for 0-n) because > * the cognitive overhead is vanishingly small (especially given the > singular/plural form > * the absence of parens in the very common case of \case is extremely > convenient > > I actively like the signal that \cases gives me, up front, "here comes > an nary lambda", rather than the very quiet commas of (2). Whereas I > know that \case is always unary. We don't have separate unary / n-ary constructs for function definitions or lambdas. Do you think we should make the distinction there too? I don't understand what makes \case so different. The paren issue is valid, but in my opinion option (2) solves it better with the comma separators. From trupill at gmail.com Fri Jul 23 11:16:12 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 23 Jul 2021 11:16:12 +0000 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> Message-ID: Re-reading the thread has made me aware of the distinction introduced by this proposal between “top-level” and “local modules”, which I do not fully grasp. I was under the impression that this was working more on the syntactic level (so if I write `module X where module Y where` this is similar to `module X.Y where`), and the specification was about sorting out how this works, but now I’m surprised about this new concept. Regards, Alejandro El 23 jul 2021 12:00:40, Simon Marlow escribió: > Just so I'm not completely silent: in the past I was generally in favour > but had some suggestions. It looks like the proposal has undergone a lot of > rewrites since I last reviewed it (or perhaps I just don't remember it all > that well), I've started to go through it again but this is a biggie! > > I think a deadline is a good idea. > > Cheers > Simon > > On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud > wrote: > >> Dear all, >> >> I know that this proposal is a bit long, but it also deserves your >> attention. >> >> I feel it's going to be easier to set a bit of time to review the >> proposal if I give a deadline. So let's say the following: I'll be on >> holiday starting two weeks from now (6th August), can I have everybody's >> opinion by then? >> >> --- >> >> Recapitulating the opinions so far >> >> - I'm personally pretty enthusiastic about the entire proposal >> - Tom voiced quite enthusiastic support for what Simon PJ calls (1), >> and (3) >> - Simon PJ wants (1), is not against (2), is mildly against (3) >> - Joachim suspends his judgement (which is fine, but hopefully not >> too many of us do this :-) ). >> >> >> On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones >> wrote: >> >>> To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3) >>> >>> 1. Import and export of qualified names. This seems like the Main >>> Point. >>> 2. Local import (in a let/where). This seems low pain but low gain. >>> 3. Local modules. This is the one I'm struggling with. >>> >>> There is more on the (tail end of the) PR >>> https://github.com/ghc-proposals/ghc-proposals/pull/283 >>> >>> >>> >>> I am open to being educated. >>> >>> >>> I would love to hear from other members of the committee. Tom’s >>> thumbs-up seemed to about (1), without saying anything about (2) and (3). >>> >>> >>> >>> One mechanism (if my categorisation is correct) could be to ask everyone >>> to vote (yes/no/maybe) on all of 1,2,3. >>> >>> >>> >>> Arnaud, you are our shepherd. Your sheep await your command. >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* ghc-steering-committee < >>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard >>> Eisenberg >>> *Sent:* 19 July 2021 21:18 >>> *To:* Spiwack, Arnaud >>> *Cc:* GHC Steering Committee >>> *Subject:* Re: [ghc-steering-committee] #283: Local modules (again), >>> recommendation: accept >>> >>> >>> >>> Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than >>> that), Arnaud is in support, but the rest of you have been quiet. >>> >>> >>> >>> Thanks! >>> >>> Richard >>> >>> >>> >>> On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud >>> wrote: >>> >>> >>> >>> Dear all, >>> >>> >>> >>> Let me raise this proposal again. Very few of us have opined, and while >>> I'd usually be happy to consider silence as assent, this is a rather large >>> proposal which may require a few more pairs of eyes. Please consider giving >>> this one a read and share your thoughts. If you can't do so right now, >>> please let me know when you will be able to, so that we can plan >>> accordingly. >>> >>> >>> >>> This is an important proposal, I'm keen on seeing its design finalised. >>> >>> >>> >>> /Arnaud >>> >>> >>> >>> On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg >>> wrote: >>> >>> >>> >>> >>> >>> On May 26, 2021, at 3:28 AM, Spiwack, Arnaud >>> wrote: >>> >>> >>> >>> I'm realising that I inverted additional options 1 and 3 in my reply. To >>> spell things out: I'm in favour of the namespace introduced for every >>> datatype and such; and weakly in favour of anonymous modules, for which I >>> prefer the `_` syntax than simply omitting the name. >>> >>> >>> >>> Oh, good. I was very confused here, but I decided not to push on it. I'm >>> similarly weakly in favor of (1), but I can't get myself to decide firmly >>> on whether to go with alternative (7). Going with (7) is a little more >>> consistent with other features, but it adds more symbols to the source text >>> that could otherwise be omitted. So I'm pretty ambivalent. >>> >>> >>> >>> Richard >>> >>> >>> >>> >>> >>> On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg >>> wrote: >>> >>> >>> >>> >>> >>> On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena >>> wrote: >>> >>> >>> >>> - I am not sure of the benefit of allowing (1), compared with the >>> possible surprise of users. >>> >>> - I do not fully understand (2). >>> >>> - I think (3) would be great, if we ensure that nothing changes if I >>> don’t use “qualified”, even if -XLocalModules is on. >>> >>> >>> >>> If in the language, I would use (1) -- anonymous local modules -- >>> regularly, when defining a function or class instance with a bunch of >>> "local" helper functions. Of course, if we can't omit the module name, I >>> will suffer no great harm. >>> >>> >>> >>> I cannot offer the guarantee you seek in (3), but I don't think you want >>> it. (If nothing changes, then the feature has no effect!) Here is a >>> scenario where (3) could cause trouble: >>> >>> >>> >>> import Data.Set as Set ( abcde ) >>> >>> >>> >>> data Set = Mk { abcdf :: Int } >>> >>> >>> >>> blah = Set.abcdf >>> >>> >>> >>> Previously, GHC would have suggested that you perhaps misspelled abcde. >>> Now, you'll get (presumably) a type error. >>> >>> >>> >>> Here's another case: >>> >>> >>> >>> import Data.Set as Set ( Set ) >>> >>> >>> >>> data Set = Mk >>> >>> >>> >>> x :: Set.Set >>> >>> >>> >>> Everything is happy today, but with -XLocalModules (and (3)), the type >>> of x is an ambiguous name. >>> >>> >>> >>> Any example that causes trouble, though, will have something in common: >>> an imported module name (possibly via an alias) that matches a locally >>> defined type name. I would imagine this pattern is rare in practice, and >>> that the benefit of (3) would outweigh the number of times that a problem >>> like this bites. >>> >>> >>> >>> I, too, could live without (2). >>> >>> >>> >>> Richard >>> >>> >>> >>> >>> >> _______________________________________________ >> 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 Jul 23 11:40:26 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 23 Jul 2021 13:40:26 +0200 Subject: [ghc-steering-committee] Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel In-Reply-To: References: <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io> <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de> Message-ID: I’ve been made aware that the “NoFallibleDo” proposal has been re-submitted to the Committee. My current recommendation is “reject”, as outlined in the following comment https://github.com/ghc-proposals/ghc-proposals/pull/319#issuecomment-885580010 (TL;DR, you’d often like to enable this for a particular “do” block, not for an entire file). Regards, Alejandro El 28 jul 2020 11:33:02, Alejandro Serrano Mena escribió: > Done. Once again, sorry for the confusion. > > Alejandro > > El mar., 28 jul. 2020 a las 11:30, Simon Peyton Jones (< > simonpj at microsoft.com>) escribió: > >> OK, so to summarise >> >> - We are waiting for the author >> - You are encouraging us to comment anyway >> >> >> Correct? Does the author know this? Why encourage only us? Maybe >> post on Github to clarify the status, and encourage everyone to contribute. >> >> >> >> S >> >> >> >> *From:* Alejandro Serrano Mena >> *Sent:* 28 July 2020 10:25 >> *To:* Simon Peyton Jones >> *Cc:* ghc-steering-committee at haskell.org >> *Subject:* Re: [ghc-steering-committee] Please review #319: NoFallibleDo >> proposal, Shepherd: Eric Seidel >> >> >> >> I mean the last status, push back to the author for revision. >> >> >> >> Alejandro >> >> >> >> El mar., 28 jul. 2020 a las 11:24, Simon Peyton Jones (< >> simonpj at microsoft.com>) escribió: >> >> So I’m still confused. “We went back to GIthub”… does that mean that we >> invited the author to revise and resubmit? I don’t know what else “back to >> github” means. >> >> >> >> If it’s in committee-decision status, then our process says should >> either accept, reject, or push back to the author for revision, in a timely >> way (guided by the shepherd) >> >> >> >> Simon >> >> >> >> *From:* Alejandro Serrano Mena >> *Sent:* 28 July 2020 10:22 >> *To:* Simon Peyton Jones >> *Cc:* ghc-steering-committee at haskell.org >> *Subject:* Re: [ghc-steering-committee] Please review #319: NoFallibleDo >> proposal, Shepherd: Eric Seidel >> >> >> >> Eric was initially in charge, but I took over his duties. He thought that >> a bit more discussion was needed, something I agree with, so we went back >> to GitHub. >> >> >> >> Sorry about the stale status, I feel that my back-and-forth was not very >> clear. >> >> >> >> Alejandro >> >> >> >> El mar., 28 jul. 2020 a las 11:17, Simon Peyton Jones (< >> simonpj at microsoft.com>) escribió: >> >> Alejandro, this one hasn’t been on my radar. >> >> >> >> Are you the shepherd? Have you made a recommendation? Is the proposal >> in its final form -- ie having absorbed all discussion etc? >> >> >> >> Simon >> >> >> >> *From:* ghc-steering-committee < >> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro >> Serrano Mena >> *Sent:* 28 July 2020 09:22 >> *To:* Joachim Breitner >> *Cc:* ghc-steering-committee >> *Subject:* Re: [ghc-steering-committee] Please review #319: NoFallibleDo >> proposal, Shepherd: Eric Seidel >> >> >> >> Dear Committee, >> >> I would like to kindly ask for your input in the NoFallibleDo proposal -> >> https://github.com/ghc-proposals/ghc-proposals/pull/319 >> >> >> This was submitted, then there was some discussion, but the conversation >> has stalled. >> >> >> >> Regards, >> >> Alejandro >> >> >> >> El jue., 14 may. 2020 a las 17:30, Alejandro Serrano Mena (< >> trupill at gmail.com>) escribió: >> >> @Eric congratulations! enjoy! :) >> >> >> >> @Joachim I can take care of this, I think the direction Eric was pushing >> this is a good one. >> >> >> >> El jue., 14 may. 2020 a las 12:16, Joachim Breitner (< >> mail at joachim-breitner.de>) escribió: >> >> Hi, >> >> Am Mittwoch, den 13.05.2020, 15:19 -0500 schrieb Eric Seidel: >> > My wife and I just checked into the hospital to have our second child >> >> Congrats, and all the best! >> >> > , so I’m going to be short on time for committee duties for a few >> > weeks. I think it would be best to reassign this proposal so we don’t >> > keep the authors waiting. >> >> Any volunteers? >> >> Cheers, >> Joachim >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Sat Jul 24 11:47:22 2021 From: marlowsd at gmail.com (Simon Marlow) Date: Sat, 24 Jul 2021 12:47:22 +0100 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> Message-ID: OK I finished reading it again. Overall I like it because it's just name resolution; this is entirely in keeping with Haskell as it stands, and limits the interaction with current and future language features. As a smooth extension of the language I think it works nicely. I rather like the idea of "data qualified" and "class qualified", perhaps because similar ideas work out quite well in other languages (e.g. C++). Just one thing concerns me. I don't think this is necessarily a blocker, but it makes me vaguely uneasy. Currently, if I see an identifier "M.x", I can search for "M" and be sure to find it in the import list somewhere, either as "import M" or "import X as M". I suspect a lot of people rely on this, and some coding styles strongly encourage the use of qualified names for this reason. Exporting qualified names and unfortunately breaks this property - any import can bring into scope qualified names. The property could be recovered by requiring the explicit import of qualified names (import Data.Set (module Set, ..) or something like that) but that doesn't seem very appealing either. Curious whether other people are worried about this and/or have any suggestions. Cheers Simon On Fri, 23 Jul 2021 at 11:00, Simon Marlow wrote: > Just so I'm not completely silent: in the past I was generally in favour > but had some suggestions. It looks like the proposal has undergone a lot of > rewrites since I last reviewed it (or perhaps I just don't remember it all > that well), I've started to go through it again but this is a biggie! > > I think a deadline is a good idea. > > Cheers > Simon > > On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud > wrote: > >> Dear all, >> >> I know that this proposal is a bit long, but it also deserves your >> attention. >> >> I feel it's going to be easier to set a bit of time to review the >> proposal if I give a deadline. So let's say the following: I'll be on >> holiday starting two weeks from now (6th August), can I have everybody's >> opinion by then? >> >> --- >> >> Recapitulating the opinions so far >> >> - I'm personally pretty enthusiastic about the entire proposal >> - Tom voiced quite enthusiastic support for what Simon PJ calls (1), >> and (3) >> - Simon PJ wants (1), is not against (2), is mildly against (3) >> - Joachim suspends his judgement (which is fine, but hopefully not >> too many of us do this :-) ). >> >> >> On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones >> wrote: >> >>> To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3) >>> >>> 1. Import and export of qualified names. This seems like the Main >>> Point. >>> 2. Local import (in a let/where). This seems low pain but low gain. >>> 3. Local modules. This is the one I'm struggling with. >>> >>> There is more on the (tail end of the) PR >>> https://github.com/ghc-proposals/ghc-proposals/pull/283 >>> >>> >>> >>> I am open to being educated. >>> >>> >>> I would love to hear from other members of the committee. Tom’s >>> thumbs-up seemed to about (1), without saying anything about (2) and (3). >>> >>> >>> >>> One mechanism (if my categorisation is correct) could be to ask everyone >>> to vote (yes/no/maybe) on all of 1,2,3. >>> >>> >>> >>> Arnaud, you are our shepherd. Your sheep await your command. >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* ghc-steering-committee < >>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard >>> Eisenberg >>> *Sent:* 19 July 2021 21:18 >>> *To:* Spiwack, Arnaud >>> *Cc:* GHC Steering Committee >>> *Subject:* Re: [ghc-steering-committee] #283: Local modules (again), >>> recommendation: accept >>> >>> >>> >>> Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than >>> that), Arnaud is in support, but the rest of you have been quiet. >>> >>> >>> >>> Thanks! >>> >>> Richard >>> >>> >>> >>> On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud >>> wrote: >>> >>> >>> >>> Dear all, >>> >>> >>> >>> Let me raise this proposal again. Very few of us have opined, and while >>> I'd usually be happy to consider silence as assent, this is a rather large >>> proposal which may require a few more pairs of eyes. Please consider giving >>> this one a read and share your thoughts. If you can't do so right now, >>> please let me know when you will be able to, so that we can plan >>> accordingly. >>> >>> >>> >>> This is an important proposal, I'm keen on seeing its design finalised. >>> >>> >>> >>> /Arnaud >>> >>> >>> >>> On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg >>> wrote: >>> >>> >>> >>> >>> >>> On May 26, 2021, at 3:28 AM, Spiwack, Arnaud >>> wrote: >>> >>> >>> >>> I'm realising that I inverted additional options 1 and 3 in my reply. To >>> spell things out: I'm in favour of the namespace introduced for every >>> datatype and such; and weakly in favour of anonymous modules, for which I >>> prefer the `_` syntax than simply omitting the name. >>> >>> >>> >>> Oh, good. I was very confused here, but I decided not to push on it. I'm >>> similarly weakly in favor of (1), but I can't get myself to decide firmly >>> on whether to go with alternative (7). Going with (7) is a little more >>> consistent with other features, but it adds more symbols to the source text >>> that could otherwise be omitted. So I'm pretty ambivalent. >>> >>> >>> >>> Richard >>> >>> >>> >>> >>> >>> On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg >>> wrote: >>> >>> >>> >>> >>> >>> On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena >>> wrote: >>> >>> >>> >>> - I am not sure of the benefit of allowing (1), compared with the >>> possible surprise of users. >>> >>> - I do not fully understand (2). >>> >>> - I think (3) would be great, if we ensure that nothing changes if I >>> don’t use “qualified”, even if -XLocalModules is on. >>> >>> >>> >>> If in the language, I would use (1) -- anonymous local modules -- >>> regularly, when defining a function or class instance with a bunch of >>> "local" helper functions. Of course, if we can't omit the module name, I >>> will suffer no great harm. >>> >>> >>> >>> I cannot offer the guarantee you seek in (3), but I don't think you want >>> it. (If nothing changes, then the feature has no effect!) Here is a >>> scenario where (3) could cause trouble: >>> >>> >>> >>> import Data.Set as Set ( abcde ) >>> >>> >>> >>> data Set = Mk { abcdf :: Int } >>> >>> >>> >>> blah = Set.abcdf >>> >>> >>> >>> Previously, GHC would have suggested that you perhaps misspelled abcde. >>> Now, you'll get (presumably) a type error. >>> >>> >>> >>> Here's another case: >>> >>> >>> >>> import Data.Set as Set ( Set ) >>> >>> >>> >>> data Set = Mk >>> >>> >>> >>> x :: Set.Set >>> >>> >>> >>> Everything is happy today, but with -XLocalModules (and (3)), the type >>> of x is an ambiguous name. >>> >>> >>> >>> Any example that causes trouble, though, will have something in common: >>> an imported module name (possibly via an alias) that matches a locally >>> defined type name. I would imagine this pattern is rare in practice, and >>> that the benefit of (3) would outweigh the number of times that a problem >>> like this bites. >>> >>> >>> >>> I, too, could live without (2). >>> >>> >>> >>> 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 rae at richarde.dev Mon Jul 26 16:55:21 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 26 Jul 2021 16:55:21 +0000 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> Message-ID: <010f017ae3be0e76-4c2537a2-7a30-4690-b3de-4e1e0eb0f471-000000@us-east-2.amazonses.com> Hi Alejandro, This distinction between top-level module and local module is pretty superficial. I've added a new bit to the proposal to explain this: > This proposal describes top-level modules as distinct from local modules, but this distinction has little import. Here is the full set of differences between these concepts: > > The module keyword for a top-level module is the first lexeme in a file; the module keyword for a local module must not be the first lexeme in a file. > A top-level module can have import statements; a local module can have only import module statements. > An import statement can name only a top-level module, not a local module. > That's it! If you like, you can think of a import X statement as a combination of import qualified X and import module X statement: the first loads the external compilation unit named X (in a file X.hs) and brings lots of X.blah entities into scope, and the second removes the X. qualification. > > Another way to think about this is that there is really no distinction between top-level modules and local modules, but there is a distinction between a compilation unit and a module. An import statement names a compilation unit, granting access to any modules it contains. Haskell separately has two restrictions: > > Every compilation unit must contain exactly one module (which may contain other modules); the compilation unit must have the same name as its one module. > import statements must go before all other statements (except, optionally, for a module header) in a compilation unit (in order to support finding dependencies while parsing only a prefix of a file). I hope this helps! Richard > On Jul 23, 2021, at 7:16 AM, Alejandro Serrano Mena wrote: > > Re-reading the thread has made me aware of the distinction introduced by this proposal between “top-level” and “local modules”, which I do not fully grasp. I was under the impression that this was working more on the syntactic level (so if I write `module X where module Y where` this is similar to `module X.Y where`), and the specification was about sorting out how this works, but now I’m surprised about this new concept. > > Regards, > Alejandro > > El 23 jul 2021 12:00:40, Simon Marlow > escribió: > Just so I'm not completely silent: in the past I was generally in favour but had some suggestions. It looks like the proposal has undergone a lot of rewrites since I last reviewed it (or perhaps I just don't remember it all that well), I've started to go through it again but this is a biggie! > > I think a deadline is a good idea. > > Cheers > Simon > > On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud > wrote: > Dear all, > > I know that this proposal is a bit long, but it also deserves your attention. > > I feel it's going to be easier to set a bit of time to review the proposal if I give a deadline. So let's say the following: I'll be on holiday starting two weeks from now (6th August), can I have everybody's opinion by then? > > --- > > Recapitulating the opinions so far > I'm personally pretty enthusiastic about the entire proposal > Tom voiced quite enthusiastic support for what Simon PJ calls (1), and (3) > Simon PJ wants (1), is not against (2), is mildly against (3) > Joachim suspends his judgement (which is fine, but hopefully not too many of us do this :-) ). > > On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones > wrote: > To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3) > > Import and export of qualified names. This seems like the Main Point. > Local import (in a let/where). This seems low pain but low gain. > Local modules. This is the one I'm struggling with. > There is more on the (tail end of the) PR https://github.com/ghc-proposals/ghc-proposals/pull/283 > > > I am open to being educated. > > > I would love to hear from other members of the committee. Tom’s thumbs-up seemed to about (1), without saying anything about (2) and (3). > > > > One mechanism (if my categorisation is correct) could be to ask everyone to vote (yes/no/maybe) on all of 1,2,3. > > > > Arnaud, you are our shepherd. Your sheep await your command. > > > > Simon > > > > From: ghc-steering-committee > On Behalf Of Richard Eisenberg > Sent: 19 July 2021 21:18 > To: Spiwack, Arnaud > > Cc: GHC Steering Committee > > Subject: Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept > > > > Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than that), Arnaud is in support, but the rest of you have been quiet. > > > > Thanks! > > Richard > > > > > On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud > wrote: > > > > Dear all, > > > > Let me raise this proposal again. Very few of us have opined, and while I'd usually be happy to consider silence as assent, this is a rather large proposal which may require a few more pairs of eyes. Please consider giving this one a read and share your thoughts. If you can't do so right now, please let me know when you will be able to, so that we can plan accordingly. > > > > This is an important proposal, I'm keen on seeing its design finalised. > > > > /Arnaud > > > > On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg > wrote: > > > > > > > On May 26, 2021, at 3:28 AM, Spiwack, Arnaud > wrote: > > > > I'm realising that I inverted additional options 1 and 3 in my reply. To spell things out: I'm in favour of the namespace introduced for every datatype and such; and weakly in favour of anonymous modules, for which I prefer the `_` syntax than simply omitting the name. > > > > Oh, good. I was very confused here, but I decided not to push on it. I'm similarly weakly in favor of (1), but I can't get myself to decide firmly on whether to go with alternative (7). Going with (7) is a little more consistent with other features, but it adds more symbols to the source text that could otherwise be omitted. So I'm pretty ambivalent. > > > > Richard > > > > > > > On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg > wrote: > > > > > > > On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena > wrote: > > > > - I am not sure of the benefit of allowing (1), compared with the possible surprise of users. > > - I do not fully understand (2). > > - I think (3) would be great, if we ensure that nothing changes if I don’t use “qualified”, even if -XLocalModules is on. > > > > If in the language, I would use (1) -- anonymous local modules -- regularly, when defining a function or class instance with a bunch of "local" helper functions. Of course, if we can't omit the module name, I will suffer no great harm. > > > > I cannot offer the guarantee you seek in (3), but I don't think you want it. (If nothing changes, then the feature has no effect!) Here is a scenario where (3) could cause trouble: > > > > import Data.Set as Set ( abcde ) > > > > data Set = Mk { abcdf :: Int } > > > > blah = Set.abcdf > > > > Previously, GHC would have suggested that you perhaps misspelled abcde. Now, you'll get (presumably) a type error. > > > > Here's another case: > > > > import Data.Set as Set ( Set ) > > > > data Set = Mk > > > > x :: Set.Set > > > > Everything is happy today, but with -XLocalModules (and (3)), the type of x is an ambiguous name. > > > > Any example that causes trouble, though, will have something in common: an imported module name (possibly via an alias) that matches a locally defined type name. I would imagine this pattern is rare in practice, and that the benefit of (3) would outweigh the number of times that a problem like this bites. > > > > I, too, could live without (2). > > > > Richard > > > > > > _______________________________________________ > 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 Jul 26 17:08:16 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 26 Jul 2021 17:08:16 +0000 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> Message-ID: <010f017ae3c9e2b2-5118dc4d-7d82-4b69-bbef-4d3c2e3b2e01-000000@us-east-2.amazonses.com> > On Jul 24, 2021, at 7:47 AM, Simon Marlow wrote: > > OK I finished reading it again. Overall I like it because it's just name resolution; this is entirely in keeping with Haskell as it stands, and limits the interaction with current and future language features. As a smooth extension of the language I think it works nicely. > > I rather like the idea of "data qualified" and "class qualified", perhaps because similar ideas work out quite well in other languages (e.g. C++). > > Just one thing concerns me. I don't think this is necessarily a blocker, but it makes me vaguely uneasy. > > Currently, if I see an identifier "M.x", I can search for "M" and be sure to find it in the import list somewhere, either as "import M" or "import X as M". I suspect a lot of people rely on this, and some coding styles strongly encourage the use of qualified names for this reason. Exporting qualified names and unfortunately breaks this property - any import can bring into scope qualified names. > > The property could be recovered by requiring the explicit import of qualified names (import Data.Set (module Set, ..) or something like that) but that doesn't seem very appealing either. Curious whether other people are worried about this and/or have any suggestions. This is true -- but it's simply a problem of unqualified imports. I can always have `import qualified Data.Set as S` and then use `S.Set`. The problem would be if `Data.Set` exports qualified names like `Set.fromList`. Now, if `Data.Set` is itself imported qualified, we have `S.Set.fromList`, which is unfortunate. One idea could be a new import item `import module M impspec` which behaves just like `module M impspec`, but without the use of `qualify` in its interpretation. In code: > interpretImpItem('import' 'module' modids impspec, export_env) > = interpretImpSpec(impspec, strip(modids, export_env)) > interpretImpItem('import' 'module' modids, export_env) > = strip(modids, export_env) Now, we could say > import qualified Data.Set ( import module Set ) as S which would bring e.g. `S.Set` and `S.fromList` into scope. This new `import module` import item would enable this idiom. (This is all possible with the proposal as stated, but not nearly as easily.) Would that help? Then, someone who cared about the property you want would be able to suggest a coding style that would maintain it. Richard > > Cheers > Simon > > > On Fri, 23 Jul 2021 at 11:00, Simon Marlow > wrote: > Just so I'm not completely silent: in the past I was generally in favour but had some suggestions. It looks like the proposal has undergone a lot of rewrites since I last reviewed it (or perhaps I just don't remember it all that well), I've started to go through it again but this is a biggie! > > I think a deadline is a good idea. > > Cheers > Simon > > On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud > wrote: > Dear all, > > I know that this proposal is a bit long, but it also deserves your attention. > > I feel it's going to be easier to set a bit of time to review the proposal if I give a deadline. So let's say the following: I'll be on holiday starting two weeks from now (6th August), can I have everybody's opinion by then? > > --- > > Recapitulating the opinions so far > I'm personally pretty enthusiastic about the entire proposal > Tom voiced quite enthusiastic support for what Simon PJ calls (1), and (3) > Simon PJ wants (1), is not against (2), is mildly against (3) > Joachim suspends his judgement (which is fine, but hopefully not too many of us do this :-) ). > > On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones > wrote: > To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3) > > Import and export of qualified names. This seems like the Main Point. > Local import (in a let/where). This seems low pain but low gain. > Local modules. This is the one I'm struggling with. > There is more on the (tail end of the) PR https://github.com/ghc-proposals/ghc-proposals/pull/283 > > > I am open to being educated. > > > I would love to hear from other members of the committee. Tom’s thumbs-up seemed to about (1), without saying anything about (2) and (3). > > > > One mechanism (if my categorisation is correct) could be to ask everyone to vote (yes/no/maybe) on all of 1,2,3. > > > > Arnaud, you are our shepherd. Your sheep await your command. > > > > Simon > > > > From: ghc-steering-committee > On Behalf Of Richard Eisenberg > Sent: 19 July 2021 21:18 > To: Spiwack, Arnaud > > Cc: GHC Steering Committee > > Subject: Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept > > > > Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than that), Arnaud is in support, but the rest of you have been quiet. > > > > Thanks! > > Richard > > > > > On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud > wrote: > > > > Dear all, > > > > Let me raise this proposal again. Very few of us have opined, and while I'd usually be happy to consider silence as assent, this is a rather large proposal which may require a few more pairs of eyes. Please consider giving this one a read and share your thoughts. If you can't do so right now, please let me know when you will be able to, so that we can plan accordingly. > > > > This is an important proposal, I'm keen on seeing its design finalised. > > > > /Arnaud > > > > On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg > wrote: > > > > > > > On May 26, 2021, at 3:28 AM, Spiwack, Arnaud > wrote: > > > > I'm realising that I inverted additional options 1 and 3 in my reply. To spell things out: I'm in favour of the namespace introduced for every datatype and such; and weakly in favour of anonymous modules, for which I prefer the `_` syntax than simply omitting the name. > > > > Oh, good. I was very confused here, but I decided not to push on it. I'm similarly weakly in favor of (1), but I can't get myself to decide firmly on whether to go with alternative (7). Going with (7) is a little more consistent with other features, but it adds more symbols to the source text that could otherwise be omitted. So I'm pretty ambivalent. > > > > Richard > > > > > > > On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg > wrote: > > > > > > > On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena > wrote: > > > > - I am not sure of the benefit of allowing (1), compared with the possible surprise of users. > > - I do not fully understand (2). > > - I think (3) would be great, if we ensure that nothing changes if I don’t use “qualified”, even if -XLocalModules is on. > > > > If in the language, I would use (1) -- anonymous local modules -- regularly, when defining a function or class instance with a bunch of "local" helper functions. Of course, if we can't omit the module name, I will suffer no great harm. > > > > I cannot offer the guarantee you seek in (3), but I don't think you want it. (If nothing changes, then the feature has no effect!) Here is a scenario where (3) could cause trouble: > > > > import Data.Set as Set ( abcde ) > > > > data Set = Mk { abcdf :: Int } > > > > blah = Set.abcdf > > > > Previously, GHC would have suggested that you perhaps misspelled abcde. Now, you'll get (presumably) a type error. > > > > Here's another case: > > > > import Data.Set as Set ( Set ) > > > > data Set = Mk > > > > x :: Set.Set > > > > Everything is happy today, but with -XLocalModules (and (3)), the type of x is an ambiguous name. > > > > Any example that causes trouble, though, will have something in common: an imported module name (possibly via an alias) that matches a locally defined type name. I would imagine this pattern is rare in practice, and that the benefit of (3) would outweigh the number of times that a problem like this bites. > > > > I, too, could live without (2). > > > > 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 lists at richarde.dev Mon Jul 26 17:45:09 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Mon, 26 Jul 2021 17:45:09 +0000 Subject: [ghc-steering-committee] #392: Clarify modifiers design principle (recommendation: acceptance) In-Reply-To: References: Message-ID: <010f017ae3eba679-439db1cd-5f72-450f-83d3-bd8a2890f5a5-000000@us-east-2.amazonses.com> I like the idea of allowing the semicolon, but I believe it should be optional, as I stated on GitHub: https://github.com/ghc-proposals/ghc-proposals/pull/390#issuecomment-878296938 I'm content to add the (optional) semicolon to #392. I don't know about the practical ramifications. Vlad may be best positioned to answer that. Richard > On Jul 23, 2021, at 3:53 AM, Alejandro Serrano Mena wrote: > > Dear all, > Richard has now updated the proposal, but only Arnaud has commented on it. I think this requires a few more eyes, since it will permeate the language once people start using linear types, and we are already thinking about introducing modifiers in other parts. > > In fact, I’ve realised that there’s a (grammar) conflict between this proposal and https://github.com/ghc-proposals/ghc-proposals/pull/390 (the fine-grained pragmas for type classes and instances). This proposal defines > > topdecl ::= {modifier} 'type' simpletype '=' type > | {modifier} 'data' [context '=>'] simpletype ['=' constrs] [deriving] > | {modifier} 'newtype' [context '=>'] simpletype = newconstr [deriving] > | {modifier} 'class' [scontext '=>'] tycls tyvar ['where' cdecls] > | {modifier} 'instance' [scontext '=>'] qtycls inst ['where' idecls] > > But #390 defines (note the ; at the end of the modifiers block): > > modifiers : {- empty -} | ('%' qtycon)* ';' > cl_decl : modifiers 'class' tycl_hdr fds where_cls > > I guess we should sort this out before accepting any of them. > > Alejandro > > El 28 jun 2021 21:26:45, Alejandro Serrano Mena > escribió: > Richard, will you take care of making those small changes to the proposal? That way we could mark this as accepted. > > Regards, > Alejandro > > El 28 jun 2021 9:01:28, Spiwack, Arnaud > escribió: > Yes, I believe that Richard and I are in agreement now. I don't think all the conclusions have been added to the proposal yet, though; but whatever's left, it's fairly minor. > > On Thu, Jun 24, 2021 at 1:29 PM Alejandro Serrano Mena > wrote: > Dear all, > This discussion has been dormant for some time, but it’s time to revive it! > > Richard, Arnaud, did you manage to reach conclusion about the modification to the proposal? > > Apart from that, is there any other concern about the proposal? As I said in my original message, this is a very small amendment to an already-existing proposal, so if we accepted the previous one I see no problem in this one. I’ll wait until Richard and Arnaud get back on the issue, and then assume that silence for a week is acceptance. > > Regards, > Alejandro > > El 11 jun 2021 14:55:41, Spiwack, Arnaud > escribió: > I think that my discussion with Richard has come to a conclusion (it should incur a small modification to the proposal). > > It is a very small (amendment to a) proposal, let's find a consensus on this one quickly. > > > On Wed, May 12, 2021 at 11:26 AM Spiwack, Arnaud > wrote: > I've commented on the PR [ https://github.com/ghc-proposals/ghc-proposals/pull/392#pullrequestreview-657652189 ] the changes on the syntax of lambda expressions are not motivated at all, I think at the very least there should be a discussion in the Alternatives section. > > But mostly, I'm worried about the implications/interactions that these changes have with linear types. > > (I'll be off for the rest of the week starting tonight, so I'll be back on this conversation on Monday, most likely) > > On Tue, May 11, 2021 at 10:10 AM Alejandro Serrano Mena > wrote: > Dear Committee, > This proposal seems a natural extension of #370, covering some additional cases (modifiers to classes and other declarations) that we’ve found along the way. My recommendation is acceptance. > > Regards, > Alejandro > > On 4 May 2021 at 09:41:56, Joachim Breitner > wrote: > Dear Committe, > > Clarify modifiers design principle > has been proposed by Richard > https://github.com/ghc-proposals/ghc-proposals/pull/392 > > This is an amendmend to #370, see the PR description for links to diffs > etc. > > I propose Alejandro as the shepherd, as he shepherded #370 before. > > 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 simonpj at microsoft.com Mon Jul 26 21:38:41 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Jul 2021 21:38:41 +0000 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: <010f017ae3be0e76-4c2537a2-7a30-4690-b3de-4e1e0eb0f471-000000@us-east-2.amazonses.com> References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> <010f017ae3be0e76-4c2537a2-7a30-4690-b3de-4e1e0eb0f471-000000@us-east-2.amazonses.com> Message-ID: I hope this helps! Alas it leaves me even more confused. Now there are three concepts in play * local module * top-level module * compilation unit I think that perhaps top-level module = compilation unit. But no, you say "there is really no distinction between top-level modules and local modules, but there is a distinction between a compilation unit and a module". So you seem to be saying "top-level module = local module". But then you say "An import statement can name only a top-level module, not a local module." suggesting that local modules and top level modules are not the same after all. I'm sorry, but I'm pretty baffled Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 26 July 2021 17:55 To: Alejandro Serrano Mena Cc: GHC Steering Committee Subject: Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept Hi Alejandro, This distinction between top-level module and local module is pretty superficial. I've added a new bit to the proposal to explain this: * This proposal describes top-level modules as distinct from local modules, but this distinction has little import. Here is the full set of differences between these concepts: 1. The module keyword for a top-level module is the first lexeme in a file; the module keyword for a local module must not be the first lexeme in a file. 2. A top-level module can have import statements; a local module can have only import module statements. 3. An import statement can name only a top-level module, not a local module. That's it! If you like, you can think of a import X statement as a combination of import qualified X and import module X statement: the first loads the external compilation unit named X (in a file X.hs) and brings lots of X.blah entities into scope, and the second removes the X. qualification. Another way to think about this is that there is really no distinction between top-level modules and local modules, but there is a distinction between a compilation unit and a module. An import statement names a compilation unit, granting access to any modules it contains. Haskell separately has two restrictions: 1. Every compilation unit must contain exactly one module (which may contain other modules); the compilation unit must have the same name as its one module. 2. import statements must go before all other statements (except, optionally, for a module header) in a compilation unit (in order to support finding dependencies while parsing only a prefix of a file). 1. I hope this helps! Richard On Jul 23, 2021, at 7:16 AM, Alejandro Serrano Mena > wrote: Re-reading the thread has made me aware of the distinction introduced by this proposal between "top-level" and "local modules", which I do not fully grasp. I was under the impression that this was working more on the syntactic level (so if I write `module X where module Y where` this is similar to `module X.Y where`), and the specification was about sorting out how this works, but now I'm surprised about this new concept. Regards, Alejandro El 23 jul 2021 12:00:40, Simon Marlow > escribió: Just so I'm not completely silent: in the past I was generally in favour but had some suggestions. It looks like the proposal has undergone a lot of rewrites since I last reviewed it (or perhaps I just don't remember it all that well), I've started to go through it again but this is a biggie! I think a deadline is a good idea. Cheers Simon On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud > wrote: Dear all, I know that this proposal is a bit long, but it also deserves your attention. I feel it's going to be easier to set a bit of time to review the proposal if I give a deadline. So let's say the following: I'll be on holiday starting two weeks from now (6th August), can I have everybody's opinion by then? --- Recapitulating the opinions so far * I'm personally pretty enthusiastic about the entire proposal * Tom voiced quite enthusiastic support for what Simon PJ calls (1), and (3) * Simon PJ wants (1), is not against (2), is mildly against (3) * Joachim suspends his judgement (which is fine, but hopefully not too many of us do this :-) ). On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones > wrote: To be clear, I'm ok with (1), luke-warm on (2), and mildly against (3) 1. Import and export of qualified names. This seems like the Main Point. 2. Local import (in a let/where). This seems low pain but low gain. 3. Local modules. This is the one I'm struggling with. There is more on the (tail end of the) PR https://github.com/ghc-proposals/ghc-proposals/pull/283 I am open to being educated. I would love to hear from other members of the committee. Tom's thumbs-up seemed to about (1), without saying anything about (2) and (3). One mechanism (if my categorisation is correct) could be to ask everyone to vote (yes/no/maybe) on all of 1,2,3. Arnaud, you are our shepherd. Your sheep await your command. Simon From: ghc-steering-committee > On Behalf Of Richard Eisenberg Sent: 19 July 2021 21:18 To: Spiwack, Arnaud > Cc: GHC Steering Committee > Subject: Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than that), Arnaud is in support, but the rest of you have been quiet. Thanks! Richard On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud > wrote: Dear all, Let me raise this proposal again. Very few of us have opined, and while I'd usually be happy to consider silence as assent, this is a rather large proposal which may require a few more pairs of eyes. Please consider giving this one a read and share your thoughts. If you can't do so right now, please let me know when you will be able to, so that we can plan accordingly. This is an important proposal, I'm keen on seeing its design finalised. /Arnaud On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg > wrote: On May 26, 2021, at 3:28 AM, Spiwack, Arnaud > wrote: I'm realising that I inverted additional options 1 and 3 in my reply. To spell things out: I'm in favour of the namespace introduced for every datatype and such; and weakly in favour of anonymous modules, for which I prefer the `_` syntax than simply omitting the name. Oh, good. I was very confused here, but I decided not to push on it. I'm similarly weakly in favor of (1), but I can't get myself to decide firmly on whether to go with alternative (7). Going with (7) is a little more consistent with other features, but it adds more symbols to the source text that could otherwise be omitted. So I'm pretty ambivalent. Richard On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg > wrote: On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena > wrote: - I am not sure of the benefit of allowing (1), compared with the possible surprise of users. - I do not fully understand (2). - I think (3) would be great, if we ensure that nothing changes if I don't use "qualified", even if -XLocalModules is on. If in the language, I would use (1) -- anonymous local modules -- regularly, when defining a function or class instance with a bunch of "local" helper functions. Of course, if we can't omit the module name, I will suffer no great harm. I cannot offer the guarantee you seek in (3), but I don't think you want it. (If nothing changes, then the feature has no effect!) Here is a scenario where (3) could cause trouble: import Data.Set as Set ( abcde ) data Set = Mk { abcdf :: Int } blah = Set.abcdf Previously, GHC would have suggested that you perhaps misspelled abcde. Now, you'll get (presumably) a type error. Here's another case: import Data.Set as Set ( Set ) data Set = Mk x :: Set.Set Everything is happy today, but with -XLocalModules (and (3)), the type of x is an ambiguous name. Any example that causes trouble, though, will have something in common: an imported module name (possibly via an alias) that matches a locally defined type name. I would imagine this pattern is rare in practice, and that the benefit of (3) would outweigh the number of times that a problem like this bites. I, too, could live without (2). Richard _______________________________________________ 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 Mon Jul 26 21:57:21 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Jul 2021 21:57:21 +0000 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: <010f017ae3c9e2b2-5118dc4d-7d82-4b69-bbef-4d3c2e3b2e01-000000@us-east-2.amazonses.com> References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> <010f017ae3c9e2b2-5118dc4d-7d82-4b69-bbef-4d3c2e3b2e01-000000@us-east-2.amazonses.com> Message-ID: One idea could be a new import item `import module M impspec` which behaves just like `module M impspec`, but without the use of `qualify` in its interpretation. In code: Not so great in cases where import Graphics imports Button.open and Widget.open If you qualify, thus import Graphics as G then you want G.Button.open and G.Widget.open. You really don't want to strip off the carefully added Button and Widget qualifiers. To be more explicit, I guess you could say import Graphics( Buttton.*, Widget.* ) or perhaps more Haskell-y import Graphics( module Button, module Widget ) and indeed I believe the proposal supports precisely that. Currently, if I see an identifier "M.x", I can search for "M" and be sure to find it in the import list somewhere, either as "import M" or "import X as M". Yes, that's convenient. But it would also be convenient if, which I see an identifier "x", I could always see where it is imported from. But sadly I can't - and I often find myself guessing. So it's not a new shortcoming of this proposal. One could imagine a new flag, ExplicitBinders, whose principle is that it is easy to determine from every occurrence which import(s) brings it into scope. For an unqualified "x" that would mean you'd have to * either import "x" explicitly, import M(x) * or change the occurrence to a qualified M.x That might be a good software engineering practice to follow. Then you could extend the same treatment to this new proposal. Simon From: Richard Eisenberg Sent: 26 July 2021 18:08 To: Simon Marlow Cc: Spiwack, Arnaud ; Simon Peyton Jones ; GHC Steering Committee Subject: Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept On Jul 24, 2021, at 7:47 AM, Simon Marlow > wrote: OK I finished reading it again. Overall I like it because it's just name resolution; this is entirely in keeping with Haskell as it stands, and limits the interaction with current and future language features. As a smooth extension of the language I think it works nicely. I rather like the idea of "data qualified" and "class qualified", perhaps because similar ideas work out quite well in other languages (e.g. C++). Just one thing concerns me. I don't think this is necessarily a blocker, but it makes me vaguely uneasy. Currently, if I see an identifier "M.x", I can search for "M" and be sure to find it in the import list somewhere, either as "import M" or "import X as M". I suspect a lot of people rely on this, and some coding styles strongly encourage the use of qualified names for this reason. Exporting qualified names and unfortunately breaks this property - any import can bring into scope qualified names. The property could be recovered by requiring the explicit import of qualified names (import Data.Set (module Set, ..) or something like that) but that doesn't seem very appealing either. Curious whether other people are worried about this and/or have any suggestions. This is true -- but it's simply a problem of unqualified imports. I can always have `import qualified Data.Set as S` and then use `S.Set`. The problem would be if `Data.Set` exports qualified names like `Set.fromList`. Now, if `Data.Set` is itself imported qualified, we have `S.Set.fromList`, which is unfortunate. One idea could be a new import item `import module M impspec` which behaves just like `module M impspec`, but without the use of `qualify` in its interpretation. In code: interpretImpItem('import' 'module' modids impspec, export_env) = interpretImpSpec(impspec, strip(modids, export_env)) interpretImpItem('import' 'module' modids, export_env) = strip(modids, export_env) Now, we could say > import qualified Data.Set ( import module Set ) as S which would bring e.g. `S.Set` and `S.fromList` into scope. This new `import module` import item would enable this idiom. (This is all possible with the proposal as stated, but not nearly as easily.) Would that help? Then, someone who cared about the property you want would be able to suggest a coding style that would maintain it. Richard Cheers Simon On Fri, 23 Jul 2021 at 11:00, Simon Marlow > wrote: Just so I'm not completely silent: in the past I was generally in favour but had some suggestions. It looks like the proposal has undergone a lot of rewrites since I last reviewed it (or perhaps I just don't remember it all that well), I've started to go through it again but this is a biggie! I think a deadline is a good idea. Cheers Simon On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud > wrote: Dear all, I know that this proposal is a bit long, but it also deserves your attention. I feel it's going to be easier to set a bit of time to review the proposal if I give a deadline. So let's say the following: I'll be on holiday starting two weeks from now (6th August), can I have everybody's opinion by then? --- Recapitulating the opinions so far * I'm personally pretty enthusiastic about the entire proposal * Tom voiced quite enthusiastic support for what Simon PJ calls (1), and (3) * Simon PJ wants (1), is not against (2), is mildly against (3) * Joachim suspends his judgement (which is fine, but hopefully not too many of us do this :-) ). On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones > wrote: To be clear, I'm ok with (1), luke-warm on (2), and mildly against (3) 1. Import and export of qualified names. This seems like the Main Point. 2. Local import (in a let/where). This seems low pain but low gain. 3. Local modules. This is the one I'm struggling with. There is more on the (tail end of the) PR https://github.com/ghc-proposals/ghc-proposals/pull/283 I am open to being educated. I would love to hear from other members of the committee. Tom's thumbs-up seemed to about (1), without saying anything about (2) and (3). One mechanism (if my categorisation is correct) could be to ask everyone to vote (yes/no/maybe) on all of 1,2,3. Arnaud, you are our shepherd. Your sheep await your command. Simon From: ghc-steering-committee > On Behalf Of Richard Eisenberg Sent: 19 July 2021 21:18 To: Spiwack, Arnaud > Cc: GHC Steering Committee > Subject: Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than that), Arnaud is in support, but the rest of you have been quiet. Thanks! Richard On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud > wrote: Dear all, Let me raise this proposal again. Very few of us have opined, and while I'd usually be happy to consider silence as assent, this is a rather large proposal which may require a few more pairs of eyes. Please consider giving this one a read and share your thoughts. If you can't do so right now, please let me know when you will be able to, so that we can plan accordingly. This is an important proposal, I'm keen on seeing its design finalised. /Arnaud On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg > wrote: On May 26, 2021, at 3:28 AM, Spiwack, Arnaud > wrote: I'm realising that I inverted additional options 1 and 3 in my reply. To spell things out: I'm in favour of the namespace introduced for every datatype and such; and weakly in favour of anonymous modules, for which I prefer the `_` syntax than simply omitting the name. Oh, good. I was very confused here, but I decided not to push on it. I'm similarly weakly in favor of (1), but I can't get myself to decide firmly on whether to go with alternative (7). Going with (7) is a little more consistent with other features, but it adds more symbols to the source text that could otherwise be omitted. So I'm pretty ambivalent. Richard On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg > wrote: On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena > wrote: - I am not sure of the benefit of allowing (1), compared with the possible surprise of users. - I do not fully understand (2). - I think (3) would be great, if we ensure that nothing changes if I don't use "qualified", even if -XLocalModules is on. If in the language, I would use (1) -- anonymous local modules -- regularly, when defining a function or class instance with a bunch of "local" helper functions. Of course, if we can't omit the module name, I will suffer no great harm. I cannot offer the guarantee you seek in (3), but I don't think you want it. (If nothing changes, then the feature has no effect!) Here is a scenario where (3) could cause trouble: import Data.Set as Set ( abcde ) data Set = Mk { abcdf :: Int } blah = Set.abcdf Previously, GHC would have suggested that you perhaps misspelled abcde. Now, you'll get (presumably) a type error. Here's another case: import Data.Set as Set ( Set ) data Set = Mk x :: Set.Set Everything is happy today, but with -XLocalModules (and (3)), the type of x is an ambiguous name. Any example that causes trouble, though, will have something in common: an imported module name (possibly via an alias) that matches a locally defined type name. I would imagine this pattern is rare in practice, and that the benefit of (3) would outweigh the number of times that a problem like this bites. I, too, could live without (2). 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 rae at richarde.dev Tue Jul 27 03:08:53 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 27 Jul 2021 03:08:53 +0000 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> <010f017ae3be0e76-4c2537a2-7a30-4690-b3de-4e1e0eb0f471-000000@us-east-2.amazonses.com> Message-ID: <010f017ae5efc299-c51b5c72-41fb-4984-be82-0f0cc68fb2b9-000000@us-east-2.amazonses.com> > On Jul 26, 2021, at 5:38 PM, Simon Peyton Jones wrote: > > I hope this helps! > > Alas it leaves me even more confused. Somehow I knew you'd say that. > > Now there are three concepts in play > local module > top-level module > compilation unit > I think that perhaps top-level module = compilation unit. A compilation unit is a chunk of Haskell code which is considered all at once, producing one .o file. Currently, compilation units are coincident both with files on disk and modules. This proposal allows us to have modules smaller than a compilation unit, but Haskell has a restriction that a compilation unit (= file on disk) contains precisely one module (which may contain others), as well as a restriction about where `import` statements appear. This little part, starting with "another way to think about this" is meant to provide intuition, if you're already familiar with compilation units. It is separate from the points above -- and is just meant to guide intuition. (For example, I have not properly defined "compilation unit".) If it does not connect with you, skip. Instead, look at the three differences between top-level modules and local modules a little further up, and see that this distinction is very superficial. Richard > But no, you say “there is really no distinction between top-level modules and local modules, but there is a distinction between a compilation unit and a module”. > So you seem to be saying “top-level module = local module”. But then you say “An import statement can name only a top-level module, not a local module.” suggesting that local modules and top level modules are not the same after all. > I’m sorry, but I’m pretty baffled > Simon > > > From: ghc-steering-committee On Behalf Of Richard Eisenberg > Sent: 26 July 2021 17:55 > To: Alejandro Serrano Mena > Cc: GHC Steering Committee > Subject: Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept > > Hi Alejandro, > > This distinction between top-level module and local module is pretty superficial. I've added a new bit to the proposal to explain this: > > · This proposal describes top-level modules as distinct from local modules, but this distinction has little import. Here is the full set of differences between these concepts: > The module keyword for a top-level module is the first lexeme in a file; the module keyword for a local module must not be the first lexeme in a file. > A top-level module can have import statements; a local module can have only import module statements. > An import statement can name only a top-level module, not a local module. > That's it! If you like, you can think of a import X statement as a combination of import qualified X and import module X statement: the first loads the external compilation unit named X (in a file X.hs) and brings lots of X.blahentities into scope, and the second removes the X. qualification. > Another way to think about this is that there is really no distinction between top-level modules and local modules, but there is a distinction between a compilation unit and a module. An import statement names a compilation unit, granting access to any modules it contains. Haskell separately has two restrictions: > Every compilation unit must contain exactly one module (which may contain other modules); the compilation unit must have the same name as its one module. > import statements must go before all other statements (except, optionally, for a module header) in a compilation unit (in order to support finding dependencies while parsing only a prefix of a file). > I hope this helps! > Richard > > > On Jul 23, 2021, at 7:16 AM, Alejandro Serrano Mena > wrote: > > Re-reading the thread has made me aware of the distinction introduced by this proposal between “top-level” and “local modules”, which I do not fully grasp. I was under the impression that this was working more on the syntactic level (so if I write `module X where module Y where` this is similar to `module X.Y where`), and the specification was about sorting out how this works, but now I’m surprised about this new concept. > > Regards, > Alejandro > > El 23 jul 2021 12:00:40, Simon Marlow > escribió: > Just so I'm not completely silent: in the past I was generally in favour but had some suggestions. It looks like the proposal has undergone a lot of rewrites since I last reviewed it (or perhaps I just don't remember it all that well), I've started to go through it again but this is a biggie! > > I think a deadline is a good idea. > > Cheers > Simon > > On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud > wrote: > Dear all, > > I know that this proposal is a bit long, but it also deserves your attention. > > I feel it's going to be easier to set a bit of time to review the proposal if I give a deadline. So let's say the following: I'll be on holiday starting two weeks from now (6th August), can I have everybody's opinion by then? > > --- > > Recapitulating the opinions so far > I'm personally pretty enthusiastic about the entire proposal > Tom voiced quite enthusiastic support for what Simon PJ calls (1), and (3) > Simon PJ wants (1), is not against (2), is mildly against (3) > Joachim suspends his judgement (which is fine, but hopefully not too many of us do this :-) ). > > On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones > wrote: > To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3) > Import and export of qualified names. This seems like the Main Point. > Local import (in a let/where). This seems low pain but low gain. > Local modules. This is the one I'm struggling with. > There is more on the (tail end of the) PR https://github.com/ghc-proposals/ghc-proposals/pull/283 > > I am open to being educated. > > I would love to hear from other members of the committee. Tom’s thumbs-up seemed to about (1), without saying anything about (2) and (3). > > One mechanism (if my categorisation is correct) could be to ask everyone to vote (yes/no/maybe) on all of 1,2,3. > > Arnaud, you are our shepherd. Your sheep await your command. > > Simon > > From: ghc-steering-committee > On Behalf Of Richard Eisenberg > Sent: 19 July 2021 21:18 > To: Spiwack, Arnaud > > Cc: GHC Steering Committee > > Subject: Re: [ghc-steering-committee] #283: Local modules (again), recommendation: accept > > Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler than that), Arnaud is in support, but the rest of you have been quiet. > > Thanks! > Richard > > > On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud > wrote: > > Dear all, > > Let me raise this proposal again. Very few of us have opined, and while I'd usually be happy to consider silence as assent, this is a rather large proposal which may require a few more pairs of eyes. Please consider giving this one a read and share your thoughts. If you can't do so right now, please let me know when you will be able to, so that we can plan accordingly. > > This is an important proposal, I'm keen on seeing its design finalised. > > /Arnaud > > On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg > wrote: > > > > On May 26, 2021, at 3:28 AM, Spiwack, Arnaud > wrote: > > I'm realising that I inverted additional options 1 and 3 in my reply. To spell things out: I'm in favour of the namespace introduced for every datatype and such; and weakly in favour of anonymous modules, for which I prefer the `_` syntax than simply omitting the name. > > Oh, good. I was very confused here, but I decided not to push on it. I'm similarly weakly in favor of (1), but I can't get myself to decide firmly on whether to go with alternative (7). Going with (7) is a little more consistent with other features, but it adds more symbols to the source text that could otherwise be omitted. So I'm pretty ambivalent. > > Richard > > > > On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg > wrote: > > > > On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena > wrote: > > - I am not sure of the benefit of allowing (1), compared with the possible surprise of users. > - I do not fully understand (2). > - I think (3) would be great, if we ensure that nothing changes if I don’t use “qualified”, even if -XLocalModules is on. > > If in the language, I would use (1) -- anonymous local modules -- regularly, when defining a function or class instance with a bunch of "local" helper functions. Of course, if we can't omit the module name, I will suffer no great harm. > > I cannot offer the guarantee you seek in (3), but I don't think you want it. (If nothing changes, then the feature has no effect!) Here is a scenario where (3) could cause trouble: > > import Data.Set as Set ( abcde ) > > data Set = Mk { abcdf :: Int } > > blah = Set.abcdf > > Previously, GHC would have suggested that you perhaps misspelled abcde. Now, you'll get (presumably) a type error. > > Here's another case: > > import Data.Set as Set ( Set ) > > data Set = Mk > > x :: Set.Set > > Everything is happy today, but with -XLocalModules (and (3)), the type of x is an ambiguous name. > > Any example that causes trouble, though, will have something in common: an imported module name (possibly via an alias) that matches a locally defined type name. I would imagine this pattern is rare in practice, and that the benefit of (3) would outweigh the number of times that a problem like this bites. > > I, too, could live without (2). > > Richard > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Jul 27 16:01:43 2021 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 27 Jul 2021 17:01:43 +0100 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: <010f017ae3c9e2b2-5118dc4d-7d82-4b69-bbef-4d3c2e3b2e01-000000@us-east-2.amazonses.com> References: <010f0179a585c6e0-378b7052-e39b-43d5-a72b-884ddef10f60-000000@us-east-2.amazonses.com> <010f0179a8ac2bf6-879f696f-a2fa-4772-bc53-49ff9b52078e-000000@us-east-2.amazonses.com> <010f017ac06b1298-2271f739-5ec0-4857-ae7f-95c4122736cd-000000@us-east-2.amazonses.com> <010f017ae3c9e2b2-5118dc4d-7d82-4b69-bbef-4d3c2e3b2e01-000000@us-east-2.amazonses.com> Message-ID: On Mon, 26 Jul 2021 at 18:08, Richard Eisenberg wrote: > > One idea could be a new import item `import module M impspec` which > behaves just like `module M impspec`, but without the use of `qualify` in > its interpretation. In code: > > interpretImpItem('import' 'module' modids impspec, export_env) > = interpretImpSpec(impspec, strip(modids, export_env)) > interpretImpItem('import' 'module' modids, export_env) > = strip(modids, export_env) > > > Now, we could say > > > import qualified Data.Set ( import module Set ) as S > > which would bring e.g. `S.Set` and `S.fromList` into scope. > > This new `import module` import item would enable this idiom. (This is all > possible with the proposal as stated, but not nearly as easily.) Would that > help? Then, someone who cared about the property you want would be able to > suggest a coding style that would maintain it. > As you say, you can do this using the proposal as is: module qualified S (module Set) where import Data.Set so I don't think it's worth adding anything new, given that this is already quite brief. (if perhaps a little obscure, but you could imagine getting used to it) But while thinking about this I realised I'm more concerned that we would have two kinds of qualification that behave in quite different ways, yet look identical. One is top-level modules, which you can bring into scoe and rename with import declarations, and the other is qualified exports which are controlled with export and import specifiers. When I refer to an identifier like A.B.C.x, zero or more of the modids come from the import declaration. This is powerful, yes, but also potentially a source of great confusion. I find it hard to predict exactly how this will work out in practice. Cheers Simon > > Richard > > > > Cheers > Simon > > > On Fri, 23 Jul 2021 at 11:00, Simon Marlow wrote: > >> Just so I'm not completely silent: in the past I was generally in favour >> but had some suggestions. It looks like the proposal has undergone a lot of >> rewrites since I last reviewed it (or perhaps I just don't remember it all >> that well), I've started to go through it again but this is a biggie! >> >> I think a deadline is a good idea. >> >> Cheers >> Simon >> >> On Fri, 23 Jul 2021 at 07:23, Spiwack, Arnaud >> wrote: >> >>> Dear all, >>> >>> I know that this proposal is a bit long, but it also deserves your >>> attention. >>> >>> I feel it's going to be easier to set a bit of time to review the >>> proposal if I give a deadline. So let's say the following: I'll be on >>> holiday starting two weeks from now (6th August), can I have everybody's >>> opinion by then? >>> >>> --- >>> >>> Recapitulating the opinions so far >>> >>> - I'm personally pretty enthusiastic about the entire proposal >>> - Tom voiced quite enthusiastic support for what Simon PJ calls (1), >>> and (3) >>> - Simon PJ wants (1), is not against (2), is mildly against (3) >>> - Joachim suspends his judgement (which is fine, but hopefully not >>> too many of us do this :-) ). >>> >>> >>> On Wed, Jul 21, 2021 at 2:30 PM Simon Peyton Jones < >>> simonpj at microsoft.com> wrote: >>> >>>> To be clear, I’m ok with (1), luke-warm on (2), and mildly against (3) >>>> >>>> 1. Import and export of qualified names. This seems like the Main >>>> Point. >>>> 2. Local import (in a let/where). This seems low pain but low gain. >>>> 3. Local modules. This is the one I'm struggling with. >>>> >>>> There is more on the (tail end of the) PR >>>> https://github.com/ghc-proposals/ghc-proposals/pull/283 >>>> >>>> >>>> >>>> I am open to being educated. >>>> >>>> >>>> I would love to hear from other members of the committee. Tom’s >>>> thumbs-up seemed to about (1), without saying anything about (2) and (3). >>>> >>>> >>>> >>>> One mechanism (if my categorisation is correct) could be to ask >>>> everyone to vote (yes/no/maybe) on all of 1,2,3. >>>> >>>> >>>> >>>> Arnaud, you are our shepherd. Your sheep await your command. >>>> >>>> >>>> >>>> Simon >>>> >>>> >>>> >>>> *From:* ghc-steering-committee < >>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard >>>> Eisenberg >>>> *Sent:* 19 July 2021 21:18 >>>> *To:* Spiwack, Arnaud >>>> *Cc:* GHC Steering Committee >>>> *Subject:* Re: [ghc-steering-committee] #283: Local modules (again), >>>> recommendation: accept >>>> >>>> >>>> >>>> Any thoughts on this? Simon PJ seems lukewarm (or maybe even cooler >>>> than that), Arnaud is in support, but the rest of you have been quiet. >>>> >>>> >>>> >>>> Thanks! >>>> >>>> Richard >>>> >>>> >>>> >>>> On Jun 11, 2021, at 3:05 AM, Spiwack, Arnaud >>>> wrote: >>>> >>>> >>>> >>>> Dear all, >>>> >>>> >>>> >>>> Let me raise this proposal again. Very few of us have opined, and while >>>> I'd usually be happy to consider silence as assent, this is a rather large >>>> proposal which may require a few more pairs of eyes. Please consider giving >>>> this one a read and share your thoughts. If you can't do so right now, >>>> please let me know when you will be able to, so that we can plan >>>> accordingly. >>>> >>>> >>>> >>>> This is an important proposal, I'm keen on seeing its design finalised. >>>> >>>> >>>> >>>> /Arnaud >>>> >>>> >>>> >>>> On Wed, May 26, 2021 at 2:35 PM Richard Eisenberg >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> On May 26, 2021, at 3:28 AM, Spiwack, Arnaud >>>> wrote: >>>> >>>> >>>> >>>> I'm realising that I inverted additional options 1 and 3 in my reply. >>>> To spell things out: I'm in favour of the namespace introduced for every >>>> datatype and such; and weakly in favour of anonymous modules, for which I >>>> prefer the `_` syntax than simply omitting the name. >>>> >>>> >>>> >>>> Oh, good. I was very confused here, but I decided not to push on it. >>>> I'm similarly weakly in favor of (1), but I can't get myself to decide >>>> firmly on whether to go with alternative (7). Going with (7) is a little >>>> more consistent with other features, but it adds more symbols to the source >>>> text that could otherwise be omitted. So I'm pretty ambivalent. >>>> >>>> >>>> >>>> Richard >>>> >>>> >>>> >>>> >>>> >>>> On Tue, May 25, 2021 at 11:54 PM Richard Eisenberg >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> On May 25, 2021, at 3:09 PM, Alejandro Serrano Mena >>>> wrote: >>>> >>>> >>>> >>>> - I am not sure of the benefit of allowing (1), compared with the >>>> possible surprise of users. >>>> >>>> - I do not fully understand (2). >>>> >>>> - I think (3) would be great, if we ensure that nothing changes if I >>>> don’t use “qualified”, even if -XLocalModules is on. >>>> >>>> >>>> >>>> If in the language, I would use (1) -- anonymous local modules -- >>>> regularly, when defining a function or class instance with a bunch of >>>> "local" helper functions. Of course, if we can't omit the module name, I >>>> will suffer no great harm. >>>> >>>> >>>> >>>> I cannot offer the guarantee you seek in (3), but I don't think you >>>> want it. (If nothing changes, then the feature has no effect!) Here is a >>>> scenario where (3) could cause trouble: >>>> >>>> >>>> >>>> import Data.Set as Set ( abcde ) >>>> >>>> >>>> >>>> data Set = Mk { abcdf :: Int } >>>> >>>> >>>> >>>> blah = Set.abcdf >>>> >>>> >>>> >>>> Previously, GHC would have suggested that you perhaps misspelled abcde. >>>> Now, you'll get (presumably) a type error. >>>> >>>> >>>> >>>> Here's another case: >>>> >>>> >>>> >>>> import Data.Set as Set ( Set ) >>>> >>>> >>>> >>>> data Set = Mk >>>> >>>> >>>> >>>> x :: Set.Set >>>> >>>> >>>> >>>> Everything is happy today, but with -XLocalModules (and (3)), the type >>>> of x is an ambiguous name. >>>> >>>> >>>> >>>> Any example that causes trouble, though, will have something in common: >>>> an imported module name (possibly via an alias) that matches a locally >>>> defined type name. I would imagine this pattern is rare in practice, and >>>> that the benefit of (3) would outweigh the number of times that a problem >>>> like this bites. >>>> >>>> >>>> >>>> I, too, could live without (2). >>>> >>>> >>>> >>>> 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 Tue Jul 27 21:40:20 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 27 Jul 2021 21:40:20 +0000 Subject: [ghc-steering-committee] #302 \cases Message-ID: Dear steering committee, See below - it seems that (1) is the winner. I have recorded the results on our document here. I'll post on the GitHub. Thanks for participating in this. I think this ranked-preference voting works well when it comes down to a balance of taste on syntax, so that complete unanimity is unreasonable expectation. Simon From: Joachim Breitner Sent: 26 July 2021 21:19 To: Simon Peyton Jones Subject: Re: Running the voting algorithm I'll do it by hand: Votes: 1 > X > 2 = 4 2 > 4 > X > 1 1 > 4 > 2 > X 1 > X > 2 = 4 2 > 1 > X > 4 X > 1 > 2 = 4 1 > X > 2 = 4 1 > 2 > X > 4 1 > X > 2 = 4 2 > X > 1 > 4 Let's see if 1 is the winner: 1 beats 2 by 7 vs. 3 votes 1 beats 4 by 9 vs. 1 votes 1 beats X by 7 vs. 3 votes The winner is 1. (This tally was created on the phone in a tent on a mountain above a Norwegian fjord.) 26.07.2021 13:31:36 Simon Peyton Jones >: Joachim We have votes for \case, here https://docs.google.com/document/d/1NDXk5kKcLtkqhkSNESAC9jVrBn3yqS_Qe1vacAIKnDs/edit?usp=sharing Could you possibly run the voting algorithm - or tell me how to? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Jul 29 09:10:40 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 29 Jul 2021 09:10:40 +0000 Subject: [ghc-steering-committee] \cases Message-ID: Folks I've had a final thought about \cases. Looking at it now, I wonder if we can simply expand what LambdaCase allows, rather than having yet another extension. That is, LambdaCase now accepts \cases as well as \case. If we'd designed it from scratch we certainly would not have had two different extensions. The only downside I can see is a loss of back-compat in this program {-# LANGUAGE LambdaCase #-} module Foo where f = \cases -> cases + 1 -- Adds 1 g = \case { True -> False, False -> True } If we extend what LambdaCase does, the definition of f will change its meaning. But this is so bizarre that I'm disinclined to waste time on it. My suggestion: expand what LambdaCase does. If not, the new extension should be LambdaCases. Can you reply on the GitHub? https://github.com/ghc-proposals/ghc-proposals/pull/302 Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Thu Jul 29 14:30:23 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 29 Jul 2021 16:30:23 +0200 Subject: [ghc-steering-committee] \cases In-Reply-To: References: Message-ID: I think writing an actual comment on Github will be quite noisy. I left you a thumbs up in the “reaction” area instead. On Thu, Jul 29, 2021 at 11:11 AM Simon Peyton Jones via ghc-steering-committee wrote: > Folks > > I’ve had a final thought about \cases. > > Looking at it now, I wonder if we can simply expand what LambdaCase > allows, rather than having yet another extension. That is, LambdaCase now > accepts \cases as well as \case. If we'd designed it from scratch we > certainly would not have had two different extensions. > > The only downside I can see is a loss of back-compat in this program > > {-# LANGUAGE LambdaCase #-} > > module Foo where > > f = \cases -> cases + 1 -- Adds 1 > > g = \case { True -> False, False -> True } > > If we extend what LambdaCase does, the definition of f will change its > meaning. But this is so bizarre that I'm disinclined to waste time on it. > > My suggestion: expand what LambdaCase does. If not, the new extension > should be LambdaCases. > > Can you reply on the GitHub? > https://github.com/ghc-proposals/ghc-proposals/pull/302 > > 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 arnaud.spiwack at tweag.io Thu Jul 29 14:38:07 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 29 Jul 2021 16:38:07 +0200 Subject: [ghc-steering-committee] Scoping of types In-Reply-To: References: Message-ID: I'm not sure what way forward you are suggesting (and judging from the lack of response, it's probably not clear for the other committee members either). Philosophically, there is a balance to strike between backward compatibility and consistency. I'd note however that all of the existing behaviour is gated behind `ScopedTypeVariables`, which is fairly stable, but not necessarily unmovable. I don't think breaking backward compatibility would be unsurmountable. On Fri, Jul 23, 2021 at 11:50 AM Alejandro Serrano Mena wrote: > Dear Committee, > > There’s a lot happening right now in the GHC proposals repo about scoping > of types in different elements in the language. Richard asked for our > decision in #238, but following a very good suggestion from Joachim, I > think it’s better to give an overview on what’s going on. In my opinion, > this should lead to a consolidation of the different proposals into a > unified design. > > > *Current status* > > In Haskell 2010 there’s no way to refer to type variables introduced in a > type signature. For a long time, GHC has shipped with > -XScopedTypeVariables, which introduced scoping for types by prepending > them with `forall`. We could then use it in other types, or as part of a > type application if -XTypeApplications is on. > > > id :: forall a. a -> a > > id x = f @a x > > where f y = y > > In the past 3 years we’ve accepted two proposals which extend this ability: > - First to patterns > https://github.com/ghc-proposals/ghc-proposals/pull/126, so we can write > `id @a x = …` > - Then to lambdas https://github.com/ghc-proposals/ghc-proposals/pull/155, > so we can write `id = \@a x -> …` > > > *What is going on* > > It seems that the accepted proposals were not quite right. We have two > on-going proposals to *amend* the current ones: > - https://github.com/ghc-proposals/ghc-proposals/pull/291 proposes > simplifications to type variable patterns. As I understand this would make > type variables in patterns behave like term variables (cannot be repeated, > occurrences in inner scopes shadow the outer one, and so on). > - https://github.com/ghc-proposals/ghc-proposals/pull/238 introduces > -XTypeAbstractions, which make the combination of `forall` and `\@a` behave > “as it should be”. But to be honest, I do not fully grasp the problems > before, so neither how this amendment solves the problem; there’s a pointer > to the GHC issue tracker where some incompatibility is discussed > https://gitlab.haskell.org/ghc/ghc/-/issues/16734#note_203412 > - https://github.com/ghc-proposals/ghc-proposals/pull/420 amends the > current behaviour of signatures in patterns (what happens if I write `id (x > :: a)` ). > > So we have different ways to introduce new type variables: `f :: forall a. > …`, `f @a = …`, `f = \@a -> …`, `f (x :: a) = …`; and it’s very unclear > what the scoping mechanism for each one should be. I think the problem is > characterised very well in the following comment by Simon PJ > https://github.com/ghc-proposals/ghc-proposals/pull/291#issuecomment-726715932 > > > Note that this problem is arising in other places, too. For example #281, > which adds visible `forall a -> ` ( > https://github.com/ghc-proposals/ghc-proposals/pull/281) is also talking > about name resolution (see > https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-884810016 for > an example). > > > *How should we proceed* > > Personally, I am a bit worried about having divergent designs on this > matter, and the fact that no fewer than 2 amendments are being proposed (!) > For me, the best would be to come up with a unified design of how scoping > works for types, covering all possible ways to introduce and resolve them. > I am happy to help with this. > > Another important point seems to be how far we want to get from the > current status quo (-XScopedTypeVariables make a type variable in a > signature scope in its body, type variables in pattern signatures are > always fresh), and how that fits with the overall -XDependentHaskell > initiative. > > > Kind regards, > Alejandro > _______________________________________________ > 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 Jul 30 09:53:35 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 30 Jul 2021 09:53:35 +0000 Subject: [ghc-steering-committee] Scoping of types In-Reply-To: References: Message-ID: Sorry, I was not clear about the goal of the message. This all stems from the fact that Joachim asked me to shepherd #238. However, when trying to do so, I found that this was not the only proposal changing some of the scoping of types, but that there’s a lot going on with regards to that field. My question to the Committee is: should we continue shepherding the proposals independently, or should we take some time to make a general judgment about how we want scoping to work on types, in the same way that we had a general Dependent Haskell proposal? Regards, Alejandro El 29 jul 2021 16:38:07, Spiwack, Arnaud escribió: > I'm not sure what way forward you are suggesting (and judging from the > lack of response, it's probably not clear for the other committee members > either). > > Philosophically, there is a balance to strike between backward > compatibility and consistency. I'd note however that all of the existing > behaviour is gated behind `ScopedTypeVariables`, which is fairly stable, > but not necessarily unmovable. I don't think breaking backward > compatibility would be unsurmountable. > > On Fri, Jul 23, 2021 at 11:50 AM Alejandro Serrano Mena > wrote: > >> Dear Committee, >> >> There’s a lot happening right now in the GHC proposals repo about scoping >> of types in different elements in the language. Richard asked for our >> decision in #238, but following a very good suggestion from Joachim, I >> think it’s better to give an overview on what’s going on. In my opinion, >> this should lead to a consolidation of the different proposals into a >> unified design. >> >> >> *Current status* >> >> In Haskell 2010 there’s no way to refer to type variables introduced in a >> type signature. For a long time, GHC has shipped with >> -XScopedTypeVariables, which introduced scoping for types by prepending >> them with `forall`. We could then use it in other types, or as part of a >> type application if -XTypeApplications is on. >> >> > id :: forall a. a -> a >> > id x = f @a x >> > where f y = y >> >> In the past 3 years we’ve accepted two proposals which extend this >> ability: >> - First to patterns >> https://github.com/ghc-proposals/ghc-proposals/pull/126, so we can write >> `id @a x = …` >> - Then to lambdas https://github.com/ghc-proposals/ghc-proposals/pull/155, >> so we can write `id = \@a x -> …` >> >> >> *What is going on* >> >> It seems that the accepted proposals were not quite right. We have two >> on-going proposals to *amend* the current ones: >> - https://github.com/ghc-proposals/ghc-proposals/pull/291 proposes >> simplifications to type variable patterns. As I understand this would make >> type variables in patterns behave like term variables (cannot be repeated, >> occurrences in inner scopes shadow the outer one, and so on). >> - https://github.com/ghc-proposals/ghc-proposals/pull/238 introduces >> -XTypeAbstractions, which make the combination of `forall` and `\@a` behave >> “as it should be”. But to be honest, I do not fully grasp the problems >> before, so neither how this amendment solves the problem; there’s a pointer >> to the GHC issue tracker where some incompatibility is discussed >> https://gitlab.haskell.org/ghc/ghc/-/issues/16734#note_203412 >> - https://github.com/ghc-proposals/ghc-proposals/pull/420 amends the >> current behaviour of signatures in patterns (what happens if I write `id (x >> :: a)` ). >> >> So we have different ways to introduce new type variables: `f :: forall >> a. …`, `f @a = …`, `f = \@a -> …`, `f (x :: a) = …`; and it’s very unclear >> what the scoping mechanism for each one should be. I think the problem is >> characterised very well in the following comment by Simon PJ >> https://github.com/ghc-proposals/ghc-proposals/pull/291#issuecomment-726715932 >> >> >> Note that this problem is arising in other places, too. For example #281, >> which adds visible `forall a -> ` ( >> https://github.com/ghc-proposals/ghc-proposals/pull/281) is also talking >> about name resolution (see >> https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-884810016 for >> an example). >> >> >> *How should we proceed* >> >> Personally, I am a bit worried about having divergent designs on this >> matter, and the fact that no fewer than 2 amendments are being proposed (!) >> For me, the best would be to come up with a unified design of how scoping >> works for types, covering all possible ways to introduce and resolve them. >> I am happy to help with this. >> >> Another important point seems to be how far we want to get from the >> current status quo (-XScopedTypeVariables make a type variable in a >> signature scope in its body, type variables in pattern signatures are >> always fresh), and how that fits with the overall -XDependentHaskell >> initiative. >> >> >> Kind regards, >> Alejandro >> _______________________________________________ >> 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 Jul 30 15:33:51 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 30 Jul 2021 17:33:51 +0200 Subject: [ghc-steering-committee] Scoping of types In-Reply-To: References: Message-ID: Can you, maybe, summarize what the various options are? And their conflicts? On Fri, Jul 30, 2021 at 11:53 AM Alejandro Serrano Mena wrote: > Sorry, I was not clear about the goal of the message. This all stems from > the fact that Joachim asked me to shepherd #238. However, when trying to do > so, I found that this was not the only proposal changing some of the > scoping of types, but that there’s a lot going on with regards to that > field. > > My question to the Committee is: should we continue shepherding the > proposals independently, or should we take some time to make a general > judgment about how we want scoping to work on types, in the same way that > we had a general Dependent Haskell proposal? > > Regards, > Alejandro > > El 29 jul 2021 16:38:07, Spiwack, Arnaud > escribió: > >> I'm not sure what way forward you are suggesting (and judging from the >> lack of response, it's probably not clear for the other committee members >> either). >> >> Philosophically, there is a balance to strike between backward >> compatibility and consistency. I'd note however that all of the existing >> behaviour is gated behind `ScopedTypeVariables`, which is fairly stable, >> but not necessarily unmovable. I don't think breaking backward >> compatibility would be unsurmountable. >> >> On Fri, Jul 23, 2021 at 11:50 AM Alejandro Serrano Mena < >> trupill at gmail.com> wrote: >> >>> Dear Committee, >>> >>> There’s a lot happening right now in the GHC proposals repo about >>> scoping of types in different elements in the language. Richard asked for >>> our decision in #238, but following a very good suggestion from Joachim, I >>> think it’s better to give an overview on what’s going on. In my opinion, >>> this should lead to a consolidation of the different proposals into a >>> unified design. >>> >>> >>> *Current status* >>> >>> In Haskell 2010 there’s no way to refer to type variables introduced in >>> a type signature. For a long time, GHC has shipped with >>> -XScopedTypeVariables, which introduced scoping for types by prepending >>> them with `forall`. We could then use it in other types, or as part of a >>> type application if -XTypeApplications is on. >>> >>> > id :: forall a. a -> a >>> > id x = f @a x >>> > where f y = y >>> >>> In the past 3 years we’ve accepted two proposals which extend this >>> ability: >>> - First to patterns >>> https://github.com/ghc-proposals/ghc-proposals/pull/126, so we can >>> write `id @a x = …` >>> - Then to lambdas >>> https://github.com/ghc-proposals/ghc-proposals/pull/155, so we can >>> write `id = \@a x -> …` >>> >>> >>> *What is going on* >>> >>> It seems that the accepted proposals were not quite right. We have two >>> on-going proposals to *amend* the current ones: >>> - https://github.com/ghc-proposals/ghc-proposals/pull/291 proposes >>> simplifications to type variable patterns. As I understand this would make >>> type variables in patterns behave like term variables (cannot be repeated, >>> occurrences in inner scopes shadow the outer one, and so on). >>> - https://github.com/ghc-proposals/ghc-proposals/pull/238 introduces >>> -XTypeAbstractions, which make the combination of `forall` and `\@a` behave >>> “as it should be”. But to be honest, I do not fully grasp the problems >>> before, so neither how this amendment solves the problem; there’s a pointer >>> to the GHC issue tracker where some incompatibility is discussed >>> https://gitlab.haskell.org/ghc/ghc/-/issues/16734#note_203412 >>> - https://github.com/ghc-proposals/ghc-proposals/pull/420 amends the >>> current behaviour of signatures in patterns (what happens if I write `id (x >>> :: a)` ). >>> >>> So we have different ways to introduce new type variables: `f :: forall >>> a. …`, `f @a = …`, `f = \@a -> …`, `f (x :: a) = …`; and it’s very unclear >>> what the scoping mechanism for each one should be. I think the problem is >>> characterised very well in the following comment by Simon PJ >>> https://github.com/ghc-proposals/ghc-proposals/pull/291#issuecomment-726715932 >>> >>> >>> Note that this problem is arising in other places, too. For example >>> #281, which adds visible `forall a -> ` ( >>> https://github.com/ghc-proposals/ghc-proposals/pull/281) is also >>> talking about name resolution (see >>> https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-884810016 for >>> an example). >>> >>> >>> *How should we proceed* >>> >>> Personally, I am a bit worried about having divergent designs on this >>> matter, and the fact that no fewer than 2 amendments are being proposed (!) >>> For me, the best would be to come up with a unified design of how scoping >>> works for types, covering all possible ways to introduce and resolve them. >>> I am happy to help with this. >>> >>> Another important point seems to be how far we want to get from the >>> current status quo (-XScopedTypeVariables make a type variable in a >>> signature scope in its body, type variables in pattern signatures are >>> always fresh), and how that fits with the overall -XDependentHaskell >>> initiative. >>> >>> >>> Kind regards, >>> Alejandro >>> _______________________________________________ >>> 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: