From mail at joachim-breitner.de Sun Nov 3 11:17:03 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 03 Nov 2019 12:17:03 +0100 Subject: [ghc-steering-committee] Please review #254: Scale back "Function Result Type Signatures" Shepherd: SPJ In-Reply-To: References: <26334dda17346630ad592c9ebc185bd1ab992fd8.camel@joachim-breitner.de> Message-ID: <8419c29ec8204e916a4ca4bd19608f47432ffbdd.camel@joachim-breitner.de> Hi, I sense consensus, will mark as accepted. Cheers, Joachim Am Freitag, den 18.10.2019, 11:17 -0700 schrieb Iavor Diatchki: > The scaling back seems reasonable to me. > > Similar to Simon's comment > (https://github.com/ghc-proposals/ghc-proposals/pull/254#issuecomment-542644791) > I am also quite unclear of what a return type annotations like `Num a > => a -> a` is supposed to mean. After all, `a` is not universally > quantified here, it is just a name for a type that occurs in the > result, so the definition of the function could already impose > whatever constraints it wants on it... > > -Iavor > > > > On Thu, Oct 17, 2019 at 12:11 AM Spiwack, Arnaud > wrote: > > I'm convinced. > > > > On Wed, Oct 16, 2019 at 12:51 PM Simon Peyton Jones via ghc-steering-committee wrote: > > > Colleagues > > > > > > I recommend acceptance. I have given my reasoning here: > > > https://github.com/ghc-proposals/ghc-proposals/pull/254#issuecomment-542643788 > > > > > > Simon > > > > > > > -----Original Message----- > > > > From: ghc-steering-committee > > > > On Behalf Of Joachim Breitner > > > > Sent: 14 October 2019 08:35 > > > > To: ghc-steering-committee at haskell.org > > > > Subject: [ghc-steering-committee] Please review #254: Scale back "Function > > > > Result Type Signatures" Shepherd: SPJ > > > > > > > > Dear Committee, > > > > > > > > this is your secretary speaking: > > > > > > > > Scale back "Function Result Type Signatures" to keep pattern sigs as-is > > > > has been proposed by John Ericson > > > > https://github.com/ghc-proposals/ghc-proposals/pull/254 > > > > > > > > > > > > This proposal amends #228, so I propose Simon PJ as the shepherd, > > > > because he also shepherded #228. > > > > > > > > Please reach consensus as described in > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > In particular, talk to the authors before, if you think this should be > > > > rejected, and kick off the discussion on Github, following the steps > > > > described under “Now the shepherd proposes to accept or reject the > > > > proposal” in the above link. > > > > > > > > Thanks, > > > > Joachim > > > > -- > > > > Joachim Breitner > > > > mail at joachim-breitner.de > > > > http://www.joachim-breitner.de/ > > > > > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Sun Nov 3 11:27:57 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 03 Nov 2019 12:27:57 +0100 Subject: [ghc-steering-committee] Status Message-ID: Dear committee, Sany is smearing honey around my mouth on reddit, so I better leap into action and fulfill expectations. Since the last status, we * SPJ refined our processes in #271 * were asked to review these proposals: #274: Quick Look Impredicativity (Shepherd: Arnaud) #277: WinAPI cconv (Shepherd: Tamar) #270: Unified Namespace (Shepherd: Iavor) #254: Scale back "Function Result Type Signatures" (Shepherd: SPJ) #195: newtype Q (Texp a) (Shepherd: Iavor) * have a recommendation form the shepherd about: #277: WinAPI cconv (rec: accept) #274: Quick Look Impredicativity (rec: accept) #254: Scale back "Function Result Type Signatures" (rec: accept) * decided about the following proposals #259: No kind signatures on associated types (accept) #220: QualifiedImports (reject) #277: WinAPI cconv (accept) #254: Scale back "Function Result Type Signatures" (accept) #270: Unified Namespace (needs revision) We currently have to act on the following 3 proposals, keeping our backlog nicely stable. Good job! ## Waiting for Shepherd action Updated partial type signatures Shepherd: Vitaly https://github.com/ghc-proposals/ghc-proposals/pull/194 newtype Q (Texp a) Shepherd: Iavor https://github.com/ghc-proposals/ghc-proposals/pull/195 ## Waiting for committee decision Quick Look Impredicativity Shepherd: Arnaud https://github.com/ghc-proposals/ghc-proposals/pull/274 Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Mon Nov 4 08:18:49 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 04 Nov 2019 09:18:49 +0100 Subject: [ghc-steering-committee] Please review again #177: Simple constrained type families, Shepherd: Richard Message-ID: Dear Committee, this is your secretary speaking: Simple constrained type families has been revised by Alexis Williams https://github.com/ghc-proposals/ghc-proposals/pull/117 https://github.com/typedrat/ghc-proposals/blob/constrained-type-families/proposals/0000-simple-constrained-type-families.rst I propose Richard as the Shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Mon Nov 4 08:21:33 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 04 Nov 2019 09:21:33 +0100 Subject: [ghc-steering-committee] Please review #273: Local Types, Shepherd: Eric Message-ID: Dear Committee, this is your secretary speaking: Local Types has been updated by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/273 https://github.com/treeowl/ghc-proposals/blob/local-types/proposals/0000-local-types.md I propose Eric as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rae at richarde.dev Tue Nov 5 10:42:43 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 5 Nov 2019 10:42:43 +0000 Subject: [ghc-steering-committee] Please review again #177: Simple constrained type families, Shepherd: Richard In-Reply-To: References: Message-ID: <7F5B114E-BF85-4A0A-BEA6-B18E11B570A1@richarde.dev> I have made a comment on the GitHub trail (https://github.com/ghc-proposals/ghc-proposals/pull/177#issuecomment-549766671), which is #177, not #117 as Joachim linked below. This comment puts the proposal back into the "needs revision" state. I will make a recommendation once it has been revised. Richard > On Nov 4, 2019, at 8:18 AM, Joachim Breitner wrote: > > Dear Committee, > > this is your secretary speaking: > > Simple constrained type families > has been revised by Alexis Williams > https://github.com/ghc-proposals/ghc-proposals/pull/117 > https://github.com/typedrat/ghc-proposals/blob/constrained-type-families/proposals/0000-simple-constrained-type-families.rst > > I propose Richard as the Shepherd. > > Please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > I suggest you make a recommendation, in a new e-mail thread with the > proposal number in the subject, about the decision, maybe point out > debatable points, and assume that anyone who stays quiet agrees with > you. > > Thanks, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From iavor.diatchki at gmail.com Tue Nov 5 16:43:31 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 5 Nov 2019 08:43:31 -0800 Subject: [ghc-steering-committee] #195 recommendation: accept Message-ID: Hello everyone, I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a newtype synonym `Code a`. The main change to the language is that the special Template Haskell notation for typed splices will will work with `Code a` rather than `Q (TExtp a)`. The benefit of having the newtype is that it makes it possible to abstract over `Code`. For example, you can work with typed name environments like `MapF Name Code`, where `MapF` is an "indexed" variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in package `parameterized-utils` on hackage). Making typed TH work with `Code` directly avoids the need to constantly switch between `Code` and `Q (TExp a)` and with the new system users of typed TH are not likely to deal with the latter much at all. For these reasons I recommend that we accept this proposal. Please let me know if you think otherwise. -Iavor From simonpj at microsoft.com Tue Nov 5 17:23:09 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 5 Nov 2019 17:23:09 +0000 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: Message-ID: It's really helpful if email of this kind includes a link to the proposal. Here it is https://github.com/ghc-proposals/ghc-proposals/pull/195 Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Iavor Diatchki | Sent: 05 November 2019 16:44 | To: ghc-steering-committee | Subject: [ghc-steering-committee] #195 recommendation: accept | | Hello everyone, | | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a | newtype synonym `Code a`. The main change to the language is that the | special Template Haskell notation for typed splices will will work | with `Code a` rather than `Q (TExtp a)`. | | The benefit of having the newtype is that it makes it possible to | abstract over `Code`. For example, you can work with typed name | environments like `MapF Name Code`, where `MapF` is an "indexed" | variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in | package `parameterized-utils` on hackage). | | Making typed TH work with `Code` directly avoids the need to | constantly switch between `Code` and `Q (TExp a)` and with the new | system users of typed TH are not likely to deal with the latter much | at all. | | For these reasons I recommend that we accept this proposal. Please | let me know if you think otherwise. | | -Iavor | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser | ved=0 From simonpj at microsoft.com Tue Nov 5 17:23:57 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 5 Nov 2019 17:23:57 +0000 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: Message-ID: I'm basically supportive, but would like to see answers to my recent questions incorporated in the proposal before it is accepted. https://github.com/ghc-proposals/ghc-proposals/pull/195#issuecomment-547522510 Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Iavor Diatchki | Sent: 05 November 2019 16:44 | To: ghc-steering-committee | Subject: [ghc-steering-committee] #195 recommendation: accept | | Hello everyone, | | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a | newtype synonym `Code a`. The main change to the language is that the | special Template Haskell notation for typed splices will will work | with `Code a` rather than `Q (TExtp a)`. | | The benefit of having the newtype is that it makes it possible to | abstract over `Code`. For example, you can work with typed name | environments like `MapF Name Code`, where `MapF` is an "indexed" | variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in | package `parameterized-utils` on hackage). | | Making typed TH work with `Code` directly avoids the need to | constantly switch between `Code` and `Q (TExp a)` and with the new | system users of typed TH are not likely to deal with the latter much | at all. | | For these reasons I recommend that we accept this proposal. Please | let me know if you think otherwise. | | -Iavor | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser | ved=0 From rae at richarde.dev Tue Nov 5 21:45:41 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 5 Nov 2019 21:45:41 +0000 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: Message-ID: I'm in the same camp as Simon here -- I'm still a little murky on how `Code` will interact with `Q`. Richard > On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via ghc-steering-committee wrote: > > I'm basically supportive, but would like to see answers to my recent questions incorporated in the proposal before it is accepted. > https://github.com/ghc-proposals/ghc-proposals/pull/195#issuecomment-547522510 > > Simon > > > | -----Original Message----- > | From: ghc-steering-committee > | On Behalf Of Iavor Diatchki > | Sent: 05 November 2019 16:44 > | To: ghc-steering-committee > | Subject: [ghc-steering-committee] #195 recommendation: accept > | > | Hello everyone, > | > | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a > | newtype synonym `Code a`. The main change to the language is that the > | special Template Haskell notation for typed splices will will work > | with `Code a` rather than `Q (TExtp a)`. > | > | The benefit of having the newtype is that it makes it possible to > | abstract over `Code`. For example, you can work with typed name > | environments like `MapF Name Code`, where `MapF` is an "indexed" > | variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in > | package `parameterized-utils` on hackage). > | > | Making typed TH work with `Code` directly avoids the need to > | constantly switch between `Code` and `Q (TExp a)` and with the new > | system users of typed TH are not likely to deal with the latter much > | at all. > | > | For these reasons I recommend that we accept this proposal. Please > | let me know if you think otherwise. > | > | -Iavor > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb > | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 > | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser > | ved=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 Wed Nov 6 08:46:08 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 6 Nov 2019 09:46:08 +0100 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: Message-ID: I understand that some details are lacking. But I don't think, whatever the details are, that they will affect my opinion of the proposal: they are over my knowledge of Template Haskell. This proposal seems well motivated. So, I'll count as an accept vote, when the details are eventually sorted out. On Tue, Nov 5, 2019 at 10:45 PM Richard Eisenberg wrote: > I'm in the same camp as Simon here -- I'm still a little murky on how > `Code` will interact with `Q`. > > Richard > > > On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via > ghc-steering-committee wrote: > > > > I'm basically supportive, but would like to see answers to my recent > questions incorporated in the proposal before it is accepted. > > > https://github.com/ghc-proposals/ghc-proposals/pull/195#issuecomment-547522510 > > > > Simon > > > > > > | -----Original Message----- > > | From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> > > | On Behalf Of Iavor Diatchki > > | Sent: 05 November 2019 16:44 > > | To: ghc-steering-committee > > | Subject: [ghc-steering-committee] #195 recommendation: accept > > | > > | Hello everyone, > > | > > | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a > > | newtype synonym `Code a`. The main change to the language is that the > > | special Template Haskell notation for typed splices will will work > > | with `Code a` rather than `Q (TExtp a)`. > > | > > | The benefit of having the newtype is that it makes it possible to > > | abstract over `Code`. For example, you can work with typed name > > | environments like `MapF Name Code`, where `MapF` is an "indexed" > > | variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in > > | package `parameterized-utils` on hackage). > > | > > | Making typed TH work with `Code` directly avoids the need to > > | constantly switch between `Code` and `Q (TExp a)` and with the new > > | system users of typed TH are not likely to deal with the latter much > > | at all. > > | > > | For these reasons I recommend that we accept this proposal. Please > > | let me know if you think otherwise. > > | > > | -Iavor > > | _______________________________________________ > > | ghc-steering-committee mailing list > > | ghc-steering-committee at haskell.org > > | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > > | committee&data=02%7C01%7Csimonpj%40microsoft.com > %7Ce2fd3cfd09334b865fb > > | > 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 > > | > 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser > > | ved=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 simonpj at microsoft.com Wed Nov 6 09:21:49 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Nov 2019 09:21:49 +0000 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: Message-ID: when the details are eventually sorted out But when will that be? Our criteria say that the proposal should stand by itself before we finally accept it. If there are specifics that we think belong in the proposal, then our protocol is: * tell the authors that we are minded to accept, * invite them to fill in the missing stuff and resubmit * change status to “needs revision” I don’t think we should formally accept proposals that are ill-specified, in the hope that they’ll subsequently be fixed up. Pushing back to “please revise to address these points” is not a negative thing – it’s a positive thing, saying good proposal but let’s make it better. Simon From: Spiwack, Arnaud Sent: 06 November 2019 08:46 To: Richard Eisenberg Cc: Simon Peyton Jones ; ghc-steering-committee Subject: Re: [ghc-steering-committee] #195 recommendation: accept I understand that some details are lacking. But I don't think, whatever the details are, that they will affect my opinion of the proposal: they are over my knowledge of Template Haskell. This proposal seems well motivated. So, I'll count as an accept vote, when the details are eventually sorted out. On Tue, Nov 5, 2019 at 10:45 PM Richard Eisenberg > wrote: I'm in the same camp as Simon here -- I'm still a little murky on how `Code` will interact with `Q`. Richard > On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via ghc-steering-committee > wrote: > > I'm basically supportive, but would like to see answers to my recent questions incorporated in the proposal before it is accepted. > https://github.com/ghc-proposals/ghc-proposals/pull/195#issuecomment-547522510 > > Simon > > > | -----Original Message----- > | From: ghc-steering-committee > > | On Behalf Of Iavor Diatchki > | Sent: 05 November 2019 16:44 > | To: ghc-steering-committee > > | Subject: [ghc-steering-committee] #195 recommendation: accept > | > | Hello everyone, > | > | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a > | newtype synonym `Code a`. The main change to the language is that the > | special Template Haskell notation for typed splices will will work > | with `Code a` rather than `Q (TExtp a)`. > | > | The benefit of having the newtype is that it makes it possible to > | abstract over `Code`. For example, you can work with typed name > | environments like `MapF Name Code`, where `MapF` is an "indexed" > | variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in > | package `parameterized-utils` on hackage). > | > | Making typed TH work with `Code` directly avoids the need to > | constantly switch between `Code` and `Q (TExp a)` and with the new > | system users of typed TH are not likely to deal with the latter much > | at all. > | > | For these reasons I recommend that we accept this proposal. Please > | let me know if you think otherwise. > | > | -Iavor > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb > | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 > | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser > | ved=0 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Nov 6 09:30:40 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 6 Nov 2019 10:30:40 +0100 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: Message-ID: > I don’t think we should formally accept proposals that are ill-specified, > in the hope that they’ll subsequently be fixed up. Pushing back to “please > revise to address these points” is not a negative thing – it’s a positive > thing, saying good proposal but let’s make it better. > > > > > For the record: I didn't imply otherwise (I was merely registering my acceptance provided details are filled out to the rest of the committee's satisfaction). I'm rather curious of what made my email sound like I was suggesting immediate acceptance, but I really don't want to derail this thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed Nov 6 09:34:57 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 Nov 2019 09:34:57 +0000 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: Message-ID: I'm rather curious of what made my email sound like I was suggesting immediate acceptance, I just misinterpreted this: “This proposal seems well motivated. So, I'll count as an accept vote, when the details are eventually sorted out.” I understood you to mean “Let’s accept the proposal, if enough people have an accept vote, and leave it to the authors to sort out the details later”. But I obviously read too much into your words – apologies. Simon From: Spiwack, Arnaud Sent: 06 November 2019 09:31 To: Simon Peyton Jones Cc: Richard Eisenberg ; ghc-steering-committee Subject: Re: [ghc-steering-committee] #195 recommendation: accept I don’t think we should formally accept proposals that are ill-specified, in the hope that they’ll subsequently be fixed up. Pushing back to “please revise to address these points” is not a negative thing – it’s a positive thing, saying good proposal but let’s make it better. For the record: I didn't imply otherwise (I was merely registering my acceptance provided details are filled out to the rest of the committee's satisfaction). I'm rather curious of what made my email sound like I was suggesting immediate acceptance, but I really don't want to derail this thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Wed Nov 6 16:33:19 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 6 Nov 2019 08:33:19 -0800 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: Message-ID: Hello, I thought my comment on GitHub answered Simon's questions, but Matt should indeed update the proposal to make it explicit. For the record here is how I think they should be answered: * Is the data constructor Code visible to clients? Can they look inside the abstraction? - I think we should have a way to convert from `Code a` of a type `Q (TExp a)`. `fromCode :: Code a -> Q (TExp a)` - I don't think it matters very much if this is done with a function like that or by exposing thew newtype constructor. - My preference would be to keep `Code` abstract and have the function. * unsafeQ lets you turn a Q (TExp a) into a Code a. But how can you get a Q (TExp a) in the first place? - I would imagine that you'd mostly get it out of `Code` using `fromCode`. - Another way would be to make it unsafely using the `TExp` constructor directly. * Can you/should you be able to get a Q (TExp a) from a Code a? - Yes: it allows splicing typed code in untyped contexts which seems useful. * The text says unsafeQ is added in order to perform unsafe Q actions inside of Code. So I was expecting something like unsafeAddQ :: Q () -> Code a -> Code a unsafeAddQThen :: Q a -> (a -> Code b) -> Code b These can be defined using `fromCode` and `unsafeQ`. If you think they might be useful, we could probably add them to the TH modules. unsafeAddQ q c = unsafeQ (q >> fromCode c) unsafeAddQThen q k = unsafeQ (q >>= fromCode . k) What do others think? Richard, you also had some questions but I am not sure what they are, does this help? -Iavor On Wed, Nov 6, 2019 at 1:35 AM Simon Peyton Jones via ghc-steering-committee wrote: > > I'm rather curious of what made my email sound like I was suggesting immediate acceptance, > > I just misinterpreted this: “This proposal seems well motivated. So, I'll count as an accept vote, when the details are eventually sorted out.” > > I understood you to mean “Let’s accept the proposal, if enough people have an accept vote, and leave it to the authors to sort out the details later”. But I obviously read too much into your words – apologies. > > > > Simon > > > > > > From: Spiwack, Arnaud > Sent: 06 November 2019 09:31 > To: Simon Peyton Jones > Cc: Richard Eisenberg ; ghc-steering-committee > Subject: Re: [ghc-steering-committee] #195 recommendation: accept > > > > > > I don’t think we should formally accept proposals that are ill-specified, in the hope that they’ll subsequently be fixed up. Pushing back to “please revise to address these points” is not a negative thing – it’s a positive thing, saying good proposal but let’s make it better. > > For the record: I didn't imply otherwise (I was merely registering my acceptance provided details are filled out to the rest of the committee's satisfaction). I'm rather curious of what made my email sound like I was suggesting immediate acceptance, but I really don't want to derail this thread. > > _______________________________________________ > 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 Thu Nov 7 09:29:17 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 07 Nov 2019 10:29:17 +0100 Subject: [ghc-steering-committee] Please review #285: -XNoImplicitForAll, Shepherd: Simon Marlow Message-ID: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: -XNoImplicitForAll has been proposed by John Ericson https://github.com/ghc-proposals/ghc-proposals/pull/285 https://github.com/Ericson2314/ghc-proposals/blob/no-implicit-forall/proposals/0000-no-implicit-forall.rst I propose Simon Marlow as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rae at richarde.dev Thu Nov 7 10:50:35 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 7 Nov 2019 10:50:35 +0000 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: Message-ID: <516EB129-BE87-4023-8BB3-E9692D3A0CF9@richarde.dev> Those answers are helpful, yes, but I would want them incorporated in the proposal. And does Matt agree with these answers? Thanks for writing that up! Richard > On Nov 6, 2019, at 4:33 PM, Iavor Diatchki wrote: > > Hello, > > I thought my comment on GitHub answered Simon's questions, but Matt > should indeed update the proposal to make it explicit. > For the record here is how I think they should be answered: > > * Is the data constructor Code visible to clients? Can they look > inside the abstraction? > - I think we should have a way to convert from `Code a` of a type > `Q (TExp a)`. `fromCode :: Code a -> Q (TExp a)` > - I don't think it matters very much if this is done with a > function like that or by exposing thew newtype constructor. > - My preference would be to keep `Code` abstract and have the function. > > * unsafeQ lets you turn a Q (TExp a) into a Code a. But how can you > get a Q (TExp a) in the first place? > - I would imagine that you'd mostly get it out of `Code` using `fromCode`. > - Another way would be to make it unsafely using the `TExp` > constructor directly. > > * Can you/should you be able to get a Q (TExp a) from a Code a? > - Yes: it allows splicing typed code in untyped contexts which seems useful. > > * The text says unsafeQ is added in order to perform unsafe Q actions > inside of Code. So I was expecting something like > unsafeAddQ :: Q () -> Code a -> Code a > unsafeAddQThen :: Q a -> (a -> Code b) -> Code b > > These can be defined using `fromCode` and `unsafeQ`. If you think > they might be useful, we could probably add them to the TH modules. > unsafeAddQ q c = unsafeQ (q >> fromCode c) > unsafeAddQThen q k = unsafeQ (q >>= fromCode . k) > > What do others think? Richard, you also had some questions but I am > not sure what they are, does this help? > > -Iavor > > On Wed, Nov 6, 2019 at 1:35 AM Simon Peyton Jones via > ghc-steering-committee wrote: >> >> I'm rather curious of what made my email sound like I was suggesting immediate acceptance, >> >> I just misinterpreted this: “This proposal seems well motivated. So, I'll count as an accept vote, when the details are eventually sorted out.” >> >> I understood you to mean “Let’s accept the proposal, if enough people have an accept vote, and leave it to the authors to sort out the details later”. But I obviously read too much into your words – apologies. >> >> >> >> Simon >> >> >> >> >> >> From: Spiwack, Arnaud >> Sent: 06 November 2019 09:31 >> To: Simon Peyton Jones >> Cc: Richard Eisenberg ; ghc-steering-committee >> Subject: Re: [ghc-steering-committee] #195 recommendation: accept >> >> >> >> >> >> I don’t think we should formally accept proposals that are ill-specified, in the hope that they’ll subsequently be fixed up. Pushing back to “please revise to address these points” is not a negative thing – it’s a positive thing, saying good proposal but let’s make it better. >> >> For the record: I didn't imply otherwise (I was merely registering my acceptance provided details are filled out to the rest of the committee's satisfaction). I'm rather curious of what made my email sound like I was suggesting immediate acceptance, but I really don't want to derail this thread. >> >> _______________________________________________ >> 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 Nov 9 18:22:14 2019 From: eric at seidel.io (Eric Seidel) Date: Sat, 09 Nov 2019 13:22:14 -0500 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: Message-ID: <23ae6a3a-94b3-4ec1-80c4-58b161221514@www.fastmail.com> I'm also in Arnaud's boat. I support improving the usability of Typed TH, and the Code newtype looks like a step in that direction. So, assuming we can satisfy Simon and Richard's questions, I support acceptance. On Wed, Nov 6, 2019, at 03:46, Spiwack, Arnaud wrote: > I understand that some details are lacking. But I don't think, whatever > the details are, that they will affect my opinion of the proposal: they > are over my knowledge of Template Haskell. > > This proposal seems well motivated. So, I'll count as an accept vote, > when the details are eventually sorted out. > > On Tue, Nov 5, 2019 at 10:45 PM Richard Eisenberg wrote: > > I'm in the same camp as Simon here -- I'm still a little murky on how `Code` will interact with `Q`. > > > > Richard > > > > > On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via ghc-steering-committee wrote: > > > > > > I'm basically supportive, but would like to see answers to my recent questions incorporated in the proposal before it is accepted. > > > https://github.com/ghc-proposals/ghc-proposals/pull/195#issuecomment-547522510 > > > > > > Simon > > > > > > > > > | -----Original Message----- > > > | From: ghc-steering-committee > > > | On Behalf Of Iavor Diatchki > > > | Sent: 05 November 2019 16:44 > > > | To: ghc-steering-committee > > > | Subject: [ghc-steering-committee] #195 recommendation: accept > > > | > > > | Hello everyone, > > > | > > > | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a > > > | newtype synonym `Code a`. The main change to the language is that the > > > | special Template Haskell notation for typed splices will will work > > > | with `Code a` rather than `Q (TExtp a)`. > > > | > > > | The benefit of having the newtype is that it makes it possible to > > > | abstract over `Code`. For example, you can work with typed name > > > | environments like `MapF Name Code`, where `MapF` is an "indexed" > > > | variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in > > > | package `parameterized-utils` on hackage). > > > | > > > | Making typed TH work with `Code` directly avoids the need to > > > | constantly switch between `Code` and `Q (TExp a)` and with the new > > > | system users of typed TH are not likely to deal with the latter much > > > | at all. > > > | > > > | For these reasons I recommend that we accept this proposal. Please > > > | let me know if you think otherwise. > > > | > > > | -Iavor > > > | _______________________________________________ > > > | ghc-steering-committee mailing list > > > | ghc-steering-committee at haskell.org > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > > > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > > > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb > > > | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 > > > | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser > > > | ved=0 > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From marlowsd at gmail.com Mon Nov 11 09:44:02 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 11 Nov 2019 09:44:02 +0000 Subject: [ghc-steering-committee] #285: -XNoImplicitForAll, recommendation: accept In-Reply-To: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de> References: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de> Message-ID: Proposal #285: https://github.com/ghc-proposals/ghc-proposals/pull/285 suggests two new LANGUAGE pragmas -XNoImplicitForall and -XNoPatternSignatureBinds. They have the effect of making a subset of existing programs illegal, and in that sense I don't think these are problematic. The intention is that these would be used with ExplicitForalls to enforce that all identifiers have explicit binding sites. I'm generally supportive of that. However I think we should be wary of the potential future direction, mentioned in the proposal: > As described in the motivation, this opens the door to other means to bind the previously implicitly bound variables. i.e. an unbound name in a type could refer to a type variable bound in an enclosing scope. This would be a language *change*, not merely an addition or subtraction, and hence potentially fork-like. So we would want to consider very carefully whether that's the direction we want to take the language. But since that isn't part of the current proposal, and the current proposal is merely an optional subtraction, I don't think it's controversial. Cheers Simon On Thu, 7 Nov 2019 at 09:29, Joachim Breitner wrote: > Dear Committee, > > this is your secretary speaking: > > -XNoImplicitForAll > has been proposed by John Ericson > https://github.com/ghc-proposals/ghc-proposals/pull/285 > > https://github.com/Ericson2314/ghc-proposals/blob/no-implicit-forall/proposals/0000-no-implicit-forall.rst > > I propose Simon Marlow as the shepherd. > > Please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > I suggest you make a recommendation, in a new e-mail thread with the > proposal number in the subject, about the decision, maybe point out > debatable points, and assume that anyone who stays quiet agrees with > you. > > Thanks, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Tue Nov 12 18:58:24 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 12 Nov 2019 19:58:24 +0100 Subject: [ghc-steering-committee] #285: -XNoImplicitForAll, recommendation: accept In-Reply-To: References: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de> Message-ID: I've left comments on the Github thread. I'm rather sympathetic to this idea. I personally think that the implicit binding rules that we have in place are a bit messy, so simply turning them off may be of help. My Github comments raise two points: - The proposal is a tad challenging to read, and I'd like some improvements before acceptance be considered - I'm questioning whether we really want two extensions for these two very related behaviours On Mon, Nov 11, 2019 at 10:44 AM Simon Marlow wrote: > Proposal #285: > > https://github.com/ghc-proposals/ghc-proposals/pull/285 > > suggests two new LANGUAGE pragmas -XNoImplicitForall and > -XNoPatternSignatureBinds. > > They have the effect of making a subset of existing programs illegal, and > in that sense I don't think these are problematic. The intention is that > these would be used with ExplicitForalls to enforce that all identifiers > have explicit binding sites. I'm generally supportive of that. > > However I think we should be wary of the potential future direction, > mentioned in the proposal: > > > As described in the motivation, this opens the door to other means to > bind the previously implicitly bound variables. > > i.e. an unbound name in a type could refer to a type variable bound in an > enclosing scope. This would be a language *change*, not merely an addition > or subtraction, and hence potentially fork-like. So we would want to > consider very carefully whether that's the direction we want to take the > language. > > But since that isn't part of the current proposal, and the current > proposal is merely an optional subtraction, I don't think it's > controversial. > > Cheers > Simon > > On Thu, 7 Nov 2019 at 09:29, Joachim Breitner > wrote: > >> Dear Committee, >> >> this is your secretary speaking: >> >> -XNoImplicitForAll >> has been proposed by John Ericson >> https://github.com/ghc-proposals/ghc-proposals/pull/285 >> >> https://github.com/Ericson2314/ghc-proposals/blob/no-implicit-forall/proposals/0000-no-implicit-forall.rst >> >> I propose Simon Marlow as the shepherd. >> >> Please reach consensus as described in >> https://github.com/ghc-proposals/ghc-proposals#committee-process >> I suggest you make a recommendation, in a new e-mail thread with the >> proposal number in the subject, about the decision, maybe point out >> debatable points, and assume that anyone who stays quiet agrees with >> you. >> >> Thanks, >> Joachim >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandy at sandymaguire.me Wed Nov 13 01:18:25 2019 From: sandy at sandymaguire.me (Sandy Maguire) Date: Wed, 13 Nov 2019 08:18:25 +0700 Subject: [ghc-steering-committee] #285: -XNoImplicitForAll, recommendation: accept In-Reply-To: References: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de> Message-ID: I'm largely in agreement with Arnaud here. On Wed, Nov 13, 2019 at 1:59 AM Spiwack, Arnaud wrote: > I've left comments on the Github thread. > > I'm rather sympathetic to this idea. I personally think that the implicit > binding rules that we have in place are a bit messy, so simply turning them > off may be of help. > > My Github comments raise two points: > > - The proposal is a tad challenging to read, and I'd like some > improvements before acceptance be considered > - I'm questioning whether we really want two extensions for these two very > related behaviours > > On Mon, Nov 11, 2019 at 10:44 AM Simon Marlow wrote: > >> Proposal #285: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/285 >> >> suggests two new LANGUAGE pragmas -XNoImplicitForall and >> -XNoPatternSignatureBinds. >> >> They have the effect of making a subset of existing programs illegal, and >> in that sense I don't think these are problematic. The intention is that >> these would be used with ExplicitForalls to enforce that all identifiers >> have explicit binding sites. I'm generally supportive of that. >> >> However I think we should be wary of the potential future direction, >> mentioned in the proposal: >> >> > As described in the motivation, this opens the door to other means to >> bind the previously implicitly bound variables. >> >> i.e. an unbound name in a type could refer to a type variable bound in an >> enclosing scope. This would be a language *change*, not merely an addition >> or subtraction, and hence potentially fork-like. So we would want to >> consider very carefully whether that's the direction we want to take the >> language. >> >> But since that isn't part of the current proposal, and the current >> proposal is merely an optional subtraction, I don't think it's >> controversial. >> >> Cheers >> Simon >> >> On Thu, 7 Nov 2019 at 09:29, Joachim Breitner >> wrote: >> >>> Dear Committee, >>> >>> this is your secretary speaking: >>> >>> -XNoImplicitForAll >>> has been proposed by John Ericson >>> https://github.com/ghc-proposals/ghc-proposals/pull/285 >>> >>> https://github.com/Ericson2314/ghc-proposals/blob/no-implicit-forall/proposals/0000-no-implicit-forall.rst >>> >>> I propose Simon Marlow as the shepherd. >>> >>> Please reach consensus as described in >>> https://github.com/ghc-proposals/ghc-proposals#committee-process >>> I suggest you make a recommendation, in a new e-mail thread with the >>> proposal number in the subject, about the decision, maybe point out >>> debatable points, and assume that anyone who stays quiet agrees with >>> you. >>> >>> Thanks, >>> Joachim >>> -- >>> Joachim Breitner >>> mail at joachim-breitner.de >>> http://www.joachim-breitner.de/ >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Nov 14 13:50:11 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 14 Nov 2019 14:50:11 +0100 Subject: [ghc-steering-committee] Please review #246: Overloaded Quotations, Shepherd: Simon PJ Message-ID: <480e06e63243357c0ab4a72174394fb8f621c178.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: Overloaded Quotations has been proposed by Matthew Pickering https://github.com/ghc-proposals/ghc-proposals/pull/246 https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst I propose Simon PJ as the shepherd, as it seems he already had some in depth discussion about this proposal. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Fri Nov 15 10:20:15 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 15 Nov 2019 11:20:15 +0100 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: <23ae6a3a-94b3-4ec1-80c4-58b161221514@www.fastmail.com> References: <23ae6a3a-94b3-4ec1-80c4-58b161221514@www.fastmail.com> Message-ID: If there are no more issue to clear up, I'll mark this as accepted next week Monday. Please speak up, if you think otherwise. On Sat, Nov 9, 2019 at 7:22 PM Eric Seidel wrote: > > I'm also in Arnaud's boat. I support improving the usability of Typed TH, and the Code newtype looks like a step in that direction. So, assuming we can satisfy Simon and Richard's questions, I support acceptance. > > On Wed, Nov 6, 2019, at 03:46, Spiwack, Arnaud wrote: > > I understand that some details are lacking. But I don't think, whatever > > the details are, that they will affect my opinion of the proposal: they > > are over my knowledge of Template Haskell. > > > > This proposal seems well motivated. So, I'll count as an accept vote, > > when the details are eventually sorted out. > > > > On Tue, Nov 5, 2019 at 10:45 PM Richard Eisenberg wrote: > > > I'm in the same camp as Simon here -- I'm still a little murky on how `Code` will interact with `Q`. > > > > > > Richard > > > > > > > On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via ghc-steering-committee wrote: > > > > > > > > I'm basically supportive, but would like to see answers to my recent questions incorporated in the proposal before it is accepted. > > > > https://github.com/ghc-proposals/ghc-proposals/pull/195#issuecomment-547522510 > > > > > > > > Simon > > > > > > > > > > > > | -----Original Message----- > > > > | From: ghc-steering-committee > > > > | On Behalf Of Iavor Diatchki > > > > | Sent: 05 November 2019 16:44 > > > > | To: ghc-steering-committee > > > > | Subject: [ghc-steering-committee] #195 recommendation: accept > > > > | > > > > | Hello everyone, > > > > | > > > > | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a > > > > | newtype synonym `Code a`. The main change to the language is that the > > > > | special Template Haskell notation for typed splices will will work > > > > | with `Code a` rather than `Q (TExtp a)`. > > > > | > > > > | The benefit of having the newtype is that it makes it possible to > > > > | abstract over `Code`. For example, you can work with typed name > > > > | environments like `MapF Name Code`, where `MapF` is an "indexed" > > > > | variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in > > > > | package `parameterized-utils` on hackage). > > > > | > > > > | Making typed TH work with `Code` directly avoids the need to > > > > | constantly switch between `Code` and `Q (TExp a)` and with the new > > > > | system users of typed TH are not likely to deal with the latter much > > > > | at all. > > > > | > > > > | For these reasons I recommend that we accept this proposal. Please > > > > | let me know if you think otherwise. > > > > | > > > > | -Iavor > > > > | _______________________________________________ > > > > | ghc-steering-committee mailing list > > > > | ghc-steering-committee at haskell.org > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > > > > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > > > > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb > > > > | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 > > > > | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser > > > > | ved=0 > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > _______________________________________________ > 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 Nov 15 10:54:14 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 15 Nov 2019 10:54:14 +0000 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: <23ae6a3a-94b3-4ec1-80c4-58b161221514@www.fastmail.com> Message-ID: | If there are no more issue to clear up, I'll mark this as accepted | next week Monday. Please speak up, if you think otherwise. I'm speaking up! Before accepting a proposal, we should be content that the proposal itself stands by itself. Our protocol says that we'll push back (promptly) to "Please revise", in the constructive spirit of "we are going to accept this but want you to make the proposal clear first". This is not a big deal -- we are going to accept it! But I don’t want accept until the proposal is done. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Iavor Diatchki | Sent: 15 November 2019 10:20 | To: Eric Seidel | Cc: ghc-steering-committee | Subject: Re: [ghc-steering-committee] #195 recommendation: accept | | If there are no more issue to clear up, I'll mark this as accepted | next week Monday. Please speak up, if you think otherwise. | | On Sat, Nov 9, 2019 at 7:22 PM Eric Seidel wrote: | > | > I'm also in Arnaud's boat. I support improving the usability of Typed | TH, and the Code newtype looks like a step in that direction. So, assuming | we can satisfy Simon and Richard's questions, I support acceptance. | > | > On Wed, Nov 6, 2019, at 03:46, Spiwack, Arnaud wrote: | > > I understand that some details are lacking. But I don't think, | whatever | > > the details are, that they will affect my opinion of the proposal: | they | > > are over my knowledge of Template Haskell. | > > | > > This proposal seems well motivated. So, I'll count as an accept vote, | > > when the details are eventually sorted out. | > > | > > On Tue, Nov 5, 2019 at 10:45 PM Richard Eisenberg | wrote: | > > > I'm in the same camp as Simon here -- I'm still a little murky on | how `Code` will interact with `Q`. | > > > | > > > Richard | > > > | > > > > On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via ghc-steering- | committee wrote: | > > > > | > > > > I'm basically supportive, but would like to see answers to my | recent questions incorporated in the proposal before it is accepted. | > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fghc-proposals%2Fghc-proposals%2Fpull%2F195%23issuecomment- | 547522510&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 | 784&sdata=sFFuc3I0Tg2o6zhmji1SH6tYYwivp68IzQtPkL1P3aY%3D&reserved= | 0 | > > > > | > > > > Simon | > > > > | > > > > | > > > > | -----Original Message----- | > > > > | From: ghc-steering-committee | > > > > | On Behalf Of Iavor Diatchki | > > > > | Sent: 05 November 2019 16:44 | > > > > | To: ghc-steering-committee | > > > > | Subject: [ghc-steering-committee] #195 recommendation: accept | > > > > | | > > > > | Hello everyone, | > > > > | | > > > > | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` | into a | > > > > | newtype synonym `Code a`. The main change to the language is | that the | > > > > | special Template Haskell notation for typed splices will will | work | > > > > | with `Code a` rather than `Q (TExtp a)`. | > > > > | | > > > > | The benefit of having the newtype is that it makes it possible | to | > > > > | abstract over `Code`. For example, you can work with typed name | > > > > | environments like `MapF Name Code`, where `MapF` is an | "indexed" | > > > > | variant of `Map` which maps `Name a` to `Code a` (`MapF` is | defined in | > > > > | package `parameterized-utils` on hackage). | > > > > | | > > > > | Making typed TH work with `Code` directly avoids the need to | > > > > | constantly switch between `Code` and `Q (TExp a)` and with the | new | > > > > | system users of typed TH are not likely to deal with the latter | much | > > > > | at all. | > > > > | | > > > > | For these reasons I recommend that we accept this proposal. | Please | > > > > | let me know if you think otherwise. | > > > > | | > > > > | -Iavor | > > > > | _______________________________________________ | > > > > | ghc-steering-committee mailing list | > > > > | ghc-steering-committee at haskell.org | > > > > | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | > > > > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > > > > | | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb | > > > > | | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 | > > > > | | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser | > > > > | ved=0 | > > > > _______________________________________________ | > > > > ghc-steering-committee mailing list | > > > > ghc-steering-committee at haskell.org | > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve | d=0 | > > > | > > > _______________________________________________ | > > > ghc-steering-committee mailing list | > > > ghc-steering-committee at haskell.org | > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve | d=0 | > > _______________________________________________ | > > ghc-steering-committee mailing list | > > ghc-steering-committee at haskell.org | > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve | d=0 | > > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee at haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve | d=0 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225510 | 779&sdata=hd%2F%2Beh86VrymmU0pDgvtWz8iimoyppAywmkDDKZtE7U%3D&reser | ved=0 From rae at richarde.dev Fri Nov 15 17:26:17 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 15 Nov 2019 18:26:17 +0100 Subject: [ghc-steering-committee] #195 recommendation: accept In-Reply-To: References: <23ae6a3a-94b3-4ec1-80c4-58b161221514@www.fastmail.com> Message-ID: I wholeheartedly agree with Simon -- the proposal is not quite ready to accept, though we can signal to the author that we plan on accepting it once it's complete. Richard > On Nov 15, 2019, at 11:54 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > | If there are no more issue to clear up, I'll mark this as accepted > | next week Monday. Please speak up, if you think otherwise. > > I'm speaking up! Before accepting a proposal, we should be content that the proposal itself stands by itself. Our protocol says that we'll push back (promptly) to "Please revise", in the constructive spirit of "we are going to accept this but want you to make the proposal clear first". > > This is not a big deal -- we are going to accept it! But I don’t want accept until the proposal is done. > > Simon > > | -----Original Message----- > | From: ghc-steering-committee > | On Behalf Of Iavor Diatchki > | Sent: 15 November 2019 10:20 > | To: Eric Seidel > | Cc: ghc-steering-committee > | Subject: Re: [ghc-steering-committee] #195 recommendation: accept > | > | If there are no more issue to clear up, I'll mark this as accepted > | next week Monday. Please speak up, if you think otherwise. > | > | On Sat, Nov 9, 2019 at 7:22 PM Eric Seidel wrote: > | > > | > I'm also in Arnaud's boat. I support improving the usability of Typed > | TH, and the Code newtype looks like a step in that direction. So, assuming > | we can satisfy Simon and Richard's questions, I support acceptance. > | > > | > On Wed, Nov 6, 2019, at 03:46, Spiwack, Arnaud wrote: > | > > I understand that some details are lacking. But I don't think, > | whatever > | > > the details are, that they will affect my opinion of the proposal: > | they > | > > are over my knowledge of Template Haskell. > | > > > | > > This proposal seems well motivated. So, I'll count as an accept vote, > | > > when the details are eventually sorted out. > | > > > | > > On Tue, Nov 5, 2019 at 10:45 PM Richard Eisenberg > | wrote: > | > > > I'm in the same camp as Simon here -- I'm still a little murky on > | how `Code` will interact with `Q`. > | > > > > | > > > Richard > | > > > > | > > > > On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via ghc-steering- > | committee wrote: > | > > > > > | > > > > I'm basically supportive, but would like to see answers to my > | recent questions incorporated in the proposal before it is accepted. > | > > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c > | om%2Fghc-proposals%2Fghc-proposals%2Fpull%2F195%23issuecomment- > | 547522510&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce > | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 > | 784&sdata=sFFuc3I0Tg2o6zhmji1SH6tYYwivp68IzQtPkL1P3aY%3D&reserved= > | 0 > | > > > > > | > > > > Simon > | > > > > > | > > > > > | > > > > | -----Original Message----- > | > > > > | From: ghc-steering-committee | bounces at haskell.org> > | > > > > | On Behalf Of Iavor Diatchki > | > > > > | Sent: 05 November 2019 16:44 > | > > > > | To: ghc-steering-committee > | > > > > | Subject: [ghc-steering-committee] #195 recommendation: accept > | > > > > | > | > > > > | Hello everyone, > | > > > > | > | > > > > | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` > | into a > | > > > > | newtype synonym `Code a`. The main change to the language is > | that the > | > > > > | special Template Haskell notation for typed splices will will > | work > | > > > > | with `Code a` rather than `Q (TExtp a)`. > | > > > > | > | > > > > | The benefit of having the newtype is that it makes it possible > | to > | > > > > | abstract over `Code`. For example, you can work with typed name > | > > > > | environments like `MapF Name Code`, where `MapF` is an > | "indexed" > | > > > > | variant of `Map` which maps `Name a` to `Code a` (`MapF` is > | defined in > | > > > > | package `parameterized-utils` on hackage). > | > > > > | > | > > > > | Making typed TH work with `Code` directly avoids the need to > | > > > > | constantly switch between `Code` and `Q (TExp a)` and with the > | new > | > > > > | system users of typed TH are not likely to deal with the latter > | much > | > > > > | at all. > | > > > > | > | > > > > | For these reasons I recommend that we accept this proposal. > | Please > | > > > > | let me know if you think otherwise. > | > > > > | > | > > > > | -Iavor > | > > > > | _______________________________________________ > | > > > > | ghc-steering-committee mailing list > | > > > > | ghc-steering-committee at haskell.org > | > > > > | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | > > > > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | > > > > | > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb > | > > > > | > | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 > | > > > > | > | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser > | > > > > | ved=0 > | > > > > _______________________________________________ > | > > > > ghc-steering-committee mailing list > | > > > > ghc-steering-committee at haskell.org > | > > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce > | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 > | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve > | d=0 > | > > > > | > > > _______________________________________________ > | > > > ghc-steering-committee mailing list > | > > > ghc-steering-committee at haskell.org > | > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce > | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 > | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve > | d=0 > | > > _______________________________________________ > | > > ghc-steering-committee mailing list > | > > ghc-steering-committee at haskell.org > | > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce > | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 > | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve > | d=0 > | > > > | > _______________________________________________ > | > ghc-steering-committee mailing list > | > ghc-steering-committee at haskell.org > | > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce > | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 > | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve > | d=0 > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce > | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225510 > | 779&sdata=hd%2F%2Beh86VrymmU0pDgvtWz8iimoyppAywmkDDKZtE7U%3D&reser > | ved=0 > _______________________________________________ > 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 Sat Nov 16 10:26:07 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 16 Nov 2019 10:26:07 +0000 Subject: [ghc-steering-committee] Please review #246: Overloaded Quotations, Shepherd: Simon PJ In-Reply-To: <480e06e63243357c0ab4a72174394fb8f621c178.camel@joachim-breitner.de> References: <480e06e63243357c0ab4a72174394fb8f621c178.camel@joachim-breitner.de> Message-ID: Dear Committee For this proposal: Overloaded Quotations has been proposed by Matthew Pickering https://github.com/ghc-proposals/ghc-proposals/pull/246 https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst I propose that we accept. As you'll see in the discussion thread I have asked Matthew to clarify some issues, but I'd like to get a sense of the committee because I don't want him to invest a lot of effort if it'll be wasted. But I think it all seems like a useful generalisation. It accommodates what we do, and allows us to do more. This will make a modest difference for some, but a very big difference for a few. As far as I can tell, it will -- at worst -- require a bit of API generalisation for some users, but perhaps not many, so it scores well on the back-compat front. Opinions please. I rather dislike "silence as assent" because it allow us to dodge our responsibility to read proposals and form an opinion. So please express an opinion, even if you want to qualify it by saying you are no expert. Please try to do this within a week, and definitely no more than two. It's also fine to point to bits of the proposal that you did not understand or found hard going. The proposal will only become stronger if it is better presented. Add technical questions on the Github thread, and evaluative judgements here on the mailing list. Thanks Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 14 November 2019 13:50 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Please review #246: Overloaded | Quotations, Shepherd: Simon PJ | | Dear Committee, | | this is your secretary speaking: | | Overloaded Quotations | has been proposed by Matthew Pickering | https://github.com/ghc-proposals/ghc-proposals/pull/246 | https://github.com/mpickering/ghc-proposals/blob/overloaded- | proposal/proposals/0000-overloaded-bracket.rst | | I propose Simon PJ as the shepherd, as it seems he already had some in | depth discussion about this proposal. | | Please reach consensus as described in | https://github.com/ghc-proposals/ghc-proposals#committee-process | I suggest you make a recommendation, in a new e-mail thread with the | proposal number in the subject, about the decision, maybe point out | debatable points, and assume that anyone who stays quiet agrees with you. | | Thanks, | Joachim | -- | Joachim Breitner | mail at joachim-breitner.de | http://www.joachim-breitner.de/ From mail at joachim-breitner.de Sat Nov 16 11:35:50 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 16 Nov 2019 12:35:50 +0100 Subject: [ghc-steering-committee] Please review #246: Overloaded Quotations, Shepherd: Simon PJ In-Reply-To: References: <480e06e63243357c0ab4a72174394fb8f621c178.camel@joachim-breitner.de> Message-ID: <8021a7db53ec267e5feffb3dc37d5d139d5ab58e.camel@joachim-breitner.de> Hi, never having done much with TH, I usually refrain from commenting on TH-related proposals. But I found the motivation of the proposal, and the solution when viewed from a certain altitude, convincing. I’ll comment there with a quick question why the alternative is bad. Cheers, Joachim Am Samstag, den 16.11.2019, 10:26 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > Dear Committee > > For this proposal: > > Overloaded Quotations > has been proposed by Matthew Pickering > https://github.com/ghc-proposals/ghc-proposals/pull/246 > https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst > > I propose that we accept. As you'll see in the discussion thread I have asked Matthew to clarify some issues, but I'd like to get a sense of the committee because I don't want him to invest a lot of effort if it'll be wasted. > > But I think it all seems like a useful generalisation. It accommodates what we do, and allows us to do more. This will make a modest difference for some, but a very big difference for a few. As far as I can tell, it will -- at worst -- require a bit of API generalisation for some users, but perhaps not many, so it scores well on the back-compat front. > > Opinions please. I rather dislike "silence as assent" because it allow us to dodge our responsibility to read proposals and form an opinion. So please express an opinion, even if you want to qualify it by saying you are no expert. Please try to do this within a week, and definitely no more than two. > > It's also fine to point to bits of the proposal that you did not understand or found hard going. The proposal will only become stronger if it is better presented. > > Add technical questions on the Github thread, and evaluative judgements here on the mailing list. > > Thanks > > Simon > > > > -----Original Message----- > > From: ghc-steering-committee > > On Behalf Of Joachim Breitner > > Sent: 14 November 2019 13:50 > > To: ghc-steering-committee at haskell.org > > Subject: [ghc-steering-committee] Please review #246: Overloaded > > Quotations, Shepherd: Simon PJ > > > > Dear Committee, > > > > this is your secretary speaking: > > > > Overloaded Quotations > > has been proposed by Matthew Pickering > > https://github.com/ghc-proposals/ghc-proposals/pull/246 > > https://github.com/mpickering/ghc-proposals/blob/overloaded- > > proposal/proposals/0000-overloaded-bracket.rst > > > > I propose Simon PJ as the shepherd, as it seems he already had some in > > depth discussion about this proposal. > > > > Please reach consensus as described in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > I suggest you make a recommendation, in a new e-mail thread with the > > proposal number in the subject, about the decision, maybe point out > > debatable points, and assume that anyone who stays quiet agrees with you. > > > > Thanks, > > Joachim > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From bravit111 at gmail.com Sun Nov 17 14:44:01 2019 From: bravit111 at gmail.com (Vitaly Bragilevsky) Date: Sun, 17 Nov 2019 17:44:01 +0300 Subject: [ghc-steering-committee] Updated partial type signatures (#194) - recommendation: accept Message-ID: Hi everyone, Being the shepherd to the Updated partial type signatures proposal (#194, https://github.com/ghc-proposals/ghc-proposals/pull/194), I recommend acceptance. I've posted the rationale behind this recommendation on Github thread ( https://github.com/ghc-proposals/ghc-proposals/pull/194#issuecomment-554751379 ). In short: the proposal unifies the treatment of underscores and identifiers beginning with underscores everywhere outside patterns. It also brings more control to partial type signatures. Please, raise your voices here or there. As usual, silence is understood as an agreement. Vitaly -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Sun Nov 17 18:20:44 2019 From: eric at seidel.io (Eric Seidel) Date: Sun, 17 Nov 2019 13:20:44 -0500 Subject: [ghc-steering-committee] =?utf-8?q?Please_review_=23246=3A_Overlo?= =?utf-8?q?aded_Quotations=2C_Shepherd=3A_Simon_PJ?= In-Reply-To: <8021a7db53ec267e5feffb3dc37d5d139d5ab58e.camel@joachim-breitner.de> References: <480e06e63243357c0ab4a72174394fb8f621c178.camel@joachim-breitner.de> <8021a7db53ec267e5feffb3dc37d5d139d5ab58e.camel@joachim-breitner.de> Message-ID: I found both parts of the motivation compelling. I'm in support. On Sat, Nov 16, 2019, at 06:35, Joachim Breitner wrote: > Hi, > > never having done much with TH, I usually refrain from commenting on > TH-related proposals. But I found the motivation of the proposal, and > the solution when viewed from a certain altitude, convincing. > > I’ll comment there with a quick question why the alternative is bad. > > Cheers, > Joachim > > > Am Samstag, den 16.11.2019, 10:26 +0000 schrieb Simon Peyton Jones via > ghc-steering-committee: > > Dear Committee > > > > For this proposal: > > > > Overloaded Quotations > > has been proposed by Matthew Pickering > > https://github.com/ghc-proposals/ghc-proposals/pull/246 > > https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst > > > > I propose that we accept. As you'll see in the discussion thread I have asked Matthew to clarify some issues, but I'd like to get a sense of the committee because I don't want him to invest a lot of effort if it'll be wasted. > > > > But I think it all seems like a useful generalisation. It accommodates what we do, and allows us to do more. This will make a modest difference for some, but a very big difference for a few. As far as I can tell, it will -- at worst -- require a bit of API generalisation for some users, but perhaps not many, so it scores well on the back-compat front. > > > > Opinions please. I rather dislike "silence as assent" because it allow us to dodge our responsibility to read proposals and form an opinion. So please express an opinion, even if you want to qualify it by saying you are no expert. Please try to do this within a week, and definitely no more than two. > > > > It's also fine to point to bits of the proposal that you did not understand or found hard going. The proposal will only become stronger if it is better presented. > > > > Add technical questions on the Github thread, and evaluative judgements here on the mailing list. > > > > Thanks > > > > Simon > > > > > > > -----Original Message----- > > > From: ghc-steering-committee > > > On Behalf Of Joachim Breitner > > > Sent: 14 November 2019 13:50 > > > To: ghc-steering-committee at haskell.org > > > Subject: [ghc-steering-committee] Please review #246: Overloaded > > > Quotations, Shepherd: Simon PJ > > > > > > Dear Committee, > > > > > > this is your secretary speaking: > > > > > > Overloaded Quotations > > > has been proposed by Matthew Pickering > > > https://github.com/ghc-proposals/ghc-proposals/pull/246 > > > https://github.com/mpickering/ghc-proposals/blob/overloaded- > > > proposal/proposals/0000-overloaded-bracket.rst > > > > > > I propose Simon PJ as the shepherd, as it seems he already had some in > > > depth discussion about this proposal. > > > > > > Please reach consensus as described in > > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > I suggest you make a recommendation, in a new e-mail thread with the > > > proposal number in the subject, about the decision, maybe point out > > > debatable points, and assume that anyone who stays quiet agrees with you. > > > > > > Thanks, > > > Joachim > > > -- > > > Joachim Breitner > > > mail at joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > From sandy at sandymaguire.me Sun Nov 17 23:38:29 2019 From: sandy at sandymaguire.me (Sandy Maguire) Date: Mon, 18 Nov 2019 06:38:29 +0700 Subject: [ghc-steering-committee] Please review #246: Overloaded Quotations, Shepherd: Simon PJ In-Reply-To: References: <480e06e63243357c0ab4a72174394fb8f621c178.camel@joachim-breitner.de> <8021a7db53ec267e5feffb3dc37d5d139d5ab58e.camel@joachim-breitner.de> Message-ID: I'm strongly in support. On Mon, Nov 18, 2019 at 1:21 AM Eric Seidel wrote: > I found both parts of the motivation compelling. I'm in support. > > On Sat, Nov 16, 2019, at 06:35, Joachim Breitner wrote: > > Hi, > > > > never having done much with TH, I usually refrain from commenting on > > TH-related proposals. But I found the motivation of the proposal, and > > the solution when viewed from a certain altitude, convincing. > > > > I’ll comment there with a quick question why the alternative is bad. > > > > Cheers, > > Joachim > > > > > > Am Samstag, den 16.11.2019, 10:26 +0000 schrieb Simon Peyton Jones via > > ghc-steering-committee: > > > Dear Committee > > > > > > For this proposal: > > > > > > Overloaded Quotations > > > has been proposed by Matthew Pickering > > > https://github.com/ghc-proposals/ghc-proposals/pull/246 > > > > https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst > > > > > > I propose that we accept. As you'll see in the discussion thread I > have asked Matthew to clarify some issues, but I'd like to get a sense of > the committee because I don't want him to invest a lot of effort if it'll > be wasted. > > > > > > But I think it all seems like a useful generalisation. It > accommodates what we do, and allows us to do more. This will make a modest > difference for some, but a very big difference for a few. As far as I can > tell, it will -- at worst -- require a bit of API generalisation for some > users, but perhaps not many, so it scores well on the back-compat front. > > > > > > Opinions please. I rather dislike "silence as assent" because it > allow us to dodge our responsibility to read proposals and form an > opinion. So please express an opinion, even if you want to qualify it by > saying you are no expert. Please try to do this within a week, and > definitely no more than two. > > > > > > It's also fine to point to bits of the proposal that you did not > understand or found hard going. The proposal will only become stronger if > it is better presented. > > > > > > Add technical questions on the Github thread, and evaluative > judgements here on the mailing list. > > > > > > Thanks > > > > > > Simon > > > > > > > > > > -----Original Message----- > > > > From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> > > > > On Behalf Of Joachim Breitner > > > > Sent: 14 November 2019 13:50 > > > > To: ghc-steering-committee at haskell.org > > > > Subject: [ghc-steering-committee] Please review #246: Overloaded > > > > Quotations, Shepherd: Simon PJ > > > > > > > > Dear Committee, > > > > > > > > this is your secretary speaking: > > > > > > > > Overloaded Quotations > > > > has been proposed by Matthew Pickering > > > > https://github.com/ghc-proposals/ghc-proposals/pull/246 > > > > https://github.com/mpickering/ghc-proposals/blob/overloaded- > > > > proposal/proposals/0000-overloaded-bracket.rst > > > > > > > > I propose Simon PJ as the shepherd, as it seems he already had some > in > > > > depth discussion about this proposal. > > > > > > > > Please reach consensus as described in > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > I suggest you make a recommendation, in a new e-mail thread with the > > > > proposal number in the subject, about the decision, maybe point out > > > > debatable points, and assume that anyone who stays quiet agrees with > you. > > > > > > > > Thanks, > > > > Joachim > > > > -- > > > > Joachim Breitner > > > > mail at joachim-breitner.de > > > > http://www.joachim-breitner.de/ > > > > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > _______________________________________________ > > 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 > -- I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Nov 18 08:09:19 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 18 Nov 2019 08:09:19 +0000 Subject: [ghc-steering-committee] Please review #246: Overloaded Quotations, Shepherd: Simon PJ In-Reply-To: References: <480e06e63243357c0ab4a72174394fb8f621c178.camel@joachim-breitner.de> Message-ID: Seems like a good idea to me. I support it. On Sat, 16 Nov 2019 at 10:26, Simon Peyton Jones via ghc-steering-committee wrote: > Dear Committee > > For this proposal: > > Overloaded Quotations > has been proposed by Matthew Pickering > https://github.com/ghc-proposals/ghc-proposals/pull/246 > > https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst > > I propose that we accept. As you'll see in the discussion thread I have > asked Matthew to clarify some issues, but I'd like to get a sense of the > committee because I don't want him to invest a lot of effort if it'll be > wasted. > > But I think it all seems like a useful generalisation. It accommodates > what we do, and allows us to do more. This will make a modest difference > for some, but a very big difference for a few. As far as I can tell, it > will -- at worst -- require a bit of API generalisation for some users, but > perhaps not many, so it scores well on the back-compat front. > > Opinions please. I rather dislike "silence as assent" because it allow us > to dodge our responsibility to read proposals and form an opinion. So > please express an opinion, even if you want to qualify it by saying you are > no expert. Please try to do this within a week, and definitely no more > than two. > > It's also fine to point to bits of the proposal that you did not > understand or found hard going. The proposal will only become stronger if > it is better presented. > > Add technical questions on the Github thread, and evaluative judgements > here on the mailing list. > > Thanks > > Simon > > > | -----Original Message----- > | From: ghc-steering-committee > > | On Behalf Of Joachim Breitner > | Sent: 14 November 2019 13:50 > | To: ghc-steering-committee at haskell.org > | Subject: [ghc-steering-committee] Please review #246: Overloaded > | Quotations, Shepherd: Simon PJ > | > | Dear Committee, > | > | this is your secretary speaking: > | > | Overloaded Quotations > | has been proposed by Matthew Pickering > | https://github.com/ghc-proposals/ghc-proposals/pull/246 > | https://github.com/mpickering/ghc-proposals/blob/overloaded- > | proposal/proposals/0000-overloaded-bracket.rst > | > | I propose Simon PJ as the shepherd, as it seems he already had some in > | depth discussion about this proposal. > | > | Please reach consensus as described in > | https://github.com/ghc-proposals/ghc-proposals#committee-process > | I suggest you make a recommendation, in a new e-mail thread with the > | proposal number in the subject, about the decision, maybe point out > | debatable points, and assume that anyone who stays quiet agrees with you. > | > | Thanks, > | Joachim > | -- > | Joachim Breitner > | mail at joachim-breitner.de > | http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Nov 18 22:52:02 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 18 Nov 2019 22:52:02 +0000 Subject: [ghc-steering-committee] Please review #246: Overloaded Quotations, Shepherd: Simon PJ In-Reply-To: References: <480e06e63243357c0ab4a72174394fb8f621c178.camel@joachim-breitner.de> Message-ID: Yes -- I support. Richard > On Nov 18, 2019, at 8:09 AM, Simon Marlow wrote: > > Seems like a good idea to me. I support it. > > On Sat, 16 Nov 2019 at 10:26, Simon Peyton Jones via ghc-steering-committee > wrote: > Dear Committee > > For this proposal: > > Overloaded Quotations > has been proposed by Matthew Pickering > https://github.com/ghc-proposals/ghc-proposals/pull/246 > https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst > > I propose that we accept. As you'll see in the discussion thread I have asked Matthew to clarify some issues, but I'd like to get a sense of the committee because I don't want him to invest a lot of effort if it'll be wasted. > > But I think it all seems like a useful generalisation. It accommodates what we do, and allows us to do more. This will make a modest difference for some, but a very big difference for a few. As far as I can tell, it will -- at worst -- require a bit of API generalisation for some users, but perhaps not many, so it scores well on the back-compat front. > > Opinions please. I rather dislike "silence as assent" because it allow us to dodge our responsibility to read proposals and form an opinion. So please express an opinion, even if you want to qualify it by saying you are no expert. Please try to do this within a week, and definitely no more than two. > > It's also fine to point to bits of the proposal that you did not understand or found hard going. The proposal will only become stronger if it is better presented. > > Add technical questions on the Github thread, and evaluative judgements here on the mailing list. > > Thanks > > Simon > > > | -----Original Message----- > | From: ghc-steering-committee > > | On Behalf Of Joachim Breitner > | Sent: 14 November 2019 13:50 > | To: ghc-steering-committee at haskell.org > | Subject: [ghc-steering-committee] Please review #246: Overloaded > | Quotations, Shepherd: Simon PJ > | > | Dear Committee, > | > | this is your secretary speaking: > | > | Overloaded Quotations > | has been proposed by Matthew Pickering > | https://github.com/ghc-proposals/ghc-proposals/pull/246 > | https://github.com/mpickering/ghc-proposals/blob/overloaded- > | proposal/proposals/0000-overloaded-bracket.rst > | > | I propose Simon PJ as the shepherd, as it seems he already had some in > | depth discussion about this proposal. > | > | Please reach consensus as described in > | https://github.com/ghc-proposals/ghc-proposals#committee-process > | I suggest you make a recommendation, in a new e-mail thread with the > | proposal number in the subject, about the decision, maybe point out > | debatable points, and assume that anyone who stays quiet agrees with you. > | > | Thanks, > | Joachim > | -- > | Joachim Breitner > | mail at joachim-breitner.de > | http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Tue Nov 19 07:26:01 2019 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 19 Nov 2019 08:26:01 +0100 Subject: [ghc-steering-committee] Please review #246: Overloaded Quotations, Shepherd: Simon PJ In-Reply-To: References: <480e06e63243357c0ab4a72174394fb8f621c178.camel@joachim-breitner.de> Message-ID: I don't know much of Template Haskell, but from my standpoint, it looks like an API improvement. The costs appear to be minimal. So I support too. On Mon, Nov 18, 2019 at 11:52 PM Richard Eisenberg wrote: > Yes -- I support. > > Richard > > On Nov 18, 2019, at 8:09 AM, Simon Marlow wrote: > > Seems like a good idea to me. I support it. > > On Sat, 16 Nov 2019 at 10:26, Simon Peyton Jones via > ghc-steering-committee wrote: > >> Dear Committee >> >> For this proposal: >> >> Overloaded Quotations >> has been proposed by Matthew Pickering >> https://github.com/ghc-proposals/ghc-proposals/pull/246 >> >> https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst >> >> I propose that we accept. As you'll see in the discussion thread I have >> asked Matthew to clarify some issues, but I'd like to get a sense of the >> committee because I don't want him to invest a lot of effort if it'll be >> wasted. >> >> But I think it all seems like a useful generalisation. It accommodates >> what we do, and allows us to do more. This will make a modest difference >> for some, but a very big difference for a few. As far as I can tell, it >> will -- at worst -- require a bit of API generalisation for some users, but >> perhaps not many, so it scores well on the back-compat front. >> >> Opinions please. I rather dislike "silence as assent" because it allow >> us to dodge our responsibility to read proposals and form an opinion. So >> please express an opinion, even if you want to qualify it by saying you are >> no expert. Please try to do this within a week, and definitely no more >> than two. >> >> It's also fine to point to bits of the proposal that you did not >> understand or found hard going. The proposal will only become stronger if >> it is better presented. >> >> Add technical questions on the Github thread, and evaluative judgements >> here on the mailing list. >> >> Thanks >> >> Simon >> >> >> | -----Original Message----- >> | From: ghc-steering-committee < >> ghc-steering-committee-bounces at haskell.org> >> | On Behalf Of Joachim Breitner >> | Sent: 14 November 2019 13:50 >> | To: ghc-steering-committee at haskell.org >> | Subject: [ghc-steering-committee] Please review #246: Overloaded >> | Quotations, Shepherd: Simon PJ >> | >> | Dear Committee, >> | >> | this is your secretary speaking: >> | >> | Overloaded Quotations >> | has been proposed by Matthew Pickering >> | https://github.com/ghc-proposals/ghc-proposals/pull/246 >> | https://github.com/mpickering/ghc-proposals/blob/overloaded- >> | proposal/proposals/0000-overloaded-bracket.rst >> | >> | I propose Simon PJ as the shepherd, as it seems he already had some in >> | depth discussion about this proposal. >> | >> | Please reach consensus as described in >> | https://github.com/ghc-proposals/ghc-proposals#committee-process >> | I suggest you make a recommendation, in a new e-mail thread with the >> | proposal number in the subject, about the decision, maybe point out >> | debatable points, and assume that anyone who stays quiet agrees with >> you. >> | >> | Thanks, >> | Joachim >> | -- >> | Joachim Breitner >> | mail at joachim-breitner.de >> | http://www.joachim-breitner.de/ >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandy at sandymaguire.me Tue Nov 19 10:18:05 2019 From: sandy at sandymaguire.me (Sandy Maguire) Date: Tue, 19 Nov 2019 17:18:05 +0700 Subject: [ghc-steering-committee] Updated partial type signatures (#194) - recommendation: accept In-Reply-To: References: Message-ID: I'm *strongly against* this proposal due to its new semantics for expression-level `_`s. My argument is here: https://github.com/ghc-proposals/ghc-proposals/pull/194#issuecomment-555435625 On Sun, Nov 17, 2019 at 9:44 PM Vitaly Bragilevsky wrote: > Hi everyone, > > Being the shepherd to the Updated partial type signatures proposal (#194, > https://github.com/ghc-proposals/ghc-proposals/pull/194), I recommend > acceptance. I've posted the rationale behind this recommendation on Github > thread ( > https://github.com/ghc-proposals/ghc-proposals/pull/194#issuecomment-554751379 > ). > > In short: the proposal unifies the treatment of underscores and > identifiers beginning with underscores everywhere outside patterns. It also > brings more control to partial type signatures. > > Please, raise your voices here or there. As usual, silence is understood > as an agreement. > > Vitaly > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed Nov 20 15:10:05 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 20 Nov 2019 15:10:05 +0000 Subject: [ghc-steering-committee] Amendment #293; recommendation: accept Message-ID: <9805D147-1E3C-4873-BE32-C05FFC204037@richarde.dev> Hi committee, Vlad (@int-index) has written up #293, an amendment to an accepted proposal. Original proposal, as accepted: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst Diff: https://github.com/ghc-proposals/ghc-proposals/pull/293/files New proposal, as amended: https://github.com/int-index/ghc-proposals/blob/229-tweaks/proposals/0229-whitespace-bang-patterns.rst The changes are well summarised in Vlad's comment at https://github.com/ghc-proposals/ghc-proposals/pull/293#issue-341038277 My views are posted at https://github.com/ghc-proposals/ghc-proposals/pull/293#issuecomment-556043106 I recommend acceptance. Please thumbs-up my comment if you agree. Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Nov 20 16:49:08 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 20 Nov 2019 17:49:08 +0100 Subject: [ghc-steering-committee] Amendment #293; recommendation: accept In-Reply-To: <9805D147-1E3C-4873-BE32-C05FFC204037@richarde.dev> References: <9805D147-1E3C-4873-BE32-C05FFC204037@richarde.dev> Message-ID: <7125a2d779751fde56856cca0aa32ab914e653ec.camel@joachim-breitner.de> Hi, Am Mittwoch, den 20.11.2019, 15:10 +0000 schrieb Richard Eisenberg: > The changes are well summarised in Vlad's comment at https://github.com/ghc-proposals/ghc-proposals/pull/293#issue-341038277 based on that: 👍 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Wed Nov 20 20:55:35 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 20 Nov 2019 20:55:35 +0000 Subject: [ghc-steering-committee] Amendment #293; recommendation: accept In-Reply-To: <9805D147-1E3C-4873-BE32-C05FFC204037@richarde.dev> References: <9805D147-1E3C-4873-BE32-C05FFC204037@richarde.dev> Message-ID: I support. Simon From: ghc-steering-committee On Behalf Of Richard Eisenberg Sent: 20 November 2019 15:10 To: Simon Peyton Jones via ghc-steering-committee Subject: [ghc-steering-committee] Amendment #293; recommendation: accept Hi committee, Vlad (@int-index) has written up #293, an amendment to an accepted proposal. Original proposal, as accepted: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst Diff: https://github.com/ghc-proposals/ghc-proposals/pull/293/files New proposal, as amended: https://github.com/int-index/ghc-proposals/blob/229-tweaks/proposals/0229-whitespace-bang-patterns.rst The changes are well summarised in Vlad's comment at https://github.com/ghc-proposals/ghc-proposals/pull/293#issue-341038277 My views are posted at https://github.com/ghc-proposals/ghc-proposals/pull/293#issuecomment-556043106 I recommend acceptance. Please thumbs-up my comment if you agree. Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Fri Nov 22 17:23:23 2019 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 22 Nov 2019 09:23:23 -0800 Subject: [ghc-steering-committee] Please review #246: Overloaded Quotations, Shepherd: Simon PJ In-Reply-To: References: <480e06e63243357c0ab4a72174394fb8f621c178.camel@joachim-breitner.de> Message-ID: Hello, In general I think this is a good idea. However, in its current form this proposal clashes with #195, at least if we intend to also apply it to typed TH. The issue is that `Code a` is not `Applicative`, because we cannot define `pure` for all Haskell types. I wonder if the full power of `Applicative` is actually needed to do the translation though? If not, perhaps we should modify `Quote` to reflect the operations that we need. -Iavor On Mon, Nov 18, 2019 at 11:27 PM Spiwack, Arnaud wrote: > > I don't know much of Template Haskell, but from my standpoint, it looks like an API improvement. The costs appear to be minimal. So I support too. > > On Mon, Nov 18, 2019 at 11:52 PM Richard Eisenberg wrote: >> >> Yes -- I support. >> >> Richard >> >> On Nov 18, 2019, at 8:09 AM, Simon Marlow wrote: >> >> Seems like a good idea to me. I support it. >> >> On Sat, 16 Nov 2019 at 10:26, Simon Peyton Jones via ghc-steering-committee wrote: >>> >>> Dear Committee >>> >>> For this proposal: >>> >>> Overloaded Quotations >>> has been proposed by Matthew Pickering >>> https://github.com/ghc-proposals/ghc-proposals/pull/246 >>> https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/proposals/0000-overloaded-bracket.rst >>> >>> I propose that we accept. As you'll see in the discussion thread I have asked Matthew to clarify some issues, but I'd like to get a sense of the committee because I don't want him to invest a lot of effort if it'll be wasted. >>> >>> But I think it all seems like a useful generalisation. It accommodates what we do, and allows us to do more. This will make a modest difference for some, but a very big difference for a few. As far as I can tell, it will -- at worst -- require a bit of API generalisation for some users, but perhaps not many, so it scores well on the back-compat front. >>> >>> Opinions please. I rather dislike "silence as assent" because it allow us to dodge our responsibility to read proposals and form an opinion. So please express an opinion, even if you want to qualify it by saying you are no expert. Please try to do this within a week, and definitely no more than two. >>> >>> It's also fine to point to bits of the proposal that you did not understand or found hard going. The proposal will only become stronger if it is better presented. >>> >>> Add technical questions on the Github thread, and evaluative judgements here on the mailing list. >>> >>> Thanks >>> >>> Simon >>> >>> >>> | -----Original Message----- >>> | From: ghc-steering-committee >>> | On Behalf Of Joachim Breitner >>> | Sent: 14 November 2019 13:50 >>> | To: ghc-steering-committee at haskell.org >>> | Subject: [ghc-steering-committee] Please review #246: Overloaded >>> | Quotations, Shepherd: Simon PJ >>> | >>> | Dear Committee, >>> | >>> | this is your secretary speaking: >>> | >>> | Overloaded Quotations >>> | has been proposed by Matthew Pickering >>> | https://github.com/ghc-proposals/ghc-proposals/pull/246 >>> | https://github.com/mpickering/ghc-proposals/blob/overloaded- >>> | proposal/proposals/0000-overloaded-bracket.rst >>> | >>> | I propose Simon PJ as the shepherd, as it seems he already had some in >>> | depth discussion about this proposal. >>> | >>> | Please reach consensus as described in >>> | https://github.com/ghc-proposals/ghc-proposals#committee-process >>> | I suggest you make a recommendation, in a new e-mail thread with the >>> | proposal number in the subject, about the decision, maybe point out >>> | debatable points, and assume that anyone who stays quiet agrees with you. >>> | >>> | Thanks, >>> | Joachim >>> | -- >>> | Joachim Breitner >>> | mail at joachim-breitner.de >>> | http://www.joachim-breitner.de/ >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From eric at seidel.io Sat Nov 23 16:32:08 2019 From: eric at seidel.io (Eric Seidel) Date: Sat, 23 Nov 2019 11:32:08 -0500 Subject: [ghc-steering-committee] Proposal #273: Local Types, Recommendation: needs revision In-Reply-To: References: Message-ID: Hi all, I am the shepherd for proposal #273: Local Types (https://github.com/ghc-proposals/ghc-proposals/pull/273). This proposal would add support for local type and instance (class and type-family) definitions as a means of addressing the Configurations Problem, which as I understand it is essentially "How can we *implicitly* pass around dynamically determined values in a safe manner?" The `reflection` package provides an answer to this question with its `Reifies` class, but the implementation relies on `unsafeCoerce` and the implementation details of how GHC represents single-method class dictionaries. The proposal argues that we could safely implement the `reflection` package with local types and instances, if only Haskell had such things! As a motivation I find this pretty compelling. The proposal introduces a few restrictions on local types and instances, and functions that contain them, primarily as a means of providing a no-escape property: local types must not be able to escape their defining scope. There are a couple ways this could happen. (1) The defining function could return a value of some local type. This is prohibited unless the value is wrapped in an existential, as otherwise the function simply could not be typed. (2) More interestingly, a type class with a functional dependency or a type family could leak the local type to the outer scope. Consider the following: ``` type family F x foo x = x where data T type instance F Int = T bar :: F Int bar = ??? ``` What type should `bar` have? The proposal says that all instances are still global, which would mean `bar :: T`, which is absurd. To avoid cases like this, the proposal introduces a restriction on local instances that says local types may not be determined by types from an outer scope (either via fundeps or type families). I believe these two restrictions are sufficient to guarantee the no-escape property. I think the key question that is left unanswered by the proposal is how exactly we might implement local types in GHC. The proposal (as a guideline, not necessarily an implementation strategy) to think of local types as global types that are implicitly indexed by the type and value parameters of its defining function. But GHC does not yet have dependent types, so this is not a workable implementation strategy. Another possible strategy would be to add type/instance definitions to Core, but as Simon PJ points out this would be a tremendous amount of work, so also not a practical direction for the short-term. Lastly, Arnaud suggests that we treat local types like global types that are only defined in the local scope, i.e. let the renamer deal with them entirely. Local instances are different as they must capture locally-bound variables, but there's nothing conceptually difficult about constructing new instances dynamically (this is what ImplicitParams does). There are some remaining questions around how to ensure the optimizer doesn't incorrectly swap two instances for a local type, but these seem tractable. I think Arnaud's suggestion is a promising and feasible strategy for implementing this proposal without new research, so my recommendation is that we return the proposal for revision and recommend the author incorporate Arnaud's suggestions. As usual, please provide technical feedback on the PR, and feedback on my recommendation here on the mailing list. Eric On Mon, Nov 4, 2019, at 03:21, Joachim Breitner wrote: > Dear Committee, > > this is your secretary speaking: > > Local Types > has been updated by David Feuer > https://github.com/ghc-proposals/ghc-proposals/pull/273 > https://github.com/treeowl/ghc-proposals/blob/local-types/proposals/0000-local-types.md > > I propose Eric as the shepherd. > > Please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > I suggest you make a recommendation, in a new e-mail thread with the > proposal number in the subject, about the decision, maybe point out > debatable points, and assume that anyone who stays quiet agrees with > you. > > Thanks, > Joachim > -- > Joachim Breitner > mail 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 > > Attachments: > * signature.asc From mail at joachim-breitner.de Sat Nov 23 16:46:56 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 23 Nov 2019 17:46:56 +0100 Subject: [ghc-steering-committee] Proposal #273: Local Types, Recommendation: needs revision In-Reply-To: References: Message-ID: <8b95366b9466d27b1e4cc705f47b8946192d7c12.camel@joachim-breitner.de> Hi, thanks for the great summary. My gut feeling when looking at this from afar is “I’d love to have local types and instances, but surely it must be hard and expensive to add that to Haskell, else we would already have it, so this gotta be flawed”. But that is not a fair initial sentiment. A renamer-focused approach to local types + some support for local instances sound like a reasonable way forward. Cheers, Joachim Am Samstag, den 23.11.2019, 11:32 -0500 schrieb Eric Seidel: > Hi all, > > I am the shepherd for proposal #273: Local Types (https://github.com/ghc-proposals/ghc-proposals/pull/273). > > This proposal would add support for local type and instance (class and type-family) definitions as a means of addressing the Configurations Problem, which as I understand it is essentially "How can we *implicitly* pass around dynamically determined values in a safe manner?" The `reflection` package provides an answer to this question with its `Reifies` class, but the implementation relies on `unsafeCoerce` and the implementation details of how GHC represents single-method class dictionaries. The proposal argues that we could safely implement the `reflection` package with local types and instances, if only Haskell had such things! As a motivation I find this pretty compelling. > > The proposal introduces a few restrictions on local types and instances, and functions that contain them, primarily as a means of providing a no-escape property: local types must not be able to escape their defining scope. There are a couple ways this could happen. (1) The defining function could return a value of some local type. This is prohibited unless the value is wrapped in an existential, as otherwise the function simply could not be typed. (2) More interestingly, a type class with a functional dependency or a type family could leak the local type to the outer scope. Consider the following: > > ``` > type family F x > > foo x = x > where > data T > type instance F Int = T > > bar :: F Int > bar = ??? > ``` > > What type should `bar` have? The proposal says that all instances are still global, which would mean `bar :: T`, which is absurd. To avoid cases like this, the proposal introduces a restriction on local instances that says local types may not be determined by types from an outer scope (either via fundeps or type families). I believe these two restrictions are sufficient to guarantee the no-escape property. > > I think the key question that is left unanswered by the proposal is how exactly we might implement local types in GHC. The proposal (as a guideline, not necessarily an implementation strategy) to think of local types as global types that are implicitly indexed by the type and value parameters of its defining function. But GHC does not yet have dependent types, so this is not a workable implementation strategy. Another possible strategy would be to add type/instance definitions to Core, but as Simon PJ points out this would be a tremendous amount of work, so also not a practical direction for the short-term. Lastly, Arnaud suggests that we treat local types like global types that are only defined in the local scope, i.e. let the renamer deal with them entirely. Local instances are different as they must capture locally-bound variables, but there's nothing conceptually difficult about constructing new instances dynamically (this is what ImplicitParams does). There are some remaining questions around how to ensure the optimizer doesn't incorrectly swap two instances for a local type, but these seem tractable. > > I think Arnaud's suggestion is a promising and feasible strategy for implementing this proposal without new research, so my recommendation is that we return the proposal for revision and recommend the author incorporate Arnaud's suggestions. > > As usual, please provide technical feedback on the PR, and feedback on my recommendation here on the mailing list. > > Eric > > On Mon, Nov 4, 2019, at 03:21, Joachim Breitner wrote: > > Dear Committee, > > > > this is your secretary speaking: > > > > Local Types > > has been updated by David Feuer > > https://github.com/ghc-proposals/ghc-proposals/pull/273 > > https://github.com/treeowl/ghc-proposals/blob/local-types/proposals/0000-local-types.md > > > > I propose Eric as the shepherd. > > > > Please reach consensus as described in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > I suggest you make a recommendation, in a new e-mail thread with the > > proposal number in the subject, about the decision, maybe point out > > debatable points, and assume that anyone who stays quiet agrees with > > you. > > > > Thanks, > > Joachim > > -- > > Joachim Breitner > > mail 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 > > > > Attachments: > > * signature.asc > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From marlowsd at gmail.com Mon Nov 25 08:15:46 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 25 Nov 2019 08:15:46 +0000 Subject: [ghc-steering-committee] Proposal #273: Local Types, Recommendation: needs revision In-Reply-To: References: Message-ID: Having written a little C++ recently (yeah I know) where you can have local type definitions, it feels entirely natural and I started to notice the lack of them in Haskell. So I support the proposal. My intuition is that we ought to be able to treat local types in the same way as local variables: they are entities with scoping rules enforced by the renamer. That is, a local type would be an ordinary TyCon with a Name and so forth. Having only read your email and not the proposal, that sounds the same as Arnuad's suggestion. Cheers Simon On Sat, 23 Nov 2019 at 16:32, Eric Seidel wrote: > Hi all, > > I am the shepherd for proposal #273: Local Types ( > https://github.com/ghc-proposals/ghc-proposals/pull/273). > > This proposal would add support for local type and instance (class and > type-family) definitions as a means of addressing the Configurations > Problem, which as I understand it is essentially "How can we *implicitly* > pass around dynamically determined values in a safe manner?" The > `reflection` package provides an answer to this question with its `Reifies` > class, but the implementation relies on `unsafeCoerce` and the > implementation details of how GHC represents single-method class > dictionaries. The proposal argues that we could safely implement the > `reflection` package with local types and instances, if only Haskell had > such things! As a motivation I find this pretty compelling. > > The proposal introduces a few restrictions on local types and instances, > and functions that contain them, primarily as a means of providing a > no-escape property: local types must not be able to escape their defining > scope. There are a couple ways this could happen. (1) The defining function > could return a value of some local type. This is prohibited unless the > value is wrapped in an existential, as otherwise the function simply could > not be typed. (2) More interestingly, a type class with a functional > dependency or a type family could leak the local type to the outer scope. > Consider the following: > > ``` > type family F x > > foo x = x > where > data T > type instance F Int = T > > bar :: F Int > bar = ??? > ``` > > What type should `bar` have? The proposal says that all instances are > still global, which would mean `bar :: T`, which is absurd. To avoid cases > like this, the proposal introduces a restriction on local instances that > says local types may not be determined by types from an outer scope (either > via fundeps or type families). I believe these two restrictions are > sufficient to guarantee the no-escape property. > > I think the key question that is left unanswered by the proposal is how > exactly we might implement local types in GHC. The proposal (as a > guideline, not necessarily an implementation strategy) to think of local > types as global types that are implicitly indexed by the type and value > parameters of its defining function. But GHC does not yet have dependent > types, so this is not a workable implementation strategy. Another possible > strategy would be to add type/instance definitions to Core, but as Simon PJ > points out this would be a tremendous amount of work, so also not a > practical direction for the short-term. Lastly, Arnaud suggests that we > treat local types like global types that are only defined in the local > scope, i.e. let the renamer deal with them entirely. Local instances are > different as they must capture locally-bound variables, but there's nothing > conceptually difficult about constructing new instances dynamically (this > is what ImplicitParams does). There are some remaining questions around how > to ensure the optimizer doesn't incorrectly swap two instances for a local > type, but these seem tractable. > > I think Arnaud's suggestion is a promising and feasible strategy for > implementing this proposal without new research, so my recommendation is > that we return the proposal for revision and recommend the author > incorporate Arnaud's suggestions. > > As usual, please provide technical feedback on the PR, and feedback on my > recommendation here on the mailing list. > > Eric > > On Mon, Nov 4, 2019, at 03:21, Joachim Breitner wrote: > > Dear Committee, > > > > this is your secretary speaking: > > > > Local Types > > has been updated by David Feuer > > https://github.com/ghc-proposals/ghc-proposals/pull/273 > > > https://github.com/treeowl/ghc-proposals/blob/local-types/proposals/0000-local-types.md > > > > I propose Eric as the shepherd. > > > > Please reach consensus as described in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > I suggest you make a recommendation, in a new e-mail thread with the > > proposal number in the subject, about the decision, maybe point out > > debatable points, and assume that anyone who stays quiet agrees with > > you. > > > > Thanks, > > Joachim > > -- > > Joachim Breitner > > mail 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 > > > > Attachments: > > * signature.asc > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Nov 25 10:38:27 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 25 Nov 2019 10:38:27 +0000 Subject: [ghc-steering-committee] Proposal #273: Local Types, Recommendation: needs revision In-Reply-To: References: Message-ID: <1CF90F56-F650-4062-B27A-9ED49D2BAA65@richarde.dev> I have posted on the ticket. The proposal text as it now stands does not support the idea of "just in the renamer", and I find the motivation lacking. Do we need all this power just to write `reflection`? Seems like overkill. Yes, I agree that local types would often be nice. But would that nicety be covered by local modules (either proposal)? Richard > On Nov 25, 2019, at 8:15 AM, Simon Marlow wrote: > > Having written a little C++ recently (yeah I know) where you can have local type definitions, it feels entirely natural and I started to notice the lack of them in Haskell. So I support the proposal. > > My intuition is that we ought to be able to treat local types in the same way as local variables: they are entities with scoping rules enforced by the renamer. That is, a local type would be an ordinary TyCon with a Name and so forth. Having only read your email and not the proposal, that sounds the same as Arnuad's suggestion. > > Cheers > Simon > > > On Sat, 23 Nov 2019 at 16:32, Eric Seidel > wrote: > Hi all, > > I am the shepherd for proposal #273: Local Types (https://github.com/ghc-proposals/ghc-proposals/pull/273 ). > > This proposal would add support for local type and instance (class and type-family) definitions as a means of addressing the Configurations Problem, which as I understand it is essentially "How can we *implicitly* pass around dynamically determined values in a safe manner?" The `reflection` package provides an answer to this question with its `Reifies` class, but the implementation relies on `unsafeCoerce` and the implementation details of how GHC represents single-method class dictionaries. The proposal argues that we could safely implement the `reflection` package with local types and instances, if only Haskell had such things! As a motivation I find this pretty compelling. > > The proposal introduces a few restrictions on local types and instances, and functions that contain them, primarily as a means of providing a no-escape property: local types must not be able to escape their defining scope. There are a couple ways this could happen. (1) The defining function could return a value of some local type. This is prohibited unless the value is wrapped in an existential, as otherwise the function simply could not be typed. (2) More interestingly, a type class with a functional dependency or a type family could leak the local type to the outer scope. Consider the following: > > ``` > type family F x > > foo x = x > where > data T > type instance F Int = T > > bar :: F Int > bar = ??? > ``` > > What type should `bar` have? The proposal says that all instances are still global, which would mean `bar :: T`, which is absurd. To avoid cases like this, the proposal introduces a restriction on local instances that says local types may not be determined by types from an outer scope (either via fundeps or type families). I believe these two restrictions are sufficient to guarantee the no-escape property. > > I think the key question that is left unanswered by the proposal is how exactly we might implement local types in GHC. The proposal (as a guideline, not necessarily an implementation strategy) to think of local types as global types that are implicitly indexed by the type and value parameters of its defining function. But GHC does not yet have dependent types, so this is not a workable implementation strategy. Another possible strategy would be to add type/instance definitions to Core, but as Simon PJ points out this would be a tremendous amount of work, so also not a practical direction for the short-term. Lastly, Arnaud suggests that we treat local types like global types that are only defined in the local scope, i.e. let the renamer deal with them entirely. Local instances are different as they must capture locally-bound variables, but there's nothing conceptually difficult about constructing new instances dynamically (this is what ImplicitParams does). There are some remaining questions around how to ensure the optimizer doesn't incorrectly swap two instances for a local type, but these seem tractable. > > I think Arnaud's suggestion is a promising and feasible strategy for implementing this proposal without new research, so my recommendation is that we return the proposal for revision and recommend the author incorporate Arnaud's suggestions. > > As usual, please provide technical feedback on the PR, and feedback on my recommendation here on the mailing list. > > Eric > > On Mon, Nov 4, 2019, at 03:21, Joachim Breitner wrote: > > Dear Committee, > > > > this is your secretary speaking: > > > > Local Types > > has been updated by David Feuer > > https://github.com/ghc-proposals/ghc-proposals/pull/273 > > https://github.com/treeowl/ghc-proposals/blob/local-types/proposals/0000-local-types.md > > > > I propose Eric as the shepherd. > > > > Please reach consensus as described in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > I suggest you make a recommendation, in a new e-mail thread with the > > proposal number in the subject, about the decision, maybe point out > > debatable points, and assume that anyone who stays quiet agrees with > > you. > > > > Thanks, > > Joachim > > -- > > Joachim Breitner > > mail 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 > > > > Attachments: > > * signature.asc > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Mon Nov 25 11:16:40 2019 From: marlowsd at gmail.com (Simon Marlow) Date: Mon, 25 Nov 2019 11:16:40 +0000 Subject: [ghc-steering-committee] Updated partial type signatures (#194) - recommendation: accept In-Reply-To: References: Message-ID: I read the proposal in full today. * I think I like the idea of explicit syntax for partial type signatures * Elision in types doesn't seem all that useful, yet it occupies prime syntactic real estate. I thought about this for a while and I don't have any alternative suggestions unfortunately. Cheers Simon On Sun, 17 Nov 2019 at 14:44, Vitaly Bragilevsky wrote: > Hi everyone, > > Being the shepherd to the Updated partial type signatures proposal (#194, > https://github.com/ghc-proposals/ghc-proposals/pull/194), I recommend > acceptance. I've posted the rationale behind this recommendation on Github > thread ( > https://github.com/ghc-proposals/ghc-proposals/pull/194#issuecomment-554751379 > ). > > In short: the proposal unifies the treatment of underscores and > identifiers beginning with underscores everywhere outside patterns. It also > brings more control to partial type signatures. > > Please, raise your voices here or there. As usual, silence is understood > as an agreement. > > Vitaly > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon Nov 25 11:20:32 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 25 Nov 2019 11:20:32 +0000 Subject: [ghc-steering-committee] Updated partial type signatures (#194) - recommendation: accept In-Reply-To: References: Message-ID: <1F231E03-D54E-4F41-BE4C-7A6A0AA50F8C@richarde.dev> > On Nov 25, 2019, at 11:16 AM, Simon Marlow wrote: > > * Elision in types doesn't seem all that useful, yet it occupies prime syntactic real estate. I thought about this for a while and I don't have any alternative suggestions unfortunately. > For what it's worth, I completely agree here. However, we Haskellers seem to like being able to say `const x _ = x`. Being able to write an underscore there is nice, and we would sorely miss its absence. Why don't we feel the same about `const :: a -> _ -> a`? Maybe it's that we're not used to it? I agree that I don't feel the same about these two elisions, but I can't articulate why. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Mon Nov 25 13:44:27 2019 From: eric at seidel.io (Eric Seidel) Date: Mon, 25 Nov 2019 08:44:27 -0500 Subject: [ghc-steering-committee] =?utf-8?q?Proposal_=23273=3A_Local_Types?= =?utf-8?q?=2C_Recommendation=3A_needs_revision?= In-Reply-To: <1CF90F56-F650-4062-B27A-9ED49D2BAA65@richarde.dev> References: <1CF90F56-F650-4062-B27A-9ED49D2BAA65@richarde.dev> Message-ID: <69ad592f-6da2-4025-a2d2-e480858b8ceb@www.fastmail.com> On Mon, Nov 25, 2019, at 05:38, Richard Eisenberg wrote: > I have posted on the ticket. The proposal text as it now stands does > not support the idea of "just in the renamer", and I find the > motivation lacking. Do we need all this power just to write > `reflection`? Seems like overkill. > > Yes, I agree that local types would often be nice. But would that > nicety be covered by local modules (either proposal)? The motivating example here seems like it would require parameterized modules, ie something akin to ML functors. Neither local module proposal currently includes parameterized modules. From rae at richarde.dev Mon Nov 25 17:00:41 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 25 Nov 2019 17:00:41 +0000 Subject: [ghc-steering-committee] Proposal #273: Local Types, Recommendation: needs revision In-Reply-To: <69ad592f-6da2-4025-a2d2-e480858b8ceb@www.fastmail.com> References: <1CF90F56-F650-4062-B27A-9ED49D2BAA65@richarde.dev> <69ad592f-6da2-4025-a2d2-e480858b8ceb@www.fastmail.com> Message-ID: I mis-summarized my GitHub comment. I agree that the local modules proposals do not cover `reflection` and brought up a strawman counterproposal just to support `reflection` (and similar usages of classes); the local modules proposals cover the rest of the "would be nice" aspect of local types, in my opinion. Richard > On Nov 25, 2019, at 1:44 PM, Eric Seidel wrote: > > On Mon, Nov 25, 2019, at 05:38, Richard Eisenberg wrote: >> I have posted on the ticket. The proposal text as it now stands does >> not support the idea of "just in the renamer", and I find the >> motivation lacking. Do we need all this power just to write >> `reflection`? Seems like overkill. >> >> Yes, I agree that local types would often be nice. But would that >> nicety be covered by local modules (either proposal)? > > The motivating example here seems like it would require parameterized modules, ie something akin to ML functors. Neither local module proposal currently includes parameterized modules. > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From sandy at sandymaguire.me Tue Nov 26 05:46:48 2019 From: sandy at sandymaguire.me (Sandy Maguire) Date: Tue, 26 Nov 2019 12:46:48 +0700 Subject: [ghc-steering-committee] Proposal #273: Local Types, Recommendation: needs revision In-Reply-To: References: <1CF90F56-F650-4062-B27A-9ED49D2BAA65@richarde.dev> <69ad592f-6da2-4025-a2d2-e480858b8ceb@www.fastmail.com> Message-ID: I'm not particularly convinced by the motivation here, and lean towards a weak "no." On Tue, Nov 26, 2019 at 12:00 AM Richard Eisenberg wrote: > I mis-summarized my GitHub comment. I agree that the local modules > proposals do not cover `reflection` and brought up a strawman > counterproposal just to support `reflection` (and similar usages of > classes); the local modules proposals cover the rest of the "would be nice" > aspect of local types, in my opinion. > > Richard > > > On Nov 25, 2019, at 1:44 PM, Eric Seidel wrote: > > > > On Mon, Nov 25, 2019, at 05:38, Richard Eisenberg wrote: > >> I have posted on the ticket. The proposal text as it now stands does > >> not support the idea of "just in the renamer", and I find the > >> motivation lacking. Do we need all this power just to write > >> `reflection`? Seems like overkill. > >> > >> Yes, I agree that local types would often be nice. But would that > >> nicety be covered by local modules (either proposal)? > > > > The motivating example here seems like it would require parameterized > modules, ie something akin to ML functors. Neither local module proposal > currently includes parameterized modules. > > _______________________________________________ > > 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 > -- I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandy at sandymaguire.me Tue Nov 26 12:39:57 2019 From: sandy at sandymaguire.me (Sandy Maguire) Date: Tue, 26 Nov 2019 19:39:57 +0700 Subject: [ghc-steering-committee] Managing github notifications? Message-ID: Hi all, I'm wondering if anyone has a good strategy for dealing with github noise. Right now I feel like I need to choose between silence and overwhelming volume, and neither is good for me to do my job on this committee. I'd like to be informed when someone opens a new proposal PR in order to read it, but not for any of the follow-up commentary. As best I can tell, there is no github option that allows for this. Any advice on this would be greatly appreciated. Thanks, Sandy -- I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Tue Nov 26 12:54:59 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 26 Nov 2019 12:54:59 +0000 Subject: [ghc-steering-committee] Managing github notifications? In-Reply-To: References: Message-ID: Hi Sandy, I sympathize. Here is my workflow: - I have a dedicated email account just for proposals traffic. This email gets all notifications -- both from new and old proposals. - I have an email filter to flag any posts that mention @goldfirere. - I separately have an email filter to flag (different color) any proposals with "under review" in the title (as described under https://github.com/ghc-proposals/ghc-proposals/#committee-process ) - I am quick with the "delete" button on proposals I recognize (they're not new) but am not currently following. It's not perfect. But I find it tolerable. Richard > On Nov 26, 2019, at 12:39 PM, Sandy Maguire wrote: > > Hi all, > > I'm wondering if anyone has a good strategy for dealing with github noise. Right now I feel like I need to choose between silence and overwhelming volume, and neither is good for me to do my job on this committee. > > I'd like to be informed when someone opens a new proposal PR in order to read it, but not for any of the follow-up commentary. As best I can tell, there is no github option that allows for this. > > Any advice on this would be greatly appreciated. > > Thanks, > Sandy > > -- > I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Nov 26 14:06:10 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 26 Nov 2019 15:06:10 +0100 Subject: [ghc-steering-committee] Managing github notifications? In-Reply-To: References: Message-ID: <2432a98b4f64a5c82b3e320991393ba9c2f9a80d.camel@joachim-breitner.de> Hi, Am Dienstag, den 26.11.2019, 19:39 +0700 schrieb Sandy Maguire: > Hi all, > > I'm wondering if anyone has a good strategy for dealing with github > noise. Right now I feel like I need to choose between silence and > overwhelming volume, and neither is good for me to do my job on this > committee. > > I'd like to be informed when someone opens a new proposal PR in order > to read it, but not for any of the follow-up commentary. As best I > can tell, there is no github option that allows for this. > > Any advice on this would be greatly appreciated. * I follow the repository, so by default I get mails * I filter the ghc-proposals-related GitHub mails into a separate folder – but not because they are too many, but because I want to be able to “mark all as read” in my GitHub folder without losing proposals mail. * If a proposal gets too noisy or doesn’t interest me, I click the “unsubscribe” link at the bottom. GitHub will automatically re-subs cribe me if my name, or the name of the team. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Thu Nov 28 10:06:37 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 28 Nov 2019 11:06:37 +0100 Subject: [ghc-steering-committee] Please review #265: Unlifted Datatypes, Shepherd: Simon Marlow Message-ID: <832fb9c5c2c9084a44e47afc19cb302fefe28e59.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000-unlifted-datatypes.rst I propose Simon Marlow as the shepherd, as the expert on low-level stuff. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Thu Nov 28 10:10:30 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 28 Nov 2019 11:10:30 +0100 Subject: [ghc-steering-committee] Please review #282: RecordDotSyntax, Shepherd: Simon PJ Message-ID: <410ef7616127b66f32aeb7e0dd23c6d3c77c1f4a.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: RecordDotSyntax language extension proposal has been proposed by Neil Mitchell and Shayne Fletcher https://github.com/ghc-proposals/ghc-proposals/pull/282 https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/proposals/0000-record-dot-syntax.md This is going to be a tricky one. It is partly about whitespace, so it has attracted a _lot_ of community interest, by far the most so far. To navigate that ship, I propose Simon PJ as the shepherd, because he is a excellent moderator and community manager, and because he has the necessary authority to hopefully get a verdict accepted. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/