From eric at seidel.io Fri Oct 1 02:17:13 2021 From: eric at seidel.io (Eric Seidel) Date: Thu, 30 Sep 2021 22:17:13 -0400 Subject: [ghc-steering-committee] =?utf-8?q?=23409=3A_Exportable_named_def?= =?utf-8?q?aults=2C_Recommendation=3A_Accept?= In-Reply-To: References: <58CA0B9F-0B7B-40C8-A8E3-BB8A588B8B84@seidel.io> <010f017b61557982-284fcbc1-ff82-4cf5-8cb1-8bb6be5b01df-000000@us-east-2.amazonses.com> Message-ID: Hi all, Following a bit more back and forth on the details, I have accepted the proposal. Thanks! On Fri, Aug 20, 2021, at 10:26, Alejandro Serrano Mena wrote: > I am also happy with that solution. > > Regards, > Alejandro > > El El vie, 20 ago 2021 a las 4:13, Richard Eisenberg > escribió: >> I'm happy with this. Thanks! >> >> Richard >> >>> On Aug 19, 2021, at 9:25 AM, Eric Seidel wrote: >>> >>> Dear Committee, >>> >>> Simon PJ has requested (on GitHub) that we merge all aspects of this proposal into a single extension NamedDefaults. We already had agreement that the import behavior should not be guarded by any extension, so I take this to mean the following. >>> >>> The proposal will introduce a single new extension NamedDefaults that enables: >>> >>> 1. The ‘default C (T1, T2, …)’ syntax that specifies the defaulted class. >>> 2. Exporting defaulting rules as discussed (explicitly, in the export list). >>> >>> Defaulting rules are always imported (implicitly), with no need to enable the NamedDefaults extension. >>> >>> Any objections? >>> >>> Sent from my iPhone >>> >>>> On Aug 14, 2021, at 12:58, Simon Peyton Jones wrote: >>>> >>>>  >>>> Eric____ >>>> __ __ >>>> I’m in support too – but I have added three small qns to the GitHub thread.____ >>>> >>>> Simon____ >>>> __ __ >>>> *From:* ghc-steering-committee *On Behalf Of *Spiwack, Arnaud >>>> *Sent:* 05 August 2021 07:43 >>>> *To:* Eric Seidel >>>> *Cc:* ghc-steering-committee at haskell.org >>>> *Subject:* Re: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Accept____ >>>> __ __ >>>> I'm very supportive of this proposal. Thanks to everyone who participated in the discussion. Like Eric, I don't see any value to the ImportedDefault extension, and would rather we removed it.____ >>>> __ __ >>>> On Tue, Aug 3, 2021 at 4:10 AM Eric Seidel wrote:____ >>>>> Committee, >>>>> >>>>> Mario has updated the proposal following some discussion on GitHub around the question of implicit vs explicit export and import of default rules. The result is >>>>> >>>>> 1. *Implicit import*: any and all forms of `import M` also import any defaulting rules exported by M, like type classes. >>>>> >>>>> 2. *Explicit export*: defaulting rules must be explicitly exported like named things, mostly. The one exception is that >>>>> >>>>> module M (module N) where { import N } >>>>> >>>>> does not re-export any defaulting rules imported from N. Simon PJ argued strongly for this change on GitHub[1]. >>>>> >>>>> With that question settled, and with Simon and Richard's assent on GitHub, *I'd like to recommend that we accept the proposal*. However, I still do not see the need for a separate ImportedDefaults extension and would recommend that we enable the import behavior universally. >>>>> >>>>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-882338794 >>>>> >>>>> On Mon, Jul 12, 2021, at 04:09, Simon Peyton Jones wrote: >>>>> > >>>>> > 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 >>>>> _______________________________________________ >>>>> ghc-steering-committee mailing list >>>>> ghc-steering-committee at haskell.org >>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee ____ >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Tue Oct 5 19:50:40 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 05 Oct 2021 21:50:40 +0200 Subject: [ghc-steering-committee] GHC20xx review; GHC2022 yes or no? Message-ID: <2c5389c5b8c0957a82f8eaa2758e1b3010382dc8.camel@joachim-breitner.de> Hi Committee, when we defined the process for GHC20xx, as written in https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst we wrote Likely, the first iteration of this process will be vastly different from the following ones: The first one is expected to add a large number of uncontroversial extensions; so the next iteration will likely only make a smaller, but more controversial change. Therefore, this proposal does not commit to a fixed cadence. Instead, 6 months after the first release of a version of GHC that supports a GHC20xx set, we evaluate the outcome, the process, and the perceived need of a next release. At that time we will refine the processes, if needed, and set a cadence. The first version of GHC that supported GHC20xx is 9.2, released in March. So we should do this evaluation now. My impression is that 9.2 hasn’t reached the masses yet: NixOS stable doesn’t even have it, and the default is at 8.10. Stackage LTS is at 8.10, and nightly at 9.0 Debian is at 8.8. So it seems premature to try to evaluate its impact, and what, if anything, we should do differently for a hypothetical GHC2022. So I suggest we postpone this review for another half year or so. Also, I don’t see why GHC2022 would be different than GHC2021. Not that much has changed about GHC and its set of “should-be-default” extensions since last year, has it? So I suggest we don’t work on defining GHC2022, and the next update will be GHC2023 (or later). What do you think, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From lists at richarde.dev Tue Oct 5 21:49:59 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 5 Oct 2021 21:49:59 +0000 Subject: [ghc-steering-committee] GHC20xx review; GHC2022 yes or no? In-Reply-To: <2c5389c5b8c0957a82f8eaa2758e1b3010382dc8.camel@joachim-breitner.de> References: <2c5389c5b8c0957a82f8eaa2758e1b3010382dc8.camel@joachim-breitner.de> Message-ID: <010f017c526f5080-d570ff47-88f4-4c5f-924e-93f8384c82f5-000000@us-east-2.amazonses.com> What makes you say 9.2 has been released? I don't think it has been. https://www.haskell.org/ghc/download.html does not list it, for example. Otherwise, I agree on holding off. Thanks for raising this! Richard > On Oct 5, 2021, at 3:50 PM, Joachim Breitner wrote: > > Hi Committee, > > when we defined the process for GHC20xx, as written in > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst > we wrote > > Likely, the first iteration of this process will be vastly different > from the following ones: The first one is expected to add a large > number of uncontroversial extensions; so the next iteration will > likely only make a smaller, but more controversial change. > > Therefore, this proposal does not commit to a fixed cadence. > Instead, 6 months after the first release of a version of GHC that > supports a GHC20xx set, we evaluate the outcome, the process, and > the perceived need of a next release. At that time we will refine > the processes, if needed, and set a cadence. > > The first version of GHC that supported GHC20xx is 9.2, released in March. > So we should do this evaluation now. > > My impression is that 9.2 hasn’t reached the masses yet: > NixOS stable doesn’t even have it, and the default is at 8.10. > Stackage LTS is at 8.10, and nightly at 9.0 > Debian is at 8.8. > > So it seems premature to try to evaluate its impact, and what, if > anything, we should do differently for a hypothetical GHC2022. > > So I suggest we postpone this review for another half year or so. > > Also, I don’t see why GHC2022 would be different than GHC2021. Not that > much has changed about GHC and its set of “should-be-default” > extensions since last year, has it? > > So I suggest we don’t work on defining GHC2022, and the next update > will be GHC2023 (or later). > > > What do you think, > Joachim > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Wed Oct 6 08:28:45 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 6 Oct 2021 08:28:45 +0000 (UTC) Subject: [ghc-steering-committee] GHC20xx review; GHC2022 yes or no? In-Reply-To: <010f017c526f5080-d570ff47-88f4-4c5f-924e-93f8384c82f5-000000@us-east-2.amazonses.com> References: <2c5389c5b8c0957a82f8eaa2758e1b3010382dc8.camel@joachim-breitner.de> <010f017c526f5080-d570ff47-88f4-4c5f-924e-93f8384c82f5-000000@us-east-2.amazonses.com> Message-ID: Right, I thought it wasn't, and phrased the mail accordingly. But then I noticed that the timeline in https://gitlab.haskell.org/ghc/ghc/-/milestones/365 said 2021, not 2022, and that it already is in nixpkgs, so I drew the wrong conclusions, and changed my mail again Anyways even more the reason to skip GHC2022 05.10.2021 23:50:06 Richard Eisenberg : > What makes you say 9.2 has been released? I don't think it has been. https://www.haskell.org/ghc/download.html does not list it, for example. > > Otherwise, I agree on holding off. > > Thanks for raising this! > Richard > >> On Oct 5, 2021, at 3:50 PM, Joachim Breitner wrote: >> >> Hi Committee, >> >> when we defined the process for GHC20xx, as written in >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst >> we wrote >> >>   Likely, the first iteration of this process will be vastly different >>   from the following ones: The first one is expected to add a large >>   number of uncontroversial extensions; so the next iteration will >>   likely only make a smaller, but more controversial change. >> >>   Therefore, this proposal does not commit to a fixed cadence. >>   Instead, 6 months after the first release of a version of GHC that >>   supports a GHC20xx set, we evaluate the outcome, the process, and >>   the perceived need of a next release. At that time we will refine >>   the processes, if needed, and set a cadence. >> >> The first version of GHC that supported GHC20xx is 9.2, released in March. >> So we should do this evaluation now. >> >> My impression is that 9.2 hasn’t reached the masses yet: >> NixOS stable doesn’t even have it, and the default is at 8.10. >> Stackage LTS is at 8.10, and nightly at 9.0 >> Debian is at 8.8. >> >> So it seems premature to try to evaluate its impact, and what, if >> anything, we should do differently for a hypothetical GHC2022. >> >> So I suggest we postpone this review for another half year or so. >> >> Also, I don’t see why GHC2022 would be different than GHC2021. Not that >> much has changed about GHC and its set of “should-be-default” >> extensions since last year, has it? >> >> So I suggest we don’t work on defining GHC2022, and the next update >> will be GHC2023 (or later). >> >> >> What do you think, >> Joachim >> >> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From simonpj at microsoft.com Wed Oct 6 08:32:47 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Oct 2021 08:32:47 +0000 Subject: [ghc-steering-committee] GHC20xx review; GHC2022 yes or no? In-Reply-To: References: <2c5389c5b8c0957a82f8eaa2758e1b3010382dc8.camel@joachim-breitner.de> <010f017c526f5080-d570ff47-88f4-4c5f-924e-93f8384c82f5-000000@us-east-2.amazonses.com> Message-ID: > Anyways even more the reason to skip GHC2022 I'm fine with doing that. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 06 October 2021 09:29 | To: Richard Eisenberg | Cc: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] GHC20xx review; GHC2022 yes or | no? | | Right, I thought it wasn't, and phrased the mail accordingly. But then | I noticed that the timeline in | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl | ab.haskell.org%2Fghc%2Fghc%2F- | %2Fmilestones%2F365&data=04%7C01%7Csimonpj%40microsoft.com%7Cb7fbe | c91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0 | %7C637691058751508157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ | IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TBDthig0E0 | aXoyYtUYaTaXLHi%2FWQAenQjAlWh5upptU%3D&reserved=0 said 2021, not | 2022, and that it already is in nixpkgs, so I drew the wrong | conclusions, and changed my mail again | | Anyways even more the reason to skip GHC2022 | | | 05.10.2021 23:50:06 Richard Eisenberg : | | > What makes you say 9.2 has been released? I don't think it has been. | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. | haskell.org%2Fghc%2Fdownload.html&data=04%7C01%7Csimonpj%40microso | ft.com%7Cb7fbec91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd0 | 11db47%7C1%7C0%7C637691058751508157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC | 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sd | ata=kWHHoWI0Zq9J8WZ2aZ5m9rIN%2FYgZWloDullgNrV2Dow%3D&reserved=0 | does not list it, for example. | > | > Otherwise, I agree on holding off. | > | > Thanks for raising this! | > Richard | > | >> On Oct 5, 2021, at 3:50 PM, Joachim Breitner wrote: | >> | >> Hi Committee, | >> | >> when we defined the process for GHC20xx, as written in | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit | >> hub.com%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fmaster%2Fproposals%2 | >> F0372-ghc- | extensions.rst&data=04%7C01%7Csimonpj%40microsoft.com%7 | >> | Cb7fbec91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47% | >> | 7C1%7C0%7C637691058751518154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw | >> | MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=t | >> AlnW8KOVrcNnV3C2BZlMUfmT0BHPKX0achIeGb2L3g%3D&reserved=0 | >> we wrote | >> | >>   Likely, the first iteration of this process will be vastly | >> different | >>   from the following ones: The first one is expected to add a large | >>   number of uncontroversial extensions; so the next iteration will | >>   likely only make a smaller, but more controversial change. | >> | >>   Therefore, this proposal does not commit to a fixed cadence. | >>   Instead, 6 months after the first release of a version of GHC | that | >>   supports a GHC20xx set, we evaluate the outcome, the process, and | >>   the perceived need of a next release. At that time we will refine | >>   the processes, if needed, and set a cadence. | >> | >> The first version of GHC that supported GHC20xx is 9.2, released in | March. | >> So we should do this evaluation now. | >> | >> My impression is that 9.2 hasn't reached the masses yet: | >> NixOS stable doesn't even have it, and the default is at 8.10. | >> Stackage LTS is at 8.10, and nightly at 9.0 Debian is at 8.8. | >> | >> So it seems premature to try to evaluate its impact, and what, if | >> anything, we should do differently for a hypothetical GHC2022. | >> | >> So I suggest we postpone this review for another half year or so. | >> | >> Also, I don't see why GHC2022 would be different than GHC2021. Not | >> that much has changed about GHC and its set of "should-be-default" | >> extensions since last year, has it? | >> | >> So I suggest we don't work on defining GHC2022, and the next update | >> will be GHC2023 (or later). | >> | >> | >> What do you think, | >> Joachim | >> | >> | >> -- | >> Joachim Breitner | >> mail at joachim-breitner.de | >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. | >> joachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb | >> | 7fbec91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C | >> | 1%7C0%7C637691058751518154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD | >> | AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n9P | >> oL8dXA8ZGWywvHhkUY19mrk1WBSWTYWQHX9uTm3Q%3D&reserved=0 | >> | >> | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee at haskell.org | >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai | >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee | >> | &data=04%7C01%7Csimonpj%40microsoft.com%7Cb7fbec91949c4c109ed608d | >> | 988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63769105875151 | >> | 8154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB | >> | TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FxFajSncDl5oRbeAY%2B%2F | >> KdrSHMCuwvhruwYxNnkVgZig%3D&reserved=0 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb7fbec91949c4c1 | 09ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376910 | 58751518154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FxFajSncDl5oRbeAY% | 2B%2FKdrSHMCuwvhruwYxNnkVgZig%3D&reserved=0 From arnaud.spiwack at tweag.io Wed Oct 6 12:17:58 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 6 Oct 2021 14:17:58 +0200 Subject: [ghc-steering-committee] GHC20xx review; GHC2022 yes or no? In-Reply-To: References: <2c5389c5b8c0957a82f8eaa2758e1b3010382dc8.camel@joachim-breitner.de> <010f017c526f5080-d570ff47-88f4-4c5f-924e-93f8384c82f5-000000@us-east-2.amazonses.com> Message-ID: I agree with skipping. On Wed, Oct 6, 2021 at 10:33 AM Simon Peyton Jones via ghc-steering-committee wrote: > > Anyways even more the reason to skip GHC2022 > > I'm fine with doing that. > > Simon > > PS: I am leaving Microsoft at the end of November 2021, at which point > simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com > instead. (For now, it just forwards to simonpj at microsoft.com.) > > | -----Original Message----- > | From: ghc-steering-committee | bounces at haskell.org> On Behalf Of Joachim Breitner > | Sent: 06 October 2021 09:29 > | To: Richard Eisenberg > | Cc: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] GHC20xx review; GHC2022 yes or > | no? > | > | Right, I thought it wasn't, and phrased the mail accordingly. But then > | I noticed that the timeline in > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl > | ab.haskell.org%2Fghc%2Fghc%2F- > | %2Fmilestones%2F365&data=04%7C01%7Csimonpj%40microsoft.com%7Cb7fbe > | c91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0 > | %7C637691058751508157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ > | IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TBDthig0E0 > | aXoyYtUYaTaXLHi%2FWQAenQjAlWh5upptU%3D&reserved=0 said 2021, not > | 2022, and that it already is in nixpkgs, so I drew the wrong > | conclusions, and changed my mail again > | > | Anyways even more the reason to skip GHC2022 > | > | > | 05.10.2021 23:50:06 Richard Eisenberg : > | > | > What makes you say 9.2 has been released? I don't think it has been. > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > | haskell.org%2Fghc%2Fdownload.html&data=04%7C01%7Csimonpj%40microso > | ft.com%7Cb7fbec91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd0 > | 11db47%7C1%7C0%7C637691058751508157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC > | 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sd > | ata=kWHHoWI0Zq9J8WZ2aZ5m9rIN%2FYgZWloDullgNrV2Dow%3D&reserved=0 > | does not list it, for example. > | > > | > Otherwise, I agree on holding off. > | > > | > Thanks for raising this! > | > Richard > | > > | >> On Oct 5, 2021, at 3:50 PM, Joachim Breitner | breitner.de> wrote: > | >> > | >> Hi Committee, > | >> > | >> when we defined the process for GHC20xx, as written in > | >> > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit > | >> hub.com%2Fghc-proposals%2Fghc- > | proposals%2Fblob%2Fmaster%2Fproposals%2 > | >> F0372-ghc- > | extensions.rst&data=04%7C01%7Csimonpj%40microsoft.com%7 > | >> > | Cb7fbec91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47% > | >> > | 7C1%7C0%7C637691058751518154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > | >> > | MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=t > | >> AlnW8KOVrcNnV3C2BZlMUfmT0BHPKX0achIeGb2L3g%3D&reserved=0 > | >> we wrote > | >> > | >> Likely, the first iteration of this process will be vastly > | >> different > | >> from the following ones: The first one is expected to add a large > | >> number of uncontroversial extensions; so the next iteration will > | >> likely only make a smaller, but more controversial change. > | >> > | >> Therefore, this proposal does not commit to a fixed cadence. > | >> Instead, 6 months after the first release of a version of GHC > | that > | >> supports a GHC20xx set, we evaluate the outcome, the process, and > | >> the perceived need of a next release. At that time we will refine > | >> the processes, if needed, and set a cadence. > | >> > | >> The first version of GHC that supported GHC20xx is 9.2, released in > | March. > | >> So we should do this evaluation now. > | >> > | >> My impression is that 9.2 hasn't reached the masses yet: > | >> NixOS stable doesn't even have it, and the default is at 8.10. > | >> Stackage LTS is at 8.10, and nightly at 9.0 Debian is at 8.8. > | >> > | >> So it seems premature to try to evaluate its impact, and what, if > | >> anything, we should do differently for a hypothetical GHC2022. > | >> > | >> So I suggest we postpone this review for another half year or so. > | >> > | >> Also, I don't see why GHC2022 would be different than GHC2021. Not > | >> that much has changed about GHC and its set of "should-be-default" > | >> extensions since last year, has it? > | >> > | >> So I suggest we don't work on defining GHC2022, and the next update > | >> will be GHC2023 (or later). > | >> > | >> > | >> What do you think, > | >> Joachim > | >> > | >> > | >> -- > | >> Joachim Breitner > | >> mail at joachim-breitner.de > | >> > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. > | >> joachim- > | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb > | >> > | 7fbec91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C > | >> > | 1%7C0%7C637691058751518154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > | >> > | AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n9P > | >> oL8dXA8ZGWywvHhkUY19mrk1WBSWTYWQHX9uTm3Q%3D&reserved=0 > | >> > | >> > | >> _______________________________________________ > | >> ghc-steering-committee mailing list > | >> ghc-steering-committee at haskell.org > | >> > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai > | >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee > | >> > | &data=04%7C01%7Csimonpj%40microsoft.com%7Cb7fbec91949c4c109ed608d > | >> > | 988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63769105875151 > | >> > | 8154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB > | >> > | TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FxFajSncDl5oRbeAY%2B%2F > | >> KdrSHMCuwvhruwYxNnkVgZig%3D&reserved=0 > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail > | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb7fbec91949c4c1 > | 09ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376910 > | 58751518154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz > | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FxFajSncDl5oRbeAY% > | 2B%2FKdrSHMCuwvhruwYxNnkVgZig%3D&reserved=0 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Thu Oct 7 07:52:31 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 7 Oct 2021 09:52:31 +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> <010f017ae3c9e2b2-5118dc4d-7d82-4b69-bbef-4d3c2e3b2e01-000000@us-east-2.amazonses.com> Message-ID: Dear all, First sorry I'm a bit late on this, life got in the way. I've got opinions from both Simons, Tom, and Alejandro. Eric, Joachim, Vitaly, Vlad what do you think about all this? --- If I were to summarise the discussion as I understand it, the major point of discussion is the difference between local modules (which are pure name-spacing entities) and global/top-level modules (which are compilation units, hence can appear in import statements for dependency management). Simon PJ has argued (in an off-band conversation with Richard and I) to embrace the difference more, though in many places in the proposal, these two kind of modules are used the same way, hence deserving the common name of “module”. Simon Marlow is worried that the lack of distinction between global module addressing and local module addressing in `A.B.C.x` can be confusing (is `A.B` a global module, or is `A` the global module and `B.C` the local module?). (I'd personally argue, regarding this latter point, that it doesn't matter. By the time we are able to name `A.B.C.x` in a file, global modules may have been renamed, so we have changed a name representing a compilation unit into a namespace, which may or may not be identical. The proposal don't treat the two situations differently at all) Another point of discussion which hasn't appeared on this list but has been raised in the Github thread, is that the current proposal goes to great length to make exporting `module M` more or less compatible with the current behaviour giving it a very different semantic to exporting `module qualified M` (these are currently items 4.iv, 4.v, and 4.vi in the specification section of the proposal). Note that is not fully backwards compatible and even with existing module can export more stuff. The question is whether it is worth trying to match the existing behaviour of `module M`, or whether a simpler notion which is in line with the behaviour of `module qualified M` would be preferable. Over to you :-) /Arnaud On Tue, Jul 27, 2021 at 6:01 PM Simon Marlow wrote: > 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 vlad.z.4096 at gmail.com Sun Oct 10 20:36:53 2021 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Sun, 10 Oct 2021 23:36:53 +0300 Subject: [ghc-steering-committee] Visible forall: 3-Year Anniversary Message-ID: <05523B37-3DA0-4FF3-9587-79BDA6CEBCF3@gmail.com> Dear GHC Steering Committee, Today (10 Oct, 2021) marks three years since the pull request for the #281 “Visible forall” proposal was opened. https://github.com/ghc-proposals/ghc-proposals/pull/281 There has been a lot of discussion, which led to numerous refinements and improvements to the proposal text and its content. When the initial version of the proposal was written, it wasn’t clear if this feature would be a good addition to Haskell. But now that #378 “Design for dependent types” has been accepted, the job of #281 “Visible forall” is merely to elaborate the details of a design that we already agreed on. Because of its reduced scope, I hope there won’t be a 4th anniversary. So I invite everyone to take a look at the current iteration of the proposal and vote on it. The proposal text is at: https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst - Vlad From vlad.z.4096 at gmail.com Sun Oct 10 20:42:04 2021 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Sun, 10 Oct 2021 23:42:04 +0300 Subject: [ghc-steering-committee] Visible forall: 3-Year Anniversary In-Reply-To: <05523B37-3DA0-4FF3-9587-79BDA6CEBCF3@gmail.com> References: <05523B37-3DA0-4FF3-9587-79BDA6CEBCF3@gmail.com> Message-ID: Oh no. It seems I made the best kind of error – an off-by-one error. It’s only the 2-Year Anniversary! This is, of course, good news, as it means the process is 1.5 times faster than I assumed. The call to action stays the same: let’s move forward with the proposal. - Vlad > On 10 Oct 2021, at 23:36, Vladislav Zavialov (int-index) wrote: > > Dear GHC Steering Committee, > > Today (10 Oct, 2021) marks three years since the pull request for the #281 “Visible forall” proposal was opened. > > https://github.com/ghc-proposals/ghc-proposals/pull/281 > > There has been a lot of discussion, which led to numerous refinements and improvements to the proposal text and its content. > > When the initial version of the proposal was written, it wasn’t clear if this feature would be a good addition to Haskell. But now that #378 “Design for dependent types” has been accepted, the job of #281 “Visible forall” is merely to elaborate the details of a design that we already agreed on. > > Because of its reduced scope, I hope there won’t be a 4th anniversary. So I invite everyone to take a look at the current iteration of the proposal and vote on it. > > The proposal text is at: https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst > > - Vlad From trupill at gmail.com Mon Oct 11 13:59:13 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 11 Oct 2021 13:59:13 +0000 Subject: [ghc-steering-committee] GHC20xx review; GHC2022 yes or no? In-Reply-To: References: <2c5389c5b8c0957a82f8eaa2758e1b3010382dc8.camel@joachim-breitner.de> <010f017c526f5080-d570ff47-88f4-4c5f-924e-93f8384c82f5-000000@us-east-2.amazonses.com> Message-ID: Skipping seems like the most sensible option. Regards, Alejandro El 6 oct 2021 14:17:58, Spiwack, Arnaud escribió: > I agree with skipping. > > On Wed, Oct 6, 2021 at 10:33 AM Simon Peyton Jones via > ghc-steering-committee wrote: > >> > Anyways even more the reason to skip GHC2022 >> >> I'm fine with doing that. >> >> Simon >> >> PS: I am leaving Microsoft at the end of November 2021, at which point >> simonpj at microsoft.com will cease to work. Use >> simon.peytonjones at gmail.com instead. (For now, it just forwards to >> simonpj at microsoft.com.) >> >> | -----Original Message----- >> | From: ghc-steering-committee > | bounces at haskell.org> On Behalf Of Joachim Breitner >> | Sent: 06 October 2021 09:29 >> | To: Richard Eisenberg >> | Cc: ghc-steering-committee at haskell.org >> | Subject: Re: [ghc-steering-committee] GHC20xx review; GHC2022 yes or >> | no? >> | >> | Right, I thought it wasn't, and phrased the mail accordingly. But then >> | I noticed that the timeline in >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl >> | ab.haskell.org%2Fghc%2Fghc%2F- >> | %2Fmilestones%2F365&data=04%7C01%7Csimonpj%40microsoft.com%7Cb7fbe >> | c91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0 >> | %7C637691058751508157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ >> | IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=TBDthig0E0 >> | aXoyYtUYaTaXLHi%2FWQAenQjAlWh5upptU%3D&reserved=0 said 2021, not >> | 2022, and that it already is in nixpkgs, so I drew the wrong >> | conclusions, and changed my mail again >> | >> | Anyways even more the reason to skip GHC2022 >> | >> | >> | 05.10.2021 23:50:06 Richard Eisenberg : >> | >> | > What makes you say 9.2 has been released? I don't think it has been. >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. >> | haskell.org%2Fghc%2Fdownload.html&data=04%7C01%7Csimonpj%40microso >> | ft.com%7Cb7fbec91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd0 >> | 11db47%7C1%7C0%7C637691058751508157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC >> | 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sd >> | ata=kWHHoWI0Zq9J8WZ2aZ5m9rIN%2FYgZWloDullgNrV2Dow%3D&reserved=0 >> | does not list it, for example. >> | > >> | > Otherwise, I agree on holding off. >> | > >> | > Thanks for raising this! >> | > Richard >> | > >> | >> On Oct 5, 2021, at 3:50 PM, Joachim Breitner > | breitner.de> wrote: >> | >> >> | >> Hi Committee, >> | >> >> | >> when we defined the process for GHC20xx, as written in >> | >> >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit >> | >> hub.com%2Fghc-proposals%2Fghc- >> | proposals%2Fblob%2Fmaster%2Fproposals%2 >> | >> F0372-ghc- >> | extensions.rst&data=04%7C01%7Csimonpj%40microsoft.com%7 >> | >> >> | Cb7fbec91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47% >> | >> >> | 7C1%7C0%7C637691058751518154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw >> | >> >> | MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=t >> | >> AlnW8KOVrcNnV3C2BZlMUfmT0BHPKX0achIeGb2L3g%3D&reserved=0 >> | >> we wrote >> | >> >> | >> Likely, the first iteration of this process will be vastly >> | >> different >> | >> from the following ones: The first one is expected to add a large >> | >> number of uncontroversial extensions; so the next iteration will >> | >> likely only make a smaller, but more controversial change. >> | >> >> | >> Therefore, this proposal does not commit to a fixed cadence. >> | >> Instead, 6 months after the first release of a version of GHC >> | that >> | >> supports a GHC20xx set, we evaluate the outcome, the process, and >> | >> the perceived need of a next release. At that time we will refine >> | >> the processes, if needed, and set a cadence. >> | >> >> | >> The first version of GHC that supported GHC20xx is 9.2, released in >> | March. >> | >> So we should do this evaluation now. >> | >> >> | >> My impression is that 9.2 hasn't reached the masses yet: >> | >> NixOS stable doesn't even have it, and the default is at 8.10. >> | >> Stackage LTS is at 8.10, and nightly at 9.0 Debian is at 8.8. >> | >> >> | >> So it seems premature to try to evaluate its impact, and what, if >> | >> anything, we should do differently for a hypothetical GHC2022. >> | >> >> | >> So I suggest we postpone this review for another half year or so. >> | >> >> | >> Also, I don't see why GHC2022 would be different than GHC2021. Not >> | >> that much has changed about GHC and its set of "should-be-default" >> | >> extensions since last year, has it? >> | >> >> | >> So I suggest we don't work on defining GHC2022, and the next update >> | >> will be GHC2023 (or later). >> | >> >> | >> >> | >> What do you think, >> | >> Joachim >> | >> >> | >> >> | >> -- >> | >> Joachim Breitner >> | >> mail at joachim-breitner.de >> | >> >> | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. >> | >> joachim- >> | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cb >> | >> >> | 7fbec91949c4c109ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C >> | >> >> | 1%7C0%7C637691058751518154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD >> | >> >> | AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=n9P >> | >> oL8dXA8ZGWywvHhkUY19mrk1WBSWTYWQHX9uTm3Q%3D&reserved=0 >> | >> >> | >> >> | >> _______________________________________________ >> | >> ghc-steering-committee mailing list >> | >> ghc-steering-committee at haskell.org >> | >> >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai >> | >> l.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- >> | committee >> | >> >> | &data=04%7C01%7Csimonpj%40microsoft.com%7Cb7fbec91949c4c109ed608d >> | >> >> | 988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63769105875151 >> | >> >> | 8154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJB >> | >> >> | TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FxFajSncDl5oRbeAY%2B%2F >> | >> KdrSHMCuwvhruwYxNnkVgZig%3D&reserved=0 >> | _______________________________________________ >> | ghc-steering-committee mailing list >> | ghc-steering-committee at haskell.org >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail >> | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- >> | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb7fbec91949c4c1 >> | 09ed608d988a37091%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6376910 >> | 58751518154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz >> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FxFajSncDl5oRbeAY% >> | 2B%2FKdrSHMCuwvhruwYxNnkVgZig%3D&reserved=0 >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Tue Oct 12 19:04:49 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 12 Oct 2021 19:04:49 +0000 Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept In-Reply-To: <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> References: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> Message-ID: <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> This proposal has been revised for clarity, yet much of the payload is the same. I've just made a few small suggestions, but I believe we can deliberate here in parallel. To recap: Proposal PR: https://github.com/ghc-proposals/ghc-proposals/pull/281 Proposal text: https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst The text of the proposal is long and detailed, but do not be daunted: it is simpler in practice than it appears. The main payload of the proposal is: Introduce a new extension -XRequiredTypeArguments. With this extension enabled, the `forall ... ->` syntax, currently in existence in kinds, is now available in types (of ordinary functions). This means that function definitions and call sites are sometimes required to write a type argument. The type argument is *not* preceded by @ or any other syntactic marker. This is useful for defining what would otherwise be ambiguous types. Example: > sizeof :: forall a -> Sizeable a => Int > sizeof = ... > > intWidth = sizeof Int There are further examples and motivation in the proposal. The rest of the proposal is simply about dealing with odd corner cases that come up with the main payload. In particular, mixing types in with terms with no syntactic signifier means that we must be careful about parsing and namespaces. If a type argument is written in the syntax that is shared between types and terms (including function application!) and uses identifiers in scope in only one of the two namespaces, nothing unusual can be observed. But, of course, there are corner cases. Here are some of the salient details: - Define type-syntax and term-syntax, where the choice of syntax is always driven by syntactic markers, such as :: or @. See the dependent types proposal for more details. Parsing and name-resolution are controlled by whether a phrase is in type-syntax or term-syntax. For name resolution, if a lookup fails in the first namespace (the term-level namespace in term-syntax or the type-level namespace in type-syntax), we try the other namespace before failing. - One unfortunate consequence of this extra namespace looking is around implicit quantification. If we have `a = 42` in scope and write `f :: a -> a`, that `a` will not be implicitly quantified. Instead, the user will get an error about the appearance of a term in a type -- but only if -XRequiredTypeArguments is on. This change affects no current code, but it does make the extension fork-like, in that enabling the new extension is not conservative. - Because term- vs type-syntax is controlled by syntax, a required type argument is in *term*-syntax and gets name-resolved *as a term*. In the absence of punning, this works out fine, but it is possible that a punned identifier will cause confusion. The proposal allows users to write `type` to signify a switch to type-syntax. - The proposal also includes a way to avoid punning for the built-in types with privileged syntax: lists and tuples. This method allows users to specify -XNoListTupleTypeSyntax to disable the list and tuple syntax in types (but still allows it for terms). The proposal also suggests exporting type List = [] from Data.List and other synonyms for tuples from Data.Tuple. --------------- I recommend acceptance. When doing type-level programming, the lack of this feature is strange, leading to ambiguous types and easy-to-forget arguments and easy-to-make type errors. The design space here is difficult, but this proposal is very much in keeping with the design sketch of our recently-accepted #378, in particular its section on this point . I believe the design described here is both backward compatible with what we have today (users who do not use this feature will not notice a difference) and forward compatible with a cohesive design for dependent types. The "unfortunate consequence" above is, well, unfortunate, but I think it is unavoidable in the context of #378 -- and it will not bite if the user avoids puns. It would be great to bring this long-running proposal to a conclusion, so I'd love to hear your opinions in the next two weeks. Thanks! Richard > On Jul 19, 2021, at 3:22 PM, Richard Eisenberg wrote: > > 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 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Oct 13 11:16:39 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 13 Oct 2021 13:16:39 +0200 Subject: [ghc-steering-committee] Visible forall: 3-Year Anniversary In-Reply-To: <05523B37-3DA0-4FF3-9587-79BDA6CEBCF3@gmail.com> References: <05523B37-3DA0-4FF3-9587-79BDA6CEBCF3@gmail.com> Message-ID: <32f393dbc06c1fef586402293f99b272db80f1fe.camel@joachim-breitner.de> Hi, thanks for pushing us here again. Fundamentally in favor. For those of you who are not following Github, Vlad and I are disagreeing over how breaking the change can be. The proposal as it stands makes forall a keyword in terms – irrespective of any extensions that are on. Vlad argues that this is good: Code that uses forall as an identifier should change that as soon as possible. Also, it simplifies the implementation of the lexer and parser if the keywordhood of `forall` doesn't depend on extensions. I argue that this is too inconsiderate towards our users. While I am generally not hesitant to require _code changes_, possibly even with CPP, when people enable new extensions, or sometimes even when upgrading the compiler, this case seems to be qualitatively more severe: Library who _export_ an identifier called `forall` (which a few “real world” libraries do; HaTeX, sbv, what4 and many others) would find themselves unable to support a newer compiler without a _breaking_ change to their public API. I find that quite a big hammer, and I am not sure if we had precedent for that before, nor that we want to set that precedent. And it seems possible to have a milder migration strategy:  * Introduce -XForallInTerms * It’s implied by new extensions like -XRequiredTypeArguments * It becomes the default with next GHC20xx (but not with Haskell2021) * -XNoForallInTerm (and the kludges necessary to support that) stay  around for a while (NB: One can _use_ qualified names that happen to be keywords just fine; if a module M exports class, M.class works. So users of such old APIs can use HaTeX.forall even if they have opted into the new world.) I think we’ve exchanged the arguments, so now it remains a judgement call between more nudging, simpler GHC and a less complex set of extensions on the one hand vs. not forcing developers to break their library APIs in order to use new GHC versions. What do the others think? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From trupill at gmail.com Wed Oct 13 19:29:01 2021 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Wed, 13 Oct 2021 19:29:01 +0000 Subject: [ghc-steering-committee] Visible forall: 3-Year Anniversary In-Reply-To: <32f393dbc06c1fef586402293f99b272db80f1fe.camel@joachim-breitner.de> References: <05523B37-3DA0-4FF3-9587-79BDA6CEBCF3@gmail.com> <32f393dbc06c1fef586402293f99b272db80f1fe.camel@joachim-breitner.de> Message-ID: Hi, As a general rule, I would prefer *not* introducing breaking changes. People already complain how much breakage is in the Haskell ecosystem in general, and we should try not to be part of the problem too. Alejandro El 13 oct 2021 13:16:39, Joachim Breitner escribió: > Hi, > > thanks for pushing us here again. Fundamentally in favor. > > For those of you who are not following Github, Vlad and I are > disagreeing over how breaking the change can be. The proposal as it > stands makes forall a keyword in terms – irrespective of any extensions > that are on. > > Vlad argues that this is good: Code that uses forall as an identifier > should change that as soon as possible. Also, it simplifies the > implementation of the lexer and parser if the keywordhood of `forall` > doesn't depend on extensions. > > I argue that this is too inconsiderate towards our users. While I am > generally not hesitant to require _code changes_, possibly even with > CPP, when people enable new extensions, or sometimes even when > upgrading the compiler, this case seems to be qualitatively more > severe: Library who _export_ an identifier called `forall` (which a few > “real world” libraries do; HaTeX, sbv, what4 and many others) would > find themselves unable to support a newer compiler without a _breaking_ > change to their public API. I find that quite a big hammer, and I am > not sure if we had precedent for that before, nor that we want to set > that precedent. > > And it seems possible to have a milder migration strategy: > * Introduce -XForallInTerms > * It’s implied by new extensions like -XRequiredTypeArguments > * It becomes the default with next GHC20xx (but not with Haskell2021) > * -XNoForallInTerm (and the kludges necessary to support that) stay > around for a while > (NB: One can _use_ qualified names that happen to be keywords just > fine; if a module M exports class, M.class works. So users of such old > APIs can use HaTeX.forall even if they have opted into the new world.) > > I think we’ve exchanged the arguments, so now it remains a judgement > call between more nudging, simpler GHC and a less complex set of > extensions on the one hand vs. not forcing developers to break their > library APIs in order to use new GHC versions. > > What do the others think? > > 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 eric at seidel.io Thu Oct 14 01:05:16 2021 From: eric at seidel.io (Eric Seidel) Date: Wed, 13 Oct 2021 21:05:16 -0400 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> <010f017ae3c9e2b2-5118dc4d-7d82-4b69-bbef-4d3c2e3b2e01-000000@us-east-2.amazonses.com> Message-ID: <44e4bc06-4a03-4ce2-99f9-0eea91da3b36@www.fastmail.com> Sorry, I've been meaning to give this one the proper attention it deserves, but have failed to carve out time for it. I will make sure to find time this weekend! On Thu, Oct 7, 2021, at 03:52, Spiwack, Arnaud wrote: > Dear all, > > First sorry I'm a bit late on this, life got in the way. > > I've got opinions from both Simons, Tom, and Alejandro. Eric, Joachim, > Vitaly, Vlad what do you think about all this? > > --- > > If I were to summarise the discussion as I understand it, the major > point of discussion is the difference between local modules (which are > pure name-spacing entities) and global/top-level modules (which are > compilation units, hence can appear in import statements for dependency > management). Simon PJ has argued (in an off-band conversation with > Richard and I) to embrace the difference more, though in many places in > the proposal, these two kind of modules are used the same way, hence > deserving the common name of “module”. Simon Marlow is worried that the > lack of distinction between global module addressing and local module > addressing in `A.B.C.x` can be confusing (is `A.B` a global module, or > is `A` the global module and `B.C` the local module?). > > (I'd personally argue, regarding this latter point, that it doesn't > matter. By the time we are able to name `A.B.C.x` in a file, global > modules may have been renamed, so we have changed a name representing a > compilation unit into a namespace, which may or may not be identical. > The proposal don't treat the two situations differently at all) > > Another point of discussion which hasn't appeared on this list but has > been raised in the Github thread, is that the current proposal goes to > great length to make exporting `module M` more or less compatible with > the current behaviour giving it a very different semantic to exporting > `module qualified M` (these are currently items 4.iv, 4.v, and 4.vi in > the specification section of the proposal). Note that is not fully > backwards compatible and even with existing module can export more > stuff. The question is whether it is worth trying to match the existing > behaviour of `module M`, or whether a simpler notion which is in line > with the behaviour of `module qualified M` would be preferable. > > Over to you :-) > > /Arnaud > > On Tue, Jul 27, 2021 at 6:01 PM Simon Marlow wrote: >> 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 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 From eric at seidel.io Sat Oct 16 18:21:54 2021 From: eric at seidel.io (Eric Seidel) Date: Sat, 16 Oct 2021 14:21:54 -0400 Subject: [ghc-steering-committee] #283: Local modules (again), recommendation: accept In-Reply-To: <44e4bc06-4a03-4ce2-99f9-0eea91da3b36@www.fastmail.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> <44e4bc06-4a03-4ce2-99f9-0eea91da3b36@www.fastmail.com> Message-ID: I've read through the module and left some technical questions and comments on GitHub. Overall, I'm largely in favor of the proposal, but I think extension 3 (local modules for datatype) is a must. Without it I would be much more ambivalent about the proposal. One concern I have, that I raised on GitHub but will repeat here, is about the implicit export of unqualified names from local modules. It seems truly bizarre to me that we'd accept the following program. ``` module Top where y = x module Inner where x = 5 ``` Am I the only one who finds this strange and counter-intuitive? Eric On Wed, Oct 13, 2021, at 21:05, Eric Seidel wrote: > Sorry, I've been meaning to give this one the proper attention it > deserves, but have failed to carve out time for it. > > I will make sure to find time this weekend! > > On Thu, Oct 7, 2021, at 03:52, Spiwack, Arnaud wrote: >> Dear all, >> >> First sorry I'm a bit late on this, life got in the way. >> >> I've got opinions from both Simons, Tom, and Alejandro. Eric, Joachim, >> Vitaly, Vlad what do you think about all this? >> >> --- >> >> If I were to summarise the discussion as I understand it, the major >> point of discussion is the difference between local modules (which are >> pure name-spacing entities) and global/top-level modules (which are >> compilation units, hence can appear in import statements for dependency >> management). Simon PJ has argued (in an off-band conversation with >> Richard and I) to embrace the difference more, though in many places in >> the proposal, these two kind of modules are used the same way, hence >> deserving the common name of “module”. Simon Marlow is worried that the >> lack of distinction between global module addressing and local module >> addressing in `A.B.C.x` can be confusing (is `A.B` a global module, or >> is `A` the global module and `B.C` the local module?). >> >> (I'd personally argue, regarding this latter point, that it doesn't >> matter. By the time we are able to name `A.B.C.x` in a file, global >> modules may have been renamed, so we have changed a name representing a >> compilation unit into a namespace, which may or may not be identical. >> The proposal don't treat the two situations differently at all) >> >> Another point of discussion which hasn't appeared on this list but has >> been raised in the Github thread, is that the current proposal goes to >> great length to make exporting `module M` more or less compatible with >> the current behaviour giving it a very different semantic to exporting >> `module qualified M` (these are currently items 4.iv, 4.v, and 4.vi in >> the specification section of the proposal). Note that is not fully >> backwards compatible and even with existing module can export more >> stuff. The question is whether it is worth trying to match the existing >> behaviour of `module M`, or whether a simpler notion which is in line >> with the behaviour of `module qualified M` would be preferable. >> >> Over to you :-) >> >> /Arnaud >> >> On Tue, Jul 27, 2021 at 6:01 PM Simon Marlow wrote: >>> 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 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 From mail at joachim-breitner.de Sat Oct 16 21:06:12 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 16 Oct 2021 23:06:12 +0200 Subject: [ghc-steering-committee] Please review #433: the Unsatisfiable constraint, Shepherd: Tom Message-ID: Dear Committee, this is your secretary speaking: Unsatisfiable has been proposed by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/433 https://github.com/adamgundry/ghc-proposals/blob/unsatisfiable/proposals/0000-unsatisfiable.rst I propose Tom Harding as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From eric at seidel.io Tue Oct 19 00:09:31 2021 From: eric at seidel.io (Eric Seidel) Date: Mon, 18 Oct 2021 20:09:31 -0400 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> <010f017ae3c9e2b2-5118dc4d-7d82-4b69-bbef-4d3c2e3b2e01-000000@us-east-2.amazonses.com> <44e4bc06-4a03-4ce2-99f9-0eea91da3b36@www.fastmail.com> Message-ID: <44055e05-3a83-40d3-9e73-95785839394e@www.fastmail.com> On Sat, Oct 16, 2021, at 14:21, Eric Seidel wrote: > One concern I have, that I raised on GitHub but will repeat here, is > about the implicit export of unqualified names from local modules. It > seems truly bizarre to me that we'd accept the following program. > > ``` > module Top where > y = x > module Inner where > x = 5 > ``` > > Am I the only one who finds this strange and counter-intuitive? For those not following GitHub as closely, I think Richard has convinced me that this is the most consistent behavior. https://github.com/ghc-proposals/ghc-proposals/pull/283#discussion_r730293027 From rae at richarde.dev Tue Oct 19 21:19:48 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 19 Oct 2021 21:19:48 +0000 Subject: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept Message-ID: <010f017c9a6cb57b-e38b9e0a-f446-4435-8cb8-1cbf39b4861d-000000@us-east-2.amazonses.com> Hi all, I am the shepherd for proposal #425, https://github.com/ghc-proposals/ghc-proposals/pull/425, proposing to add invisible binders in type declarations. The main payload of the proposal is to allow definitions like > data Proxy @k (a :: k) = Proxy instead of today's > data Proxy (a :: k) = Proxy which has no explicit binding site for k. This new syntax solves a number of smallish syntax conundra, as very well outlined in the proposal. In addition, the proposal includes two small unrelated tweaks to the syntax of type family instances; these are points (6) and (7) in the proposal. Both changes will break some obscure (but still realistic, knowing Haskell) programs, but both fixes are backward compatible. --- I recommend acceptance. The proposal is motivated nicely (do check out the examples) and solves a real problem. The new syntax fits in with other similar features. The small cleanups to existing syntax will lead to better error messages. The one drawback, as I see it, is that this proposal includes point (5), which is a breaking change to the way type synonyms work. Right now, we can say > type P = (Proxy :: k -> Type) and GHC will infer P :: forall k. k -> Type. Under this proposal, you would have to write > type P @k = (Proxy :: k -> Type) bringing k into scope explicitly. The fix is not backward compatible, and so I think this proposal should come with a migration strategy, where we warn about the former version for some releases before banning it. (Continuing to support it is possible, but it's very awkward to have a variable mentioned only in a synonym's right-hand side.) Sorry for the delay in producing this recommendation! Richard From arnaud.spiwack at tweag.io Thu Oct 21 07:03:29 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Thu, 21 Oct 2021 09:03:29 +0200 Subject: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept In-Reply-To: <010f017c9a6cb57b-e38b9e0a-f446-4435-8cb8-1cbf39b4861d-000000@us-east-2.amazonses.com> References: <010f017c9a6cb57b-e38b9e0a-f446-4435-8cb8-1cbf39b4861d-000000@us-east-2.amazonses.com> Message-ID: I'm generally in favour. But I'm not convinced that the secondary changes (points 4–7) are worth it. They are certainly better place than we are today, but are they worth breaking existing code for? Point 5–7 can probably be replaced by warnings. I don't know about 4. On Tue, Oct 19, 2021 at 11:20 PM Richard Eisenberg wrote: > Hi all, > > I am the shepherd for proposal #425, > https://github.com/ghc-proposals/ghc-proposals/pull/425, proposing to add > invisible binders in type declarations. > > The main payload of the proposal is to allow definitions like > > > data Proxy @k (a :: k) = Proxy > > instead of today's > > > data Proxy (a :: k) = Proxy > > which has no explicit binding site for k. > > This new syntax solves a number of smallish syntax conundra, as very well > outlined in the proposal. > > In addition, the proposal includes two small unrelated tweaks to the > syntax of type family instances; these are points (6) and (7) in the > proposal. Both changes will break some obscure (but still realistic, > knowing Haskell) programs, but both fixes are backward compatible. > > --- > > I recommend acceptance. The proposal is motivated nicely (do check out the > examples) and solves a real problem. The new syntax fits in with other > similar features. The small cleanups to existing syntax will lead to better > error messages. > > The one drawback, as I see it, is that this proposal includes point (5), > which is a breaking change to the way type synonyms work. Right now, we can > say > > > type P = (Proxy :: k -> Type) > > and GHC will infer P :: forall k. k -> Type. Under this proposal, you > would have to write > > > type P @k = (Proxy :: k -> Type) > > bringing k into scope explicitly. The fix is not backward compatible, and > so I think this proposal should come with a migration strategy, where we > warn about the former version for some releases before banning it. > (Continuing to support it is possible, but it's very awkward to have a > variable mentioned only in a synonym's right-hand side.) > > Sorry for the delay in producing this recommendation! > 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 Fri Oct 22 11:00:04 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 22 Oct 2021 11:00:04 +0000 Subject: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept In-Reply-To: References: <010f017c9a6cb57b-e38b9e0a-f446-4435-8cb8-1cbf39b4861d-000000@us-east-2.amazonses.com> Message-ID: I'm in strong support. This tidies up the design nicely. I am particularly keen on 5,6,7; indeed I wrote a whole proposal about it, which Vlad has #included here https://github.com/ghc-proposals/ghc-proposals/pull/386 Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) From: ghc-steering-committee On Behalf Of Spiwack, Arnaud Sent: 21 October 2021 08:03 To: Richard Eisenberg Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept I'm generally in favour. But I'm not convinced that the secondary changes (points 4-7) are worth it. They are certainly better place than we are today, but are they worth breaking existing code for? Point 5-7 can probably be replaced by warnings. I don't know about 4. On Tue, Oct 19, 2021 at 11:20 PM Richard Eisenberg > wrote: Hi all, I am the shepherd for proposal #425, https://github.com/ghc-proposals/ghc-proposals/pull/425, proposing to add invisible binders in type declarations. The main payload of the proposal is to allow definitions like > data Proxy @k (a :: k) = Proxy instead of today's > data Proxy (a :: k) = Proxy which has no explicit binding site for k. This new syntax solves a number of smallish syntax conundra, as very well outlined in the proposal. In addition, the proposal includes two small unrelated tweaks to the syntax of type family instances; these are points (6) and (7) in the proposal. Both changes will break some obscure (but still realistic, knowing Haskell) programs, but both fixes are backward compatible. --- I recommend acceptance. The proposal is motivated nicely (do check out the examples) and solves a real problem. The new syntax fits in with other similar features. The small cleanups to existing syntax will lead to better error messages. The one drawback, as I see it, is that this proposal includes point (5), which is a breaking change to the way type synonyms work. Right now, we can say > type P = (Proxy :: k -> Type) and GHC will infer P :: forall k. k -> Type. Under this proposal, you would have to write > type P @k = (Proxy :: k -> Type) bringing k into scope explicitly. The fix is not backward compatible, and so I think this proposal should come with a migration strategy, where we warn about the former version for some releases before banning it. (Continuing to support it is possible, but it's very awkward to have a variable mentioned only in a synonym's right-hand side.) Sorry for the delay in producing this recommendation! 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 arnaud.spiwack at tweag.io Mon Oct 25 07:24:19 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Mon, 25 Oct 2021 09:24:19 +0200 Subject: [ghc-steering-committee] #425: invisible binders in type declarations; rec: accept In-Reply-To: References: <010f017c9a6cb57b-e38b9e0a-f446-4435-8cb8-1cbf39b4861d-000000@us-east-2.amazonses.com> Message-ID: My weak objections are no match for Simon's strong keenness :-) . I should say that, egoistically, I'd also like 5,6,7 to happen. I was only expressing concerns about the price. On Fri, Oct 22, 2021 at 1:00 PM Simon Peyton Jones wrote: > I’m in strong support. This tidies up the design nicely. > > > > I am particularly keen on 5,6,7; indeed I wrote a whole proposal about it, > which Vlad has #included here > > > > https://github.com/ghc-proposals/ghc-proposals/pull/386 > > > > Simon > > > > PS: I am leaving Microsoft at the end of November 2021, at which point > simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com > instead. (For now, it just forwards to simonpj at microsoft.com.) > > > > *From:* ghc-steering-committee > *On Behalf Of *Spiwack, Arnaud > *Sent:* 21 October 2021 08:03 > *To:* Richard Eisenberg > *Cc:* ghc-steering-committee > *Subject:* Re: [ghc-steering-committee] #425: invisible binders in type > declarations; rec: accept > > > > I'm generally in favour. But I'm not convinced that the secondary changes > (points 4–7) are worth it. They are certainly better place than we are > today, but are they worth breaking existing code for? Point 5–7 can > probably be replaced by warnings. I don't know about 4. > > > > On Tue, Oct 19, 2021 at 11:20 PM Richard Eisenberg > wrote: > > Hi all, > > I am the shepherd for proposal #425, > https://github.com/ghc-proposals/ghc-proposals/pull/425 > , > proposing to add invisible binders in type declarations. > > The main payload of the proposal is to allow definitions like > > > data Proxy @k (a :: k) = Proxy > > instead of today's > > > data Proxy (a :: k) = Proxy > > which has no explicit binding site for k. > > This new syntax solves a number of smallish syntax conundra, as very well > outlined in the proposal. > > In addition, the proposal includes two small unrelated tweaks to the > syntax of type family instances; these are points (6) and (7) in the > proposal. Both changes will break some obscure (but still realistic, > knowing Haskell) programs, but both fixes are backward compatible. > > --- > > I recommend acceptance. The proposal is motivated nicely (do check out the > examples) and solves a real problem. The new syntax fits in with other > similar features. The small cleanups to existing syntax will lead to better > error messages. > > The one drawback, as I see it, is that this proposal includes point (5), > which is a breaking change to the way type synonyms work. Right now, we can > say > > > type P = (Proxy :: k -> Type) > > and GHC will infer P :: forall k. k -> Type. Under this proposal, you > would have to write > > > type P @k = (Proxy :: k -> Type) > > bringing k into scope explicitly. The fix is not backward compatible, and > so I think this proposal should come with a migration strategy, where we > warn about the former version for some releases before banning it. > (Continuing to support it is possible, but it's very awkward to have a > variable mentioned only in a synonym's right-hand side.) > > Sorry for the delay in producing this recommendation! > 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 arnaud.spiwack at tweag.io Wed Oct 27 08:20:09 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 27 Oct 2021 10:20:09 +0200 Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept In-Reply-To: <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> References: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> Message-ID: I've been struggling to have an opinion on this PR. I'm very sympathetic to the goal of the proposal (and this latest rendition of the proposal is a really good document). There are a lot of inconvenient side effects and corner cases (but, to be fair, these are not special to this proposal: they are inherent to the dependent types plan). But I'm fairly convinced that this is the best possible approach, or close enough. So yes, I don't really feel strongly about it. But on balance, I think that I'm in favour. On Tue, Oct 12, 2021 at 9:05 PM Richard Eisenberg wrote: > This proposal has been revised for clarity, yet much of the payload is the > same. I've just made a few small suggestions, but I believe we can > deliberate here in parallel. > > To recap: > > Proposal PR: https://github.com/ghc-proposals/ghc-proposals/pull/281 > Proposal text: > https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst > > The text of the proposal is long and detailed, but do not be daunted: it > is simpler in practice than it appears. > > The main payload of the proposal is: Introduce a new extension > -XRequiredTypeArguments. With this extension enabled, the `forall ... ->` > syntax, currently in existence in kinds, is now available in types (of > ordinary functions). This means that function definitions and call sites > are sometimes required to write a type argument. The type argument is *not* > preceded by @ or any other syntactic marker. > > This is useful for defining what would otherwise be ambiguous types. > Example: > > sizeof :: forall a -> Sizeable a => Int > sizeof = ... > > intWidth = sizeof Int > > > There are further examples and motivation in the proposal. > > The rest of the proposal is simply about dealing with odd corner cases > that come up with the main payload. In particular, mixing types in with > terms with no syntactic signifier means that we must be careful about > parsing and namespaces. If a type argument is written in the syntax that is > shared between types and terms (including function application!) and uses > identifiers in scope in only one of the two namespaces, nothing unusual can > be observed. But, of course, there are corner cases. Here are some of the > salient details: > - Define type-syntax and term-syntax, where the choice of syntax is always > driven by syntactic markers, such as :: or @. See the dependent types > proposal > for > more details. Parsing and name-resolution are controlled by whether a > phrase is in type-syntax or term-syntax. For name resolution, if a lookup > fails in the first namespace (the term-level namespace in term-syntax or > the type-level namespace in type-syntax), we try the other namespace before > failing. > - One unfortunate consequence of this extra namespace looking is around > implicit quantification. If we have `a = 42` in scope and write `f :: a -> > a`, that `a` will *not* be implicitly quantified. Instead, the user will > get an error about the appearance of a term in a type -- but only if > -XRequiredTypeArguments is on. This change affects no current code, but it > does make the extension fork-like, in that enabling the new extension is > not conservative. > - Because term- vs type-syntax is controlled by syntax, a required type > argument is in *term*-syntax and gets name-resolved *as a term*. In the > absence of punning, this works out fine, but it is possible that a punned > identifier will cause confusion. The proposal allows users to write `type` > to signify a switch to type-syntax. > - The proposal also includes a way to avoid punning for the built-in types > with privileged syntax: lists and tuples. This method allows users to > specify -XNoListTupleTypeSyntax to disable the list and tuple syntax in > types (but still allows it for terms). The proposal also suggests exporting > type List = [] from Data.List and other synonyms for tuples from Data.Tuple. > > --------------- > > I recommend acceptance. When doing type-level programming, the lack of > this feature is strange, leading to ambiguous types and easy-to-forget > arguments and easy-to-make type errors. The design space here is difficult, > but this proposal is very much in keeping with the design sketch of our > recently-accepted #378, in particular its section on this point > . > I believe the design described here is both backward compatible with what > we have today (users who do not use this feature will not notice a > difference) and forward compatible with a cohesive design for dependent > types. > > The "unfortunate consequence" above is, well, unfortunate, but I think it > is unavoidable in the context of #378 -- and it will not bite if the user > avoids puns. > > It would be great to bring this long-running proposal to a conclusion, so > I'd love to hear your opinions in the next two weeks. > > Thanks! > Richard > > > On Jul 19, 2021, at 3:22 PM, Richard Eisenberg wrote: > > 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 > _______________________________________________ > 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 i.am.tom.harding at gmail.com Wed Oct 27 09:01:05 2021 From: i.am.tom.harding at gmail.com (Tom Harding) Date: Wed, 27 Oct 2021 10:01:05 +0100 Subject: [ghc-steering-committee] #433: the Unsatisfiable constraint; recommendation: accept Message-ID: <0651BACE-875A-4D66-AEAD-0BC7EBE065A4@gmail.com> Hi all, Firstly, apologies for the radio silence - I’ve apparently been having some undiscovered email trouble (perhaps even since joining the committee), and so I’m now going to be using my usual, and hopefully far more reliable, email address. With that said, I’d like to recommend proposal #433 for acceptance. The proposal does a good job of outlining the difference between this and the current TypeError mechanism, and I think the case is well justified. Certainly, the ability to bypass fundep checks in error case “instances” immediately brought to mind a handful of places in my own libraries that could benefit from this check. I think the thread already contains a lot of committee activity, but I welcome any further comments! Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Oct 27 09:05:49 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 27 Oct 2021 09:05:49 +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> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> Message-ID: There are a lot of inconvenient side effects and corner cases Arnaud, could you enumerate them? Even if (as I strongly hope) we accept this proposal, it's good to have a concrete list of things to bear in mind. I for one do not have such list in my head. One principle that the proposal espouses (but perhaps does not call out explicitly) is that it should be possible to write an explicit binder for every in-scope variable. So instead of data T (a :: k -> k) = ... I want to write data T @k (a :: k -> k) = ... with an explicit binder for k. So I see the proposal as removing an ad-hoc wart in the language. But I may be blind to the "inconvenient side effects and corner cases" and I'd welcome a list of such cases. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) From: ghc-steering-committee On Behalf Of Spiwack, Arnaud Sent: 27 October 2021 09:20 To: Richard Eisenberg Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept I've been struggling to have an opinion on this PR. I'm very sympathetic to the goal of the proposal (and this latest rendition of the proposal is a really good document). There are a lot of inconvenient side effects and corner cases (but, to be fair, these are not special to this proposal: they are inherent to the dependent types plan). But I'm fairly convinced that this is the best possible approach, or close enough. So yes, I don't really feel strongly about it. But on balance, I think that I'm in favour. On Tue, Oct 12, 2021 at 9:05 PM Richard Eisenberg > wrote: This proposal has been revised for clarity, yet much of the payload is the same. I've just made a few small suggestions, but I believe we can deliberate here in parallel. To recap: Proposal PR: https://github.com/ghc-proposals/ghc-proposals/pull/281 Proposal text: https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst The text of the proposal is long and detailed, but do not be daunted: it is simpler in practice than it appears. The main payload of the proposal is: Introduce a new extension -XRequiredTypeArguments. With this extension enabled, the `forall ... ->` syntax, currently in existence in kinds, is now available in types (of ordinary functions). This means that function definitions and call sites are sometimes required to write a type argument. The type argument is *not* preceded by @ or any other syntactic marker. This is useful for defining what would otherwise be ambiguous types. Example: sizeof :: forall a -> Sizeable a => Int sizeof = ... intWidth = sizeof Int There are further examples and motivation in the proposal. The rest of the proposal is simply about dealing with odd corner cases that come up with the main payload. In particular, mixing types in with terms with no syntactic signifier means that we must be careful about parsing and namespaces. If a type argument is written in the syntax that is shared between types and terms (including function application!) and uses identifiers in scope in only one of the two namespaces, nothing unusual can be observed. But, of course, there are corner cases. Here are some of the salient details: - Define type-syntax and term-syntax, where the choice of syntax is always driven by syntactic markers, such as :: or @. See the dependent types proposal for more details. Parsing and name-resolution are controlled by whether a phrase is in type-syntax or term-syntax. For name resolution, if a lookup fails in the first namespace (the term-level namespace in term-syntax or the type-level namespace in type-syntax), we try the other namespace before failing. - One unfortunate consequence of this extra namespace looking is around implicit quantification. If we have `a = 42` in scope and write `f :: a -> a`, that `a` will not be implicitly quantified. Instead, the user will get an error about the appearance of a term in a type -- but only if -XRequiredTypeArguments is on. This change affects no current code, but it does make the extension fork-like, in that enabling the new extension is not conservative. - Because term- vs type-syntax is controlled by syntax, a required type argument is in *term*-syntax and gets name-resolved *as a term*. In the absence of punning, this works out fine, but it is possible that a punned identifier will cause confusion. The proposal allows users to write `type` to signify a switch to type-syntax. - The proposal also includes a way to avoid punning for the built-in types with privileged syntax: lists and tuples. This method allows users to specify -XNoListTupleTypeSyntax to disable the list and tuple syntax in types (but still allows it for terms). The proposal also suggests exporting type List = [] from Data.List and other synonyms for tuples from Data.Tuple. --------------- I recommend acceptance. When doing type-level programming, the lack of this feature is strange, leading to ambiguous types and easy-to-forget arguments and easy-to-make type errors. The design space here is difficult, but this proposal is very much in keeping with the design sketch of our recently-accepted #378, in particular its section on this point. I believe the design described here is both backward compatible with what we have today (users who do not use this feature will not notice a difference) and forward compatible with a cohesive design for dependent types. The "unfortunate consequence" above is, well, unfortunate, but I think it is unavoidable in the context of #378 -- and it will not bite if the user avoids puns. It would be great to bring this long-running proposal to a conclusion, so I'd love to hear your opinions in the next two weeks. Thanks! Richard On Jul 19, 2021, at 3:22 PM, Richard Eisenberg > wrote: 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 _______________________________________________ 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 vlad.z.4096 at gmail.com Wed Oct 27 09:09:32 2021 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Wed, 27 Oct 2021 12:09:32 +0300 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> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> Message-ID: <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> Simon, perhaps you’re thinking of another proposal that is currently under committee’s consideration? Arnaud was commenting on #281, and you seem to be talking about #425. - Vlad > On 27 Oct 2021, at 12:05, Simon Peyton Jones via ghc-steering-committee wrote: > > There are a lot of inconvenient side effects and corner cases > > Arnaud, could you enumerate them? Even if (as I strongly hope) we accept this proposal, it’s good to have a concrete list of things to bear in mind. I for one do not have such list in my head. > > One principle that the proposal espouses (but perhaps does not call out explicitly) is that it should be possible to write an explicit binder for every in-scope variable. So instead of > data T (a :: k -> k) = … > I want to write > data T @k (a :: k -> k) = … > with an explicit binder for k. > > So I see the proposal as removing an ad-hoc wart in the language. But I may be blind to the “inconvenient side effects and corner cases” and I’d welcome a list of such cases. > > Simon > > > PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Usesimon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) > > From: ghc-steering-committee On Behalf Of Spiwack, Arnaud > Sent: 27 October 2021 09:20 > To: Richard Eisenberg > Cc: ghc-steering-committee > Subject: Re: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept > > I've been struggling to have an opinion on this PR. I'm very sympathetic to the goal of the proposal (and this latest rendition of the proposal is a really good document). There are a lot of inconvenient side effects and corner cases (but, to be fair, these are not special to this proposal: they are inherent to the dependent types plan). But I'm fairly convinced that this is the best possible approach, or close enough. > > > > So yes, I don't really feel strongly about it. But on balance, I think that I'm in favour. From simonpj at microsoft.com Wed Oct 27 09:29:16 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 27 Oct 2021 09:29:16 +0000 Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept In-Reply-To: <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> References: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> Message-ID: I was indeed confused! Apologies. But my main point remains: enumerating a list of inconvenient side effects and corner cases would be a great service. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) | -----Original Message----- | From: Vladislav Zavialov (int-index) | Sent: 27 October 2021 10:10 | To: Simon Peyton Jones | Cc: Spiwack, Arnaud ; Richard Eisenberg | ; ghc-steering-committee | Subject: Re: [ghc-steering-committee] Proposal #281: Visible "forall" | in terms; rec: accept | | Simon, perhaps you’re thinking of another proposal that is currently | under committee’s consideration? | | Arnaud was commenting on #281, and you seem to be talking about #425. | | - Vlad | | > On 27 Oct 2021, at 12:05, Simon Peyton Jones via ghc-steering- | committee wrote: | > | > There are a lot of inconvenient side effects and corner cases | > | > Arnaud, could you enumerate them? Even if (as I strongly hope) we | accept this proposal, it’s good to have a concrete list of things to | bear in mind. I for one do not have such list in my head. | > | > One principle that the proposal espouses (but perhaps does not call | out explicitly) is that it should be possible to write an explicit | binder for every in-scope variable. So instead of | > data T (a :: k -> k) = … I want to write | > data T @k (a :: k -> k) = … with an explicit binder | > for k. | > | > So I see the proposal as removing an ad-hoc wart in the language. | But I may be blind to the “inconvenient side effects and corner cases” | and I’d welcome a list of such cases. | > | > Simon | > | > | > PS: I am leaving Microsoft at the end of November 2021, at which | point | > simonpj at microsoft.com will cease to work. | > Usesimon.peytonjones at gmail.com instead. (For now, it just forwards | to | > simonpj at microsoft.com.) | > | > From: ghc-steering-committee | > On Behalf Of Spiwack, | > Arnaud | > Sent: 27 October 2021 09:20 | > To: Richard Eisenberg | > Cc: ghc-steering-committee | > Subject: Re: [ghc-steering-committee] Proposal #281: Visible | "forall" | > in terms; rec: accept | > | > I've been struggling to have an opinion on this PR. I'm very | sympathetic to the goal of the proposal (and this latest rendition of | the proposal is a really good document). There are a lot of | inconvenient side effects and corner cases (but, to be fair, these are | not special to this proposal: they are inherent to the dependent types | plan). But I'm fairly convinced that this is the best possible | approach, or close enough. | > | > | > | > So yes, I don't really feel strongly about it. But on balance, I | think that I'm in favour. From arnaud.spiwack at tweag.io Wed Oct 27 09:30:28 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 27 Oct 2021 11:30:28 +0200 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> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> Message-ID: I think that the proposal makes a great job at listing the issues. It's quite transparent about this, I'm not sure what I could add. On Wed, Oct 27, 2021 at 11:29 AM Simon Peyton Jones wrote: > I was indeed confused! Apologies. > > But my main point remains: enumerating a list of inconvenient side effects > and corner cases would be a great service. > > Simon > > PS: I am leaving Microsoft at the end of November 2021, at which point > simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com > instead. (For now, it just forwards to simonpj at microsoft.com.) > > | -----Original Message----- > | From: Vladislav Zavialov (int-index) > | Sent: 27 October 2021 10:10 > | To: Simon Peyton Jones > | Cc: Spiwack, Arnaud ; Richard Eisenberg > | ; ghc-steering-committee | committee at haskell.org> > | Subject: Re: [ghc-steering-committee] Proposal #281: Visible "forall" > | in terms; rec: accept > | > | Simon, perhaps you’re thinking of another proposal that is currently > | under committee’s consideration? > | > | Arnaud was commenting on #281, and you seem to be talking about #425. > | > | - Vlad > | > | > On 27 Oct 2021, at 12:05, Simon Peyton Jones via ghc-steering- > | committee wrote: > | > > | > There are a lot of inconvenient side effects and corner cases > | > > | > Arnaud, could you enumerate them? Even if (as I strongly hope) we > | accept this proposal, it’s good to have a concrete list of things to > | bear in mind. I for one do not have such list in my head. > | > > | > One principle that the proposal espouses (but perhaps does not call > | out explicitly) is that it should be possible to write an explicit > | binder for every in-scope variable. So instead of > | > data T (a :: k -> k) = … I want to write > | > data T @k (a :: k -> k) = … with an explicit binder > | > for k. > | > > | > So I see the proposal as removing an ad-hoc wart in the language. > | But I may be blind to the “inconvenient side effects and corner cases” > | and I’d welcome a list of such cases. > | > > | > Simon > | > > | > > | > PS: I am leaving Microsoft at the end of November 2021, at which > | point > | > simonpj at microsoft.com will cease to work. > | > Usesimon.peytonjones at gmail.com instead. (For now, it just forwards > | to > | > simonpj at microsoft.com.) > | > > | > From: ghc-steering-committee > | > On Behalf Of Spiwack, > | > Arnaud > | > Sent: 27 October 2021 09:20 > | > To: Richard Eisenberg > | > Cc: ghc-steering-committee > | > Subject: Re: [ghc-steering-committee] Proposal #281: Visible > | "forall" > | > in terms; rec: accept > | > > | > I've been struggling to have an opinion on this PR. I'm very > | sympathetic to the goal of the proposal (and this latest rendition of > | the proposal is a really good document). There are a lot of > | inconvenient side effects and corner cases (but, to be fair, these are > | not special to this proposal: they are inherent to the dependent types > | plan). But I'm fairly convinced that this is the best possible > | approach, or close enough. > | > > | > > | > > | > So yes, I don't really feel strongly about it. But on balance, I > | think that I'm in favour. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Oct 27 09:32:29 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 27 Oct 2021 11:32:29 +0200 Subject: [ghc-steering-committee] #433: the Unsatisfiable constraint; recommendation: accept In-Reply-To: <0651BACE-875A-4D66-AEAD-0BC7EBE065A4@gmail.com> References: <0651BACE-875A-4D66-AEAD-0BC7EBE065A4@gmail.com> Message-ID: I'm in favour. I have no opinion on the `Warning` type class. On Wed, Oct 27, 2021 at 11:01 AM Tom Harding wrote: > Hi all, > > Firstly, apologies for the radio silence - I’ve apparently been having > some undiscovered email trouble (perhaps even since joining the committee), > and so I’m now going to be using my usual, and hopefully far more reliable, > email address. > > With that said, I’d like to recommend proposal #433 > for acceptance. > The proposal does a good job of outlining the difference between this and > the current TypeError mechanism, and I think the case is well justified. > Certainly, the ability to bypass fundep checks in error case “instances” > immediately brought to mind a handful of places in my own libraries that > could benefit from this check. > > I think the thread already contains a lot of committee activity, but I > welcome any further comments! > > Thanks, > Tom > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed Oct 27 13:56:49 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 27 Oct 2021 13:56:49 +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> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> Message-ID: <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> It has been two weeks. I have heard no argument against this proposal, but Simon Marlow (in the springtime) expressed some puzzlement. Simon, what are you thinking about this now? With no further response, I will accept this proposal on Friday. Others are also very welcome to chime in! Thanks, all! Richard > On Oct 27, 2021, at 5:30 AM, Spiwack, Arnaud wrote: > > I think that the proposal makes a great job at listing the issues. It's quite transparent about this, I'm not sure what I could add. > > On Wed, Oct 27, 2021 at 11:29 AM Simon Peyton Jones > wrote: > I was indeed confused! Apologies. > > But my main point remains: enumerating a list of inconvenient side effects and corner cases would be a great service. > > Simon > > PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com .) > > | -----Original Message----- > | From: Vladislav Zavialov (int-index) > > | Sent: 27 October 2021 10:10 > | To: Simon Peyton Jones > > | Cc: Spiwack, Arnaud >; Richard Eisenberg > | >; ghc-steering-committee | committee at haskell.org > > | Subject: Re: [ghc-steering-committee] Proposal #281: Visible "forall" > | in terms; rec: accept > | > | Simon, perhaps you’re thinking of another proposal that is currently > | under committee’s consideration? > | > | Arnaud was commenting on #281, and you seem to be talking about #425. > | > | - Vlad > | > | > On 27 Oct 2021, at 12:05, Simon Peyton Jones via ghc-steering- > | committee > wrote: > | > > | > There are a lot of inconvenient side effects and corner cases > | > > | > Arnaud, could you enumerate them? Even if (as I strongly hope) we > | accept this proposal, it’s good to have a concrete list of things to > | bear in mind. I for one do not have such list in my head. > | > > | > One principle that the proposal espouses (but perhaps does not call > | out explicitly) is that it should be possible to write an explicit > | binder for every in-scope variable. So instead of > | > data T (a :: k -> k) = … I want to write > | > data T @k (a :: k -> k) = … with an explicit binder > | > for k. > | > > | > So I see the proposal as removing an ad-hoc wart in the language. > | But I may be blind to the “inconvenient side effects and corner cases” > | and I’d welcome a list of such cases. > | > > | > Simon > | > > | > > | > PS: I am leaving Microsoft at the end of November 2021, at which > | point > | > simonpj at microsoft.com will cease to work. > | > Usesimon.peytonjones at gmail.com instead. (For now, it just forwards > | to > | > simonpj at microsoft.com .) > | > > | > From: ghc-steering-committee > | > > On Behalf Of Spiwack, > | > Arnaud > | > Sent: 27 October 2021 09:20 > | > To: Richard Eisenberg > > | > Cc: ghc-steering-committee > > | > Subject: Re: [ghc-steering-committee] Proposal #281: Visible > | "forall" > | > in terms; rec: accept > | > > | > I've been struggling to have an opinion on this PR. I'm very > | sympathetic to the goal of the proposal (and this latest rendition of > | the proposal is a really good document). There are a lot of > | inconvenient side effects and corner cases (but, to be fair, these are > | not special to this proposal: they are inherent to the dependent types > | plan). But I'm fairly convinced that this is the best possible > | approach, or close enough. > | > > | > > | > > | > So yes, I don't really feel strongly about it. But on balance, I > | think that I'm in favour. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlad.z.4096 at gmail.com Wed Oct 27 14:33:36 2021 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Wed, 27 Oct 2021 17:33:36 +0300 Subject: [ghc-steering-committee] #433: the Unsatisfiable constraint; recommendation: accept In-Reply-To: <0651BACE-875A-4D66-AEAD-0BC7EBE065A4@gmail.com> References: <0651BACE-875A-4D66-AEAD-0BC7EBE065A4@gmail.com> Message-ID: <7520878C-E102-4542-995B-7545E6CC989A@gmail.com> I’m in favor of the proposal overall, but if we include the ‘Warning’ machinery, I’d like to see Richard’s suggestion about a (flag :: Symbol) parameter, so that users can enable and disable custom warnings. Also, I don’t understand why we need a separate ‘Unsatisfiable’ class when we could reuse ’TypeError’ instantiated at kind ‘Constraint’. Adam lists this option in the Alternatives, but I wish it had a more detailed explanation why this is not possible. Just think of the API we are going to end up with: * TypeError * Unsatisfiable * Warning How come ‘Warning’ is a constraint like ‘Unsatisfiable’ rather than like ’TypeError’? I agree that each piece here makes sense individually, but we should also consider a more holistic approach to API design. Reusing ’TypeError’ is certainly tempting. - Vlad > On 27 Oct 2021, at 12:01, Tom Harding wrote: > > Hi all, > > Firstly, apologies for the radio silence - I’ve apparently been having some undiscovered email trouble (perhaps even since joining the committee), and so I’m now going to be using my usual, and hopefully far more reliable, email address. > > With that said, I’d like to recommend proposal #433 for acceptance. The proposal does a good job of outlining the difference between this and the current TypeError mechanism, and I think the case is well justified. Certainly, the ability to bypass fundep checks in error case “instances” immediately brought to mind a handful of places in my own libraries that could benefit from this check. > > I think the thread already contains a lot of committee activity, but I welcome any further comments! > > Thanks, > Tom > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From lists at richarde.dev Wed Oct 27 18:42:58 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Wed, 27 Oct 2021 18:42:58 +0000 Subject: [ghc-steering-committee] #433: the Unsatisfiable constraint; recommendation: accept In-Reply-To: <7520878C-E102-4542-995B-7545E6CC989A@gmail.com> References: <0651BACE-875A-4D66-AEAD-0BC7EBE065A4@gmail.com> <7520878C-E102-4542-995B-7545E6CC989A@gmail.com> Message-ID: <010f017cc31001d7-ca785e5e-4021-4924-92aa-a0d8d6f5fed8-000000@us-east-2.amazonses.com> I think this is a good point, Vlad, but I think the semantics of Unsatisfiable and TypeError @Constraint are actually different. Specifically, suppose we have an unsolved [W] (F a0 ~ Dict (Unsatisfiable "blah")) constraint. That will report a "failure to unify" error, muttering about an ambiguous a0, most likely. On the other hand [W] (F a0 ~ Dict (TypeError @Constraint "blah")) will spit out "blah". I suppose we could say, by fiat, that `TypeError @Constraint` has the semantics this proposal gives to Unsatisfiable, and then `TypeError @anything_other_than_constraint` has its usual (underspecified) semantics. This would a little unstable at the edges (when we might or might not have simplified a variable to Constraint), but that's OK, because the instability is only around the wording of an error message. I still favor having a separate Unsatisfiable. Use TypeError when you are writing a partial type family that looks total and need to fill in the missing case. Use Unsatisfiable when you have a constraint. Writing all this makes me wonder, though, about the relationship between Unsatisfiable and Warning. I will post on GitHub. Richard > On Oct 27, 2021, at 10:33 AM, Vladislav Zavialov (int-index) wrote: > > I’m in favor of the proposal overall, but if we include the ‘Warning’ machinery, I’d like to see Richard’s suggestion about a (flag :: Symbol) parameter, so that users can enable and disable custom warnings. > > Also, I don’t understand why we need a separate ‘Unsatisfiable’ class when we could reuse ’TypeError’ instantiated at kind ‘Constraint’. Adam lists this option in the Alternatives, but I wish it had a more detailed explanation why this is not possible. Just think of the API we are going to end up with: > > * TypeError > * Unsatisfiable > * Warning > > How come ‘Warning’ is a constraint like ‘Unsatisfiable’ rather than like ’TypeError’? I agree that each piece here makes sense individually, but we should also consider a more holistic approach to API design. Reusing ’TypeError’ is certainly tempting. > > - Vlad > >> On 27 Oct 2021, at 12:01, Tom Harding wrote: >> >> Hi all, >> >> Firstly, apologies for the radio silence - I’ve apparently been having some undiscovered email trouble (perhaps even since joining the committee), and so I’m now going to be using my usual, and hopefully far more reliable, email address. >> >> With that said, I’d like to recommend proposal #433 for acceptance. The proposal does a good job of outlining the difference between this and the current TypeError mechanism, and I think the case is well justified. Certainly, the ability to bypass fundep checks in error case “instances” immediately brought to mind a handful of places in my own libraries that could benefit from this check. >> >> I think the thread already contains a lot of committee activity, but I welcome any further comments! >> >> Thanks, >> Tom >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Fri Oct 29 01:16:14 2021 From: eric at seidel.io (Eric Seidel) Date: Thu, 28 Oct 2021 21:16:14 -0400 Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept In-Reply-To: <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> References: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> Message-ID: <8793cd72-2406-4f1c-9095-3dedd1ceb14b@www.fastmail.com> I would still prefer alternative 5 (using @ as the type herald). I really dislike that we would now have three ways to specify a type argument: 1. f @Int -- traditional, invisible forall 2. f Int -- visible forall, Int is unambiguous 3. f (type Int) -- visible forall, Int is ambiguous Ideally I would have single syntax for specifying type arguments, which was historically (1). I know that many people would like to unify the term and type syntaxes, so I'm ok with (2) as well even though the T2T algorithm seemed quite involved. But adding (3) really feels excessive. But I believe I'm a small minority in this opinion, so I don't want to stand in the way of a very useful feature. On Wed, Oct 27, 2021, at 09:56, Richard Eisenberg wrote: > It has been two weeks. I have heard no argument against this proposal, > but Simon Marlow (in the springtime) expressed some puzzlement. Simon, > what are you thinking about this now? With no further response, I will > accept this proposal on Friday. > > Others are also very welcome to chime in! > > Thanks, all! > Richard > >> On Oct 27, 2021, at 5:30 AM, Spiwack, Arnaud wrote: >> >> I think that the proposal makes a great job at listing the issues. It's quite transparent about this, I'm not sure what I could add. >> >> On Wed, Oct 27, 2021 at 11:29 AM Simon Peyton Jones wrote: >>> I was indeed confused! Apologies. >>> >>> But my main point remains: enumerating a list of inconvenient side effects and corner cases would be a great service. >>> >>> Simon >>> >>> PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) >>> >>> | -----Original Message----- >>> | From: Vladislav Zavialov (int-index) >>> | Sent: 27 October 2021 10:10 >>> | To: Simon Peyton Jones >>> | Cc: Spiwack, Arnaud ; Richard Eisenberg >>> | ; ghc-steering-committee >> | committee at haskell.org> >>> | Subject: Re: [ghc-steering-committee] Proposal #281: Visible "forall" >>> | in terms; rec: accept >>> | >>> | Simon, perhaps you’re thinking of another proposal that is currently >>> | under committee’s consideration? >>> | >>> | Arnaud was commenting on #281, and you seem to be talking about #425. >>> | >>> | - Vlad >>> | >>> | > On 27 Oct 2021, at 12:05, Simon Peyton Jones via ghc-steering- >>> | committee wrote: >>> | > >>> | > There are a lot of inconvenient side effects and corner cases >>> | > >>> | > Arnaud, could you enumerate them? Even if (as I strongly hope) we >>> | accept this proposal, it’s good to have a concrete list of things to >>> | bear in mind. I for one do not have such list in my head. >>> | > >>> | > One principle that the proposal espouses (but perhaps does not call >>> | out explicitly) is that it should be possible to write an explicit >>> | binder for every in-scope variable. So instead of >>> | > data T (a :: k -> k) = … I want to write >>> | > data T @k (a :: k -> k) = … with an explicit binder >>> | > for k. >>> | > >>> | > So I see the proposal as removing an ad-hoc wart in the language. >>> | But I may be blind to the “inconvenient side effects and corner cases” >>> | and I’d welcome a list of such cases. >>> | > >>> | > Simon >>> | > >>> | > >>> | > PS: I am leaving Microsoft at the end of November 2021, at which >>> | point >>> | > simonpj at microsoft.com will cease to work. >>> | > Usesimon.peytonjones at gmail.com instead. (For now, it just forwards >>> | to >>> | > simonpj at microsoft.com.) >>> | > >>> | > From: ghc-steering-committee >>> | > On Behalf Of Spiwack, >>> | > Arnaud >>> | > Sent: 27 October 2021 09:20 >>> | > To: Richard Eisenberg >>> | > Cc: ghc-steering-committee >>> | > Subject: Re: [ghc-steering-committee] Proposal #281: Visible >>> | "forall" >>> | > in terms; rec: accept >>> | > >>> | > I've been struggling to have an opinion on this PR. I'm very >>> | sympathetic to the goal of the proposal (and this latest rendition of >>> | the proposal is a really good document). There are a lot of >>> | inconvenient side effects and corner cases (but, to be fair, these are >>> | not special to this proposal: they are inherent to the dependent types >>> | plan). But I'm fairly convinced that this is the best possible >>> | approach, or close enough. >>> | > >>> | > >>> | > >>> | > So yes, I don't really feel strongly about it. But on balance, I >>> | think that I'm in favour. > > _______________________________________________ > 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 Fri Oct 29 14:53:35 2021 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 29 Oct 2021 14:53:35 +0000 Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept In-Reply-To: <8793cd72-2406-4f1c-9095-3dedd1ceb14b@www.fastmail.com> References: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> <8793cd72-2406-4f1c-9095-3dedd1ceb14b@www.fastmail.com> Message-ID: | 1. f @Int -- traditional, invisible forall 2. f Int -- visible forall, | Int is unambiguous 3. f (type Int) -- visible forall, Int is ambiguous Perhaps it would help, in the proposal, to make explicit the argument *against* using @ as the herald for all type arguments. I remember that there *is* such an argument, and I found it quite convincing, but I can't remember it now. Maybe it is there somewhere? Vlad/Richard? Simon PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) | -----Original Message----- | From: ghc-steering-committee On Behalf Of Eric Seidel | Sent: 29 October 2021 02:16 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Proposal #281: Visible "forall" | in terms; rec: accept | | I would still prefer alternative 5 (using @ as the type herald). I | really dislike that we would now have three ways to specify a type | argument: | | 1. f @Int -- traditional, invisible forall 2. f Int -- visible forall, | Int is unambiguous 3. f (type Int) -- visible forall, Int is ambiguous | | Ideally I would have single syntax for specifying type arguments, | which was historically (1). I know that many people would like to | unify the term and type syntaxes, so I'm ok with (2) as well even | though the T2T algorithm seemed quite involved. But adding (3) really | feels excessive. | | But I believe I'm a small minority in this opinion, so I don't want to | stand in the way of a very useful feature. | | On Wed, Oct 27, 2021, at 09:56, Richard Eisenberg wrote: | > It has been two weeks. I have heard no argument against this | proposal, | > but Simon Marlow (in the springtime) expressed some puzzlement. | Simon, | > what are you thinking about this now? With no further response, I | will | > accept this proposal on Friday. | > | > Others are also very welcome to chime in! | > | > Thanks, all! | > Richard | > | >> On Oct 27, 2021, at 5:30 AM, Spiwack, Arnaud | wrote: | >> | >> I think that the proposal makes a great job at listing the issues. | It's quite transparent about this, I'm not sure what I could add. | >> | >> On Wed, Oct 27, 2021 at 11:29 AM Simon Peyton Jones | wrote: | >>> I was indeed confused! Apologies. | >>> | >>> But my main point remains: enumerating a list of inconvenient side | effects and corner cases would be a great service. | >>> | >>> Simon | >>> | >>> PS: I am leaving Microsoft at the end of November 2021, at which | >>> point simonpj at microsoft.com will cease to work. Use | >>> simon.peytonjones at gmail.com instead. (For now, it just forwards | to | >>> simonpj at microsoft.com.) | >>> | >>> | -----Original Message----- | >>> | From: Vladislav Zavialov (int-index) | >>> | Sent: 27 October 2021 10:10 | >>> | To: Simon Peyton Jones | >>> | Cc: Spiwack, Arnaud ; Richard | Eisenberg | >>> | ; ghc-steering-committee >> | committee at haskell.org> | >>> | Subject: Re: [ghc-steering-committee] Proposal #281: Visible | "forall" | >>> | in terms; rec: accept | >>> | | >>> | Simon, perhaps you're thinking of another proposal that is | >>> | currently under committee's consideration? | >>> | | >>> | Arnaud was commenting on #281, and you seem to be talking about | #425. | >>> | | >>> | - Vlad | >>> | | >>> | > On 27 Oct 2021, at 12:05, Simon Peyton Jones via ghc- | steering- | >>> | committee wrote: | >>> | > | >>> | > There are a lot of inconvenient side effects and corner cases | >>> | > > Arnaud, could you enumerate them? Even if (as I strongly | >>> | hope) we accept this proposal, it's good to have a concrete | list | >>> | of things to | >>> | bear in mind. I for one do not have such list in my head. | >>> | > | >>> | > One principle that the proposal espouses (but perhaps does | not | >>> | call out explicitly) is that it should be possible to write an | explicit | >>> | binder for every in-scope variable. So instead of | >>> | > data T (a :: k -> k) = ... I want to write | >>> | > data T @k (a :: k -> k) = ... with an explicit | binder | >>> | > for k. | >>> | > | >>> | > So I see the proposal as removing an ad-hoc wart in the | language. | >>> | But I may be blind to the "inconvenient side effects and corner | cases" | >>> | and I'd welcome a list of such cases. | >>> | > | >>> | > Simon | >>> | > | >>> | > | >>> | > PS: I am leaving Microsoft at the end of November 2021, at | >>> | which point > simonpj at microsoft.com will cease to work. | >>> | > Usesimon.peytonjones at gmail.com instead. (For now, it just | >>> | forwards to > simonpj at microsoft.com.) > > From: | >>> | ghc-steering-committee > | >>> | On Behalf Of | Spiwack, | >>> | > Arnaud > Sent: 27 October 2021 09:20 > To: Richard Eisenberg | >>> | > Cc: ghc-steering-committee | >>> | | >>> | > Subject: Re: [ghc-steering-committee] Proposal #281: Visible | >>> | "forall" | >>> | > in terms; rec: accept | >>> | > | >>> | > I've been struggling to have an opinion on this PR. I'm very | >>> | sympathetic to the goal of the proposal (and this latest | rendition | >>> | of the proposal is a really good document). There are a lot of | >>> | inconvenient side effects and corner cases (but, to be fair, | these | >>> | are not special to this proposal: they are inherent to the | >>> | dependent types plan). But I'm fairly convinced that this is | the | >>> | best possible approach, or close enough. | >>> | > | >>> | > | >>> | > | >>> | > So yes, I don't really feel strongly about it. But on | balance, | >>> | I think that I'm in favour. | > | > _______________________________________________ | > 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%7C69ae5d5e09784d08370708d99a | > | 79ccff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710670242799539 | > | %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I | > | k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hGq4xMd5RsHOEGwF7lr3QCuMUXrxSwl | > cjEH89KLcy5A%3D&reserved=0 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C69ae5d5e09784d0 | 8370708d99a79ccff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6377106 | 70242799539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hGq4xMd5RsHOEGwF7lr3 | QCuMUXrxSwlcjEH89KLcy5A%3D&reserved=0 From vlad.z.4096 at gmail.com Fri Oct 29 15:01:19 2021 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Fri, 29 Oct 2021 18:01:19 +0300 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> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> <8793cd72-2406-4f1c-9095-3dedd1ceb14b@www.fastmail.com> Message-ID: The problem with ‘@‘, as explained by Richard, is cited right next to the Alternative 5. However, I agree with Eric that the ’type’ herald feels excessive. It’s not something I personally intend to use. However, I remember Simon PJ and Iavor liked it (if I recall correctly), hence its inclusion in the proposal. I don’t think it hurts either, though. We can accommodate different programming styles. - Vlad > On 29 Oct 2021, at 17:53, Simon Peyton Jones via ghc-steering-committee wrote: > > | 1. f @Int -- traditional, invisible forall 2. f Int -- visible forall, > | Int is unambiguous 3. f (type Int) -- visible forall, Int is ambiguous > > Perhaps it would help, in the proposal, to make explicit the argument *against* using @ as the herald for all type arguments. I remember that there *is* such an argument, and I found it quite convincing, but I can't remember it now. Maybe it is there somewhere? > > Vlad/Richard? > > Simon > > PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) > > | -----Original Message----- > | From: ghc-steering-committee | bounces at haskell.org> On Behalf Of Eric Seidel > | Sent: 29 October 2021 02:16 > | To: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] Proposal #281: Visible "forall" > | in terms; rec: accept > | > | I would still prefer alternative 5 (using @ as the type herald). I > | really dislike that we would now have three ways to specify a type > | argument: > | > | 1. f @Int -- traditional, invisible forall 2. f Int -- visible forall, > | Int is unambiguous 3. f (type Int) -- visible forall, Int is ambiguous > | > | Ideally I would have single syntax for specifying type arguments, > | which was historically (1). I know that many people would like to > | unify the term and type syntaxes, so I'm ok with (2) as well even > | though the T2T algorithm seemed quite involved. But adding (3) really > | feels excessive. > | > | But I believe I'm a small minority in this opinion, so I don't want to > | stand in the way of a very useful feature. > | > | On Wed, Oct 27, 2021, at 09:56, Richard Eisenberg wrote: > | > It has been two weeks. I have heard no argument against this > | proposal, > | > but Simon Marlow (in the springtime) expressed some puzzlement. > | Simon, > | > what are you thinking about this now? With no further response, I > | will > | > accept this proposal on Friday. > | > > | > Others are also very welcome to chime in! > | > > | > Thanks, all! > | > Richard > | > > | >> On Oct 27, 2021, at 5:30 AM, Spiwack, Arnaud > | wrote: > | >> > | >> I think that the proposal makes a great job at listing the issues. > | It's quite transparent about this, I'm not sure what I could add. > | >> > | >> On Wed, Oct 27, 2021 at 11:29 AM Simon Peyton Jones > | wrote: > | >>> I was indeed confused! Apologies. > | >>> > | >>> But my main point remains: enumerating a list of inconvenient side > | effects and corner cases would be a great service. > | >>> > | >>> Simon > | >>> > | >>> PS: I am leaving Microsoft at the end of November 2021, at which > | >>> point simonpj at microsoft.com will cease to work. Use > | >>> simon.peytonjones at gmail.com instead. (For now, it just forwards > | to > | >>> simonpj at microsoft.com.) > | >>> > | >>> | -----Original Message----- > | >>> | From: Vladislav Zavialov (int-index) > | >>> | Sent: 27 October 2021 10:10 > | >>> | To: Simon Peyton Jones > | >>> | Cc: Spiwack, Arnaud ; Richard > | Eisenberg > | >>> | ; ghc-steering-committee | >>> | committee at haskell.org> > | >>> | Subject: Re: [ghc-steering-committee] Proposal #281: Visible > | "forall" > | >>> | in terms; rec: accept > | >>> | > | >>> | Simon, perhaps you're thinking of another proposal that is > | >>> | currently under committee's consideration? > | >>> | > | >>> | Arnaud was commenting on #281, and you seem to be talking about > | #425. > | >>> | > | >>> | - Vlad > | >>> | > | >>> | > On 27 Oct 2021, at 12:05, Simon Peyton Jones via ghc- > | steering- > | >>> | committee wrote: > | >>> | > > | >>> | > There are a lot of inconvenient side effects and corner cases > | >>> | > > Arnaud, could you enumerate them? Even if (as I strongly > | >>> | hope) we accept this proposal, it's good to have a concrete > | list > | >>> | of things to > | >>> | bear in mind. I for one do not have such list in my head. > | >>> | > > | >>> | > One principle that the proposal espouses (but perhaps does > | not > | >>> | call out explicitly) is that it should be possible to write an > | explicit > | >>> | binder for every in-scope variable. So instead of > | >>> | > data T (a :: k -> k) = ... I want to write > | >>> | > data T @k (a :: k -> k) = ... with an explicit > | binder > | >>> | > for k. > | >>> | > > | >>> | > So I see the proposal as removing an ad-hoc wart in the > | language. > | >>> | But I may be blind to the "inconvenient side effects and corner > | cases" > | >>> | and I'd welcome a list of such cases. > | >>> | > > | >>> | > Simon > | >>> | > > | >>> | > > | >>> | > PS: I am leaving Microsoft at the end of November 2021, at > | >>> | which point > simonpj at microsoft.com will cease to work. > | >>> | > Usesimon.peytonjones at gmail.com instead. (For now, it just > | >>> | forwards to > simonpj at microsoft.com.) > > From: > | >>> | ghc-steering-committee > > | >>> | On Behalf Of > | Spiwack, > | >>> | > Arnaud > Sent: 27 October 2021 09:20 > To: Richard Eisenberg > | >>> | > Cc: ghc-steering-committee > | >>> | > | >>> | > Subject: Re: [ghc-steering-committee] Proposal #281: Visible > | >>> | "forall" > | >>> | > in terms; rec: accept > | >>> | > > | >>> | > I've been struggling to have an opinion on this PR. I'm very > | >>> | sympathetic to the goal of the proposal (and this latest > | rendition > | >>> | of the proposal is a really good document). There are a lot of > | >>> | inconvenient side effects and corner cases (but, to be fair, > | these > | >>> | are not special to this proposal: they are inherent to the > | >>> | dependent types plan). But I'm fairly convinced that this is > | the > | >>> | best possible approach, or close enough. > | >>> | > > | >>> | > > | >>> | > > | >>> | > So yes, I don't really feel strongly about it. But on > | balance, > | >>> | I think that I'm in favour. > | > > | > _______________________________________________ > | > 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%7C69ae5d5e09784d08370708d99a > | > > | 79ccff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710670242799539 > | > > | %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I > | > > | k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hGq4xMd5RsHOEGwF7lr3QCuMUXrxSwl > | > cjEH89KLcy5A%3D&reserved=0 > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail > | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C69ae5d5e09784d0 > | 8370708d99a79ccff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6377106 > | 70242799539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz > | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hGq4xMd5RsHOEGwF7lr3 > | QCuMUXrxSwlcjEH89KLcy5A%3D&reserved=0 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From eric at seidel.io Fri Oct 29 15:16:06 2021 From: eric at seidel.io (Eric Seidel) Date: Fri, 29 Oct 2021 11:16:06 -0400 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> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> <8793cd72-2406-4f1c-9095-3dedd1ceb14b@www.fastmail.com> Message-ID: Yes, the proposal does argue explicitly against '@', I just don't find the argument all that convincing. In my mind the use of '@' as a visibility specifier is the inconsistency, as '@' has been the symbol for type application both in Core and Haskell for much longer than it has been used as a visibility specifier. On Fri, Oct 29, 2021, at 11:01, Vladislav Zavialov (int-index) wrote: > The problem with ‘@‘, as explained by Richard, is cited right next to > the Alternative 5. > > However, I agree with Eric that the ’type’ herald feels excessive. It’s > not something I personally intend to use. However, I remember Simon PJ > and Iavor liked it (if I recall correctly), hence its inclusion in the > proposal. > > I don’t think it hurts either, though. We can accommodate different > programming styles. > > - Vlad > >> On 29 Oct 2021, at 17:53, Simon Peyton Jones via ghc-steering-committee wrote: >> >> | 1. f @Int -- traditional, invisible forall 2. f Int -- visible forall, >> | Int is unambiguous 3. f (type Int) -- visible forall, Int is ambiguous >> >> Perhaps it would help, in the proposal, to make explicit the argument *against* using @ as the herald for all type arguments. I remember that there *is* such an argument, and I found it quite convincing, but I can't remember it now. Maybe it is there somewhere? >> >> Vlad/Richard? >> >> Simon >> >> PS: I am leaving Microsoft at the end of November 2021, at which point simonpj at microsoft.com will cease to work. Use simon.peytonjones at gmail.com instead. (For now, it just forwards to simonpj at microsoft.com.) >> >> | -----Original Message----- >> | From: ghc-steering-committee > | bounces at haskell.org> On Behalf Of Eric Seidel >> | Sent: 29 October 2021 02:16 >> | To: ghc-steering-committee at haskell.org >> | Subject: Re: [ghc-steering-committee] Proposal #281: Visible "forall" >> | in terms; rec: accept >> | >> | I would still prefer alternative 5 (using @ as the type herald). I >> | really dislike that we would now have three ways to specify a type >> | argument: >> | >> | 1. f @Int -- traditional, invisible forall 2. f Int -- visible forall, >> | Int is unambiguous 3. f (type Int) -- visible forall, Int is ambiguous >> | >> | Ideally I would have single syntax for specifying type arguments, >> | which was historically (1). I know that many people would like to >> | unify the term and type syntaxes, so I'm ok with (2) as well even >> | though the T2T algorithm seemed quite involved. But adding (3) really >> | feels excessive. >> | >> | But I believe I'm a small minority in this opinion, so I don't want to >> | stand in the way of a very useful feature. >> | >> | On Wed, Oct 27, 2021, at 09:56, Richard Eisenberg wrote: >> | > It has been two weeks. I have heard no argument against this >> | proposal, >> | > but Simon Marlow (in the springtime) expressed some puzzlement. >> | Simon, >> | > what are you thinking about this now? With no further response, I >> | will >> | > accept this proposal on Friday. >> | > >> | > Others are also very welcome to chime in! >> | > >> | > Thanks, all! >> | > Richard >> | > >> | >> On Oct 27, 2021, at 5:30 AM, Spiwack, Arnaud >> | wrote: >> | >> >> | >> I think that the proposal makes a great job at listing the issues. >> | It's quite transparent about this, I'm not sure what I could add. >> | >> >> | >> On Wed, Oct 27, 2021 at 11:29 AM Simon Peyton Jones >> | wrote: >> | >>> I was indeed confused! Apologies. >> | >>> >> | >>> But my main point remains: enumerating a list of inconvenient side >> | effects and corner cases would be a great service. >> | >>> >> | >>> Simon >> | >>> >> | >>> PS: I am leaving Microsoft at the end of November 2021, at which >> | >>> point simonpj at microsoft.com will cease to work. Use >> | >>> simon.peytonjones at gmail.com instead. (For now, it just forwards >> | to >> | >>> simonpj at microsoft.com.) >> | >>> >> | >>> | -----Original Message----- >> | >>> | From: Vladislav Zavialov (int-index) >> | >>> | Sent: 27 October 2021 10:10 >> | >>> | To: Simon Peyton Jones >> | >>> | Cc: Spiwack, Arnaud ; Richard >> | Eisenberg >> | >>> | ; ghc-steering-committee > | >>> | committee at haskell.org> >> | >>> | Subject: Re: [ghc-steering-committee] Proposal #281: Visible >> | "forall" >> | >>> | in terms; rec: accept >> | >>> | >> | >>> | Simon, perhaps you're thinking of another proposal that is >> | >>> | currently under committee's consideration? >> | >>> | >> | >>> | Arnaud was commenting on #281, and you seem to be talking about >> | #425. >> | >>> | >> | >>> | - Vlad >> | >>> | >> | >>> | > On 27 Oct 2021, at 12:05, Simon Peyton Jones via ghc- >> | steering- >> | >>> | committee wrote: >> | >>> | > >> | >>> | > There are a lot of inconvenient side effects and corner cases >> | >>> | > > Arnaud, could you enumerate them? Even if (as I strongly >> | >>> | hope) we accept this proposal, it's good to have a concrete >> | list >> | >>> | of things to >> | >>> | bear in mind. I for one do not have such list in my head. >> | >>> | > >> | >>> | > One principle that the proposal espouses (but perhaps does >> | not >> | >>> | call out explicitly) is that it should be possible to write an >> | explicit >> | >>> | binder for every in-scope variable. So instead of >> | >>> | > data T (a :: k -> k) = ... I want to write >> | >>> | > data T @k (a :: k -> k) = ... with an explicit >> | binder >> | >>> | > for k. >> | >>> | > >> | >>> | > So I see the proposal as removing an ad-hoc wart in the >> | language. >> | >>> | But I may be blind to the "inconvenient side effects and corner >> | cases" >> | >>> | and I'd welcome a list of such cases. >> | >>> | > >> | >>> | > Simon >> | >>> | > >> | >>> | > >> | >>> | > PS: I am leaving Microsoft at the end of November 2021, at >> | >>> | which point > simonpj at microsoft.com will cease to work. >> | >>> | > Usesimon.peytonjones at gmail.com instead. (For now, it just >> | >>> | forwards to > simonpj at microsoft.com.) > > From: >> | >>> | ghc-steering-committee > >> | >>> | On Behalf Of >> | Spiwack, >> | >>> | > Arnaud > Sent: 27 October 2021 09:20 > To: Richard Eisenberg >> | >>> | > Cc: ghc-steering-committee >> | >>> | >> | >>> | > Subject: Re: [ghc-steering-committee] Proposal #281: Visible >> | >>> | "forall" >> | >>> | > in terms; rec: accept >> | >>> | > >> | >>> | > I've been struggling to have an opinion on this PR. I'm very >> | >>> | sympathetic to the goal of the proposal (and this latest >> | rendition >> | >>> | of the proposal is a really good document). There are a lot of >> | >>> | inconvenient side effects and corner cases (but, to be fair, >> | these >> | >>> | are not special to this proposal: they are inherent to the >> | >>> | dependent types plan). But I'm fairly convinced that this is >> | the >> | >>> | best possible approach, or close enough. >> | >>> | > >> | >>> | > >> | >>> | > >> | >>> | > So yes, I don't really feel strongly about it. But on >> | balance, >> | >>> | I think that I'm in favour. >> | > >> | > _______________________________________________ >> | > 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%7C69ae5d5e09784d08370708d99a >> | > >> | 79ccff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637710670242799539 >> | > >> | %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I >> | > >> | k1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hGq4xMd5RsHOEGwF7lr3QCuMUXrxSwl >> | > cjEH89KLcy5A%3D&reserved=0 >> | _______________________________________________ >> | ghc-steering-committee mailing list >> | ghc-steering-committee at haskell.org >> | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail >> | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- >> | committee&data=04%7C01%7Csimonpj%40microsoft.com%7C69ae5d5e09784d0 >> | 8370708d99a79ccff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6377106 >> | 70242799539%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz >> | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hGq4xMd5RsHOEGwF7lr3 >> | QCuMUXrxSwlcjEH89KLcy5A%3D&reserved=0 >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From arnaud.spiwack at tweag.io Fri Oct 29 15:35:41 2021 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Fri, 29 Oct 2021 17:35:41 +0200 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> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> <8793cd72-2406-4f1c-9095-3dedd1ceb14b@www.fastmail.com> Message-ID: On Fri, Oct 29, 2021 at 5:16 PM Eric Seidel wrote: > In my mind the use of '@' as a visibility specifier is the inconsistency, > as '@' has been the symbol for type application both in Core and Haskell > for much longer than it has been used as a visibility specifier. > I agree with this. But how would you fix the current situation? `@` is used as a visibility specifier in the user language (well, it switches both visibility and grammar/namespace). If `@` is to switch only grammar/namespace, what do we make of all the `@` that have been written in the past half-dozen years? /Arnaud -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Fri Oct 29 15:49:37 2021 From: eric at seidel.io (Eric Seidel) Date: Fri, 29 Oct 2021 11:49:37 -0400 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> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> <8793cd72-2406-4f1c-9095-3dedd1ceb14b@www.fastmail.com> Message-ID: I suppose we could use the GHC20XX standards as a way to slowly course-correct. 1. Introduce -X at MeansTypeNamespaceOnly 2. Enable -X at MeansTypeNamespaceOnly as part of GHC2022 3. Let the ecosystem slowly adopt the change as they move to newer language standards But I think there would still be more questions to answer. 1. What becomes the new syntax for visibility specifiers? (I think Agda and Idris use {}?) 2. Do we really need visibility specifiers? (I wish the answer were no, but I think it's yes.) 3. If we do need visibility specifiers, do I then have to write `f {@Int}` to specify an invisible type argument? That's gross. So I'm netting out in the same place as Arnaud, somewhat uncomfortable with the proposal, but unable to come up with a better idea that doesn't compromise on expressiveness. I really do wish we could avoid the three ways to specify type arguments, but it seems like they're all necessary for different reasons.. On Fri, Oct 29, 2021, at 11:35, Spiwack, Arnaud wrote: > On Fri, Oct 29, 2021 at 5:16 PM Eric Seidel wrote: >> In my mind the use of '@' as a visibility specifier is the inconsistency, as '@' has been the symbol for type application both in Core and Haskell for much longer than it has been used as a visibility specifier. > > I agree with this. But how would you fix the current situation? `@` is > used as a visibility specifier in the user language (well, it switches > both visibility and grammar/namespace). If `@` is to switch only > grammar/namespace, what do we make of all the `@` that have been > written in the past half-dozen years? > > /Arnaud From lists at richarde.dev Fri Oct 29 17:56:58 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Fri, 29 Oct 2021 17:56:58 +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> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> <8793cd72-2406-4f1c-9095-3dedd1ceb14b@www.fastmail.com> Message-ID: <010f017ccd329aad-7b59b47e-d107-4855-90c8-2235f5bd3bc7-000000@us-east-2.amazonses.com> Here's my take: 1. We need visibility specifiers: otherwise, we'd have no way of knowing which arguments were original invisible and which weren't. Example: `f x y` vs `f (%ThisWasAnInvisibleArgument x) y` (where I've used an obviously brainless strawman syntax... though a shorter modifier is not as obviously brainless). In the second version, y is the first declared-visible argument. 2. We would like some type arguments to be visible and some to be invisible. This is the nub of the motivation for #281. 3. We thus need at least two ways of passing type arguments: one for declared-invisible ones (this is -XTypeApplications since GHC 8.0) and one for declared-visible ones (this is the new part). 4. The Syntactic Unification Principle of #378 tells us that the way of passing declared-visible types must be the same as the way of passing declared-visible terms (that is, ordinary function arguments). Thus, the way of passing declared-visible types must be by just writing the type in an argument position. Note that we do not have declared-invisible term arguments (ignoring class dictionaries, which operate via quite a separate mechanism). 5. Because of punning (that is, the use of the same name in the term-level and type-level namespaces), a bare type argument might be misinterpreted. (For example, we might want the type T, not its data constructor T.) We thus need a way of stating that we request an identifier from the type-level namespace. The proposal includes the `type` syntax to do this. ---------------- I consider the `type` syntax from the proposal a disambiguation mechanism used as part of visible type application, not really a new way of passing types... though users may well think of it as a third way of passing types, so your point that 3 is too many stands. The good news is that, absent punning, there is no need for the `type` syntax from this proposal. Alternatively, there is nothing stopping a user from writing `type` at *every* visible type application, if they so choose. ---------------- Does this help motivate the current design? Richard > On Oct 29, 2021, at 11:49 AM, Eric Seidel wrote: > > I suppose we could use the GHC20XX standards as a way to slowly course-correct. > > 1. Introduce -X at MeansTypeNamespaceOnly > 2. Enable -X at MeansTypeNamespaceOnly as part of GHC2022 > 3. Let the ecosystem slowly adopt the change as they move to newer language standards > > But I think there would still be more questions to answer. > > 1. What becomes the new syntax for visibility specifiers? (I think Agda and Idris use {}?) > 2. Do we really need visibility specifiers? (I wish the answer were no, but I think it's yes.) > 3. If we do need visibility specifiers, do I then have to write `f {@Int}` to specify an invisible type argument? That's gross. > > So I'm netting out in the same place as Arnaud, somewhat uncomfortable with the proposal, but unable to come up with a better idea that doesn't compromise on expressiveness. I really do wish we could avoid the three ways to specify type arguments, but it seems like they're all necessary for different reasons.. > > On Fri, Oct 29, 2021, at 11:35, Spiwack, Arnaud wrote: >> On Fri, Oct 29, 2021 at 5:16 PM Eric Seidel wrote: >>> In my mind the use of '@' as a visibility specifier is the inconsistency, as '@' has been the symbol for type application both in Core and Haskell for much longer than it has been used as a visibility specifier. >> >> I agree with this. But how would you fix the current situation? `@` is >> used as a visibility specifier in the user language (well, it switches >> both visibility and grammar/namespace). If `@` is to switch only >> grammar/namespace, what do we make of all the `@` that have been >> written in the past half-dozen years? >> >> /Arnaud > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Fri Oct 29 21:17:39 2021 From: eric at seidel.io (Eric Seidel) Date: Fri, 29 Oct 2021 17:17:39 -0400 Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept In-Reply-To: <010f017ccd329aad-7b59b47e-d107-4855-90c8-2235f5bd3bc7-000000@us-east-2.amazonses.com> References: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> <8793cd72-2406-4f1c-9095-3dedd1ceb14b@www.fastmail.com> <010f017ccd329aad-7b59b47e-d107-4855-90c8-2235f5bd3bc7-000000@us-east-2.amazonses.com> Message-ID: <2e803a61-6fec-446d-8d25-f9391a30430d@www.fastmail.com> On Fri, Oct 29, 2021, at 13:56, Richard Eisenberg wrote: > 2. We would like some type arguments to be visible and some to be > invisible. This is the nub of the motivation for #281. Possibly a slight tangent, but if I were to replace every occurrence of "visible" with "required" and "invisible" with "optional", would that be a valid way of reading the discussion around visibility? For some reason the terminology has always been a bit confusing. Veering off a bit further, if the above substitution is valid, would visibility give us a formalism to deal with optional *value* arguments? It's always bothered me that OCaml has optional/named parameters but Haskell does not. From vlad.z.4096 at gmail.com Fri Oct 29 22:06:41 2021 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Sat, 30 Oct 2021 01:06:41 +0300 Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept In-Reply-To: <2e803a61-6fec-446d-8d25-f9391a30430d@www.fastmail.com> References: <010f0179b44f4afa-768644d0-1b2f-4138-8016-17f0a0236dfd-000000@us-east-2.amazonses.com> <010f017ac037d9c8-3a450c97-8afb-40e8-a53f-d283d10566d4-000000@us-east-2.amazonses.com> <010f017c75e49ff0-48d4a340-cbec-4055-88a1-3cf7deb1e607-000000@us-east-2.amazonses.com> <2566325D-3D4E-4B92-A741-2E1B410F1272@gmail.com> <010f017cc20a06a5-ff068842-f663-4d12-a7a6-4edbf9816057-000000@us-east-2.amazonses.com> <8793cd72-2406-4f1c-9095-3dedd1ceb14b@www.fastmail.com> <010f017ccd329aad-7b59b47e-d107-4855-90c8-2235f5bd3bc7-000000@us-east-2.amazonses.com> <2e803a61-6fec-446d-8d25-f9391a30430d@www.fastmail.com> Message-ID: There’s indeed a similarity, but also some differences. Optional parameters are typically defaulted rather than inferred by unification, and they can be passed by name rather than by position. Both of those would be welcome additions to Haskell, y the way (at least in my opinion, surely this also would need a full proposal). Those features wouldn’t be a replacement for visible forall, though, but an addition. So before we continue this discussion: what do we think of the proposal at hand? Richard, you were planning to merge today. My interpretation of Eric’s position (correct me if I’m misrepresenting) is that there are some unfortunate consequences of the proposed design, but we are more or less forced into it by the SUP and other constraints, so there don’t appear to be any better alternatives. Shall we pull the trigger? - Vlad > On 30 Oct 2021, at 00:17, Eric Seidel wrote: > > On Fri, Oct 29, 2021, at 13:56, Richard Eisenberg wrote: >> 2. We would like some type arguments to be visible and some to be >> invisible. This is the nub of the motivation for #281. > > Possibly a slight tangent, but if I were to replace every occurrence of "visible" with "required" and "invisible" with "optional", would that be a valid way of reading the discussion around visibility? For some reason the terminology has always been a bit confusing. > > Veering off a bit further, if the above substitution is valid, would visibility give us a formalism to deal with optional *value* arguments? It's always bothered me that OCaml has optional/named parameters but Haskell does not. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From eric at seidel.io Fri Oct 29 22:20:16 2021 From: eric at seidel.io (Eric Seidel) Date: Fri, 29 Oct 2021 18:20:16 -0400 Subject: [ghc-steering-committee] Proposal #281: Visible "forall" in terms; rec: accept In-Reply-To: References: Message-ID: Yes, to be absolutely clear, I’m ok with merging. Sent from my iPhone > On Oct 29, 2021, at 18:06, Vladislav Zavialov (int-index) wrote: > > There’s indeed a similarity, but also some differences. Optional parameters are typically defaulted rather than inferred by unification, and they can be passed by name rather than by position. Both of those would be welcome additions to Haskell, y the way (at least in my opinion, surely this also would need a full proposal). > > Those features wouldn’t be a replacement for visible forall, though, but an addition. So before we continue this discussion: what do we think of the proposal at hand? > > Richard, you were planning to merge today. My interpretation of Eric’s position (correct me if I’m misrepresenting) is that there are some unfortunate consequences of the proposed design, but we are more or less forced into it by the SUP and other constraints, so there don’t appear to be any better alternatives. > > Shall we pull the trigger? > > - Vlad > >> On 30 Oct 2021, at 00:17, Eric Seidel wrote: >> >>> On Fri, Oct 29, 2021, at 13:56, Richard Eisenberg wrote: >>> 2. We would like some type arguments to be visible and some to be >>> invisible. This is the nub of the motivation for #281. >> >> Possibly a slight tangent, but if I were to replace every occurrence of "visible" with "required" and "invisible" with "optional", would that be a valid way of reading the discussion around visibility? For some reason the terminology has always been a bit confusing. >> >> Veering off a bit further, if the above substitution is valid, would visibility give us a formalism to deal with optional *value* arguments? It's always bothered me that OCaml has optional/named parameters but Haskell does not. >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From mail at joachim-breitner.de Sun Oct 31 14:24:19 2021 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 31 Oct 2021 15:24:19 +0100 Subject: [ghc-steering-committee] Please review #413: GHC Maintainer Preview, Shepherd: Vlad Message-ID: Dear Committee, this is your secretary speaking: GHC Maintainer Preview, a change to GHC's release process, has been proposed by Hécate Moonlight. https://github.com/ghc-proposals/ghc-proposals/pull/413 https://github.com/Kleidukos/ghc-proposals/blob/patch-1/proposals/0000-ghc-maintainer-preview.md I propose Vladislav as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From vlad.z.4096 at gmail.com Sun Oct 31 15:08:34 2021 From: vlad.z.4096 at gmail.com (Vladislav Zavialov (int-index)) Date: Sun, 31 Oct 2021 18:08:34 +0300 Subject: [ghc-steering-committee] Please review #413: GHC Maintainer Preview, Shepherd: Vlad In-Reply-To: References: Message-ID: I judged the proposal to be out of scope. Nevertheless, I invite the committee to participate in the GitHub discussion anyway. I believe the perspective of the committee’s members would be helpful. The correct link to the proposal is https://github.com/ghc-proposals/ghc-proposals/pull/417 - Vlad > On 31 Oct 2021, at 17:24, Joachim Breitner wrote: > > Dear Committee, > > this is your secretary speaking: > > GHC Maintainer Preview, a change to GHC's release process, > has been proposed by Hécate Moonlight. > https://github.com/ghc-proposals/ghc-proposals/pull/413 > > https://github.com/Kleidukos/ghc-proposals/blob/patch-1/proposals/0000-ghc-maintainer-preview.md > > I propose Vladislav as the shepherd. > > Please guide us to a conclusion as outlined in > https://github.com/ghc-proposals/ghc-proposals#committee-process > > Thanks, > Joachim > > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee