From mail at joachim-breitner.de Fri May 1 09:03:47 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 01 May 2020 11:03:47 +0200 Subject: [ghc-steering-committee] Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel Message-ID: Dear Committee, this is your secretary speaking: NoFallibleDo proposal has been proposed by Cale https://github.com/ghc-proposals/ghc-proposals/pull/319 https://github.com/obsidiansystems/ghc-proposals/blob/no-fallible-do/proposals/0000-no-fallible-do.rst I propose Eric Seidel as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Sat May 2 09:36:06 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 02 May 2020 11:36:06 +0200 Subject: [ghc-steering-committee] Please review #320: clsdfltassoctypinst in bckpck&.hs-boot, Shepherd: Richard Eisenberg Message-ID: Dear Committee, this is your secretary speaking: Ignore class defaults for associated type instances in instances that occur in backpack and hs-boot files (a title too long for the email subject line) has been proposed by Cale https://github.com/ghc-proposals/ghc-proposals/pull/320 https://github.com/obsidiansystems/ghc-proposals/blob/signature-type-instances/proposals/0000-signature-instances.md I propose Richard Eisenberg as the shepherd, as he looked at it before. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Sat May 2 09:39:31 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 02 May 2020 11:39:31 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: Dear Committee, it seems discussion has ebbed down. Are there any new arguments that can be brought forward? Did anyone have a change of mind which would bring us closer to (or farther away from) consensus? Or should we vote? Simon Marlow, Chris, Cale, Tom: You have not stated an opinion. Do you have one? Cheers, Joachim Am Mittwoch, den 22.04.2020, 12:26 +0200 schrieb Joachim Breitner: > Dear Committe, > > trying to summarize the discussion here. > > The main decision seems to be: Record based or module based. > > Record based is preferred by: > Arnaud (one of the authors), SPJ > > Module based is preferred by: > Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro, > me > > This is not a vote, merely a summary of sentimenss. But it seems that > maybe the onus to make stronger arguments for the record-based approach > is on Simon and Arnaud? > > > Related to the module based variant, there was some discussion about > whether the > * desugaring should go to a “qualified name”, that is then resolved > like any manually written name > (i.e. could conceptually be done in the parser) > * or if it should go directly a suitable “original name” of a suitable > function, even if not explicitly imported > (i.e. could conceptually be done in the renamer, but not the parser) > > I initially advocated for the latter, arguing with a “you shall not > have to import stuff you do not write explicitly” rule. > But Simon’s recent argument that > > import qualified Monad as M > > (i.e. _with_ qualification, but _without_ an import list) will give the > developer a good user experience, and if they try to do things like > > import Monad as M (runMonad) > … M.do … > > then, well, they shouldn’t. So I am happy to advocate for the module > based approach with the “must be in scope” rule. But maybe we should > keep the focus more on the fundamental question above. > > > > We could keep in mind that eventually, people will ask for M.if; M.[ > and other “qualified syntax”. But it seems that that will work equally > well with either choice here. > > Cheers, > Joachim > > -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From cgibbard at gmail.com Sat May 2 09:54:30 2020 From: cgibbard at gmail.com (Cale Gibbard) Date: Sat, 2 May 2020 05:54:30 -0400 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: I greatly prefer the earlier module-based version of this where the definitions of the relevant functions are simply obtained from the qualified module and we don't have to talk about fully-settled types to explain how expressions are going to desugar. Even if it's not quite true in the case of GHC's internals that desugaring comes entirely before typechecking, I think it's really very helpful in both understanding the language ourselves and in explaining it to beginners if we can at least think about it that way. The more that the translation from surface syntax to core factors into a bunch of individually comprehensible translations, the better. On Sat, 2 May 2020 at 05:39, Joachim Breitner wrote: > > Dear Committee, > > it seems discussion has ebbed down. Are there any new arguments that > can be brought forward? Did anyone have a change of mind which would > bring us closer to (or farther away from) consensus? Or should we vote? > > Simon Marlow, Chris, Cale, Tom: > You have not stated an opinion. Do you have one? > > Cheers, > Joachim > > Am Mittwoch, den 22.04.2020, 12:26 +0200 schrieb Joachim Breitner: > > Dear Committe, > > > > trying to summarize the discussion here. > > > > The main decision seems to be: Record based or module based. > > > > Record based is preferred by: > > Arnaud (one of the authors), SPJ > > > > Module based is preferred by: > > Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro, > > me > > > > This is not a vote, merely a summary of sentimenss. But it seems that > > maybe the onus to make stronger arguments for the record-based approach > > is on Simon and Arnaud? > > > > > > Related to the module based variant, there was some discussion about > > whether the > > * desugaring should go to a “qualified name”, that is then resolved > > like any manually written name > > (i.e. could conceptually be done in the parser) > > * or if it should go directly a suitable “original name” of a suitable > > function, even if not explicitly imported > > (i.e. could conceptually be done in the renamer, but not the parser) > > > > I initially advocated for the latter, arguing with a “you shall not > > have to import stuff you do not write explicitly” rule. > > But Simon’s recent argument that > > > > import qualified Monad as M > > > > (i.e. _with_ qualification, but _without_ an import list) will give the > > developer a good user experience, and if they try to do things like > > > > import Monad as M (runMonad) > > … M.do … > > > > then, well, they shouldn’t. So I am happy to advocate for the module > > based approach with the “must be in scope” rule. But maybe we should > > keep the focus more on the fundamental question above. > > > > > > > > We could keep in mind that eventually, people will ask for M.if; M.[ > > and other “qualified syntax”. But it seems that that will work equally > > well with either choice here. > > > > Cheers, > > Joachim > > > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Sun May 3 11:21:32 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 03 May 2020 13:21:32 +0200 Subject: [ghc-steering-committee] #285: -XNoImplicitForAll, recommendation: accept In-Reply-To: References: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de> Message-ID: <7c7ede815f1c20a3619ab40ecc0b550ccf079ce9.camel@joachim-breitner.de> Hi, Am Montag, den 20.01.2020, 08:37 +0000 schrieb Simon Marlow: > Proposal #285 is currently under consideration: > https://github.com/ghc-proposals/ghc-proposals/pull/285 > > I previously recommended acceptance, and there was some followup > discussion on the GitHub thread where Simon PJ and Arnaud requested > changes. The changes, namely clarifications and more examples, have > all been implemented and those that requested changes have signed > off. > > I think we can accept the proposal now. Any final concerns? looks like this never happened, and Arnaud was the last to comment, and said “if I'm alone in this, I'm not going to argue further.”. Simon M, if you tell me so, I’ll merge it as accepted. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Sun May 3 11:31:28 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 03 May 2020 13:31:28 +0200 Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals] RecordDotSyntax language extension proposal (#282) In-Reply-To: References: Message-ID: <68c2f18bd55aae661a546ce08cc56e02afd01fcb.camel@joachim-breitner.de> Hi, Am Freitag, den 17.04.2020, 22:16 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > Dear GHC steering committee > > Shayne and Neil have updated the RecordDotSyntax proposal in the light of our conclusions. > > We have debated this extensively, so the question is now not so much about content as presentation: is the proposal complete, clear, and precise? > > I think it’s pretty good, and I propose that we now accept it as-is. I’ll take silence as assent. Please yell by close of play Weds 22 April if you’d like any further changes. the silence was roaring, so I’ll merge this now. Small typos or such can still be fixed by PR against the repo. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Sun May 3 11:48:02 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 03 May 2020 13:48:02 +0200 Subject: [ghc-steering-committee] Status Message-ID: Dear Committee, I have maintained proper social distancing from writing status mails, wisely preemptively since mid-December, but with the infection numbers going down this is no longer justifiable. Most of the time has been spent on debating and discussing the Record syntax proposal, which we eventually resolved by voting for a somewhat conservative choice. Given that I’ll try to summarize 4½ months, there might be holes. So anyways, what has happened? * Alejandro Serrano Mena, Cale Gibbard and Tom Harding have joined up. Welcome! * we were asked to review these proposals: #303: Constraint based arrow notation, Shepherd: Chis Allen #287: Simplify subsumption, Shepherd: Arnaud #302: Layout and Guards in Lambda Expressions, Shepherd: Cale #314: -Wnoncanonical-mumble-instances, Shepherd: Tom Harding #319: NoFallibleDo proposal, Shepherd: Eric Seidel #320: clsdfltassoctypinst in bckpck&.hs-boot, Shepherd: Richard Eisenberg #270: Extend Term-Level Lookup Rules, Shepherd: Iavor (resubmission) #285: -XNoImplicitForAll, Shephard Simon M (resubmission) * we have a recommendation from the shepherd about: #282: RecordDotSyntax language extension proposal (rec: accept by vote) #287: Simplify subsumption (rec: accept) #216: Qualified Do (rec: accept one of the variants) #314: -Wnoncanonical-mumble-instances (rec: accept) #285: -XNoImplicitForAll (rec: accept) * we have sent the following proposals back to revision #216: QualifiedDo, but it’s already back * we decided about the following proposals #301: Rename PtrRep to BoxedRep (accept) #282: RecordDotSyntax language extension proposal (accept by vote) #287: Simplify subsumption (accept) #111: Linear Types (final acceptance) #314: -Wnoncanonical-mumble-instances (accept) We currently have to act on the following 7 proposals, up by 5! ## Waiting for committee decision #216: Qualified Do, Shepherd: Joachim Strong backing for one variant, but no consensus yet. Let’s keep talking (or vote!) ## Waiting for Shepherd action #285: -XNoImplicitForAll (rec: accept) acceptance imminent #302: Layout and Guards in Lambda Expressions, Shepherd: Cale #303: Constraint based arrow notation, Shepherd: Chis Allen #319: NoFallibleDo proposal, Shepherd: Eric Seidel #320: clsdfltassoctypinst in bckpck&.hs-boot, Shepherd: Richard Eisenberg #270: Extend Term-Level Lookup Rules, Shepherd: Iavor This is already a re-submission. Cale and Chris, you have two rather old proposals on your plate. Please be considerate of our contributor’s motivation and show some activity! Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ #320: clsdfltassoctypinst in bckpck&.hs-boot, Shepherd: Richard Eisenberg From rae at richarde.dev Mon May 4 09:06:35 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 4 May 2020 10:06:35 +0100 Subject: [ghc-steering-committee] Proposal #320: recommendation: accept Message-ID: Hi committee, I am the shepherd for #320, about a tweak to the handling of associated-type defaults in hs-boot and signature files. I recommend acceptance. Proposal: https://github.com/obsidiansystems/ghc-proposals/blob/signature-type-instances/proposals/0000-signature-instances.md Recommendation (in GitHub thread): https://github.com/ghc-proposals/ghc-proposals/pull/320#issuecomment-623346043 As stated in our published process (https://github.com/ghc-proposals/ghc-proposals#committee-process ), technical conversation should go on the GitHub thread, while evaluative comments can go on this thread in the mailing list. I expect this will be boring and uncontroversial to many of us. I will accept this in one week unless debate has sprung up. Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon May 4 11:31:01 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 4 May 2020 11:31:01 +0000 Subject: [ghc-steering-committee] #285: -XNoImplicitForAll, recommendation: accept In-Reply-To: <7c7ede815f1c20a3619ab40ecc0b550ccf079ce9.camel@joachim-breitner.de> References: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de> <7c7ede815f1c20a3619ab40ecc0b550ccf079ce9.camel@joachim-breitner.de> Message-ID: I think it's good to go. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 03 May 2020 12:22 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] #285: -XNoImplicitForAll, | recommendation: accept | | Hi, | | | Am Montag, den 20.01.2020, 08:37 +0000 schrieb Simon Marlow: | > Proposal #285 is currently under consideration: | > https://github.com/ghc-proposals/ghc-proposals/pull/285 | > | > I previously recommended acceptance, and there was some followup | > discussion on the GitHub thread where Simon PJ and Arnaud requested | > changes. The changes, namely clarifications and more examples, have | > all been implemented and those that requested changes have signed | > off. | > | > I think we can accept the proposal now. Any final concerns? | | looks like this never happened, and Arnaud was the last to comment, and | said “if I'm alone in this, I'm not going to argue further.”. | | Simon M, if you tell me so, I’ll merge it as accepted. | | Cheers, | Joachim | | -- | Joachim Breitner | mail at joachim-breitner.de | http://www.joachim-breitner.de/ | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From tomjharding at live.co.uk Mon May 4 12:00:12 2020 From: tomjharding at live.co.uk (Tom Harding) Date: Mon, 4 May 2020 12:00:12 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> I’ve been quiet so far because I think both outcomes are perfectly sensible, and I don’t think I have anything to add that hasn’t already been covered. If really pushed, I’d perhaps have a slight bias towards the record-based approach, but really only because of the future possibility of dynamically constructing builders. However, I don’t think that preference is strong enough to be worth counting - I’m happy to abstain. Thanks, Tom > On 2 May 2020, at 10:54, Cale Gibbard wrote: > > I greatly prefer the earlier module-based version of this where the > definitions of the relevant functions are simply obtained from the > qualified module and we don't have to talk about fully-settled types > to explain how expressions are going to desugar. Even if it's not > quite true in the case of GHC's internals that desugaring comes > entirely before typechecking, I think it's really very helpful in both > understanding the language ourselves and in explaining it to beginners > if we can at least think about it that way. The more that the > translation from surface syntax to core factors into a bunch of > individually comprehensible translations, the better. > > On Sat, 2 May 2020 at 05:39, Joachim Breitner wrote: >> >> Dear Committee, >> >> it seems discussion has ebbed down. Are there any new arguments that >> can be brought forward? Did anyone have a change of mind which would >> bring us closer to (or farther away from) consensus? Or should we vote? >> >> Simon Marlow, Chris, Cale, Tom: >> You have not stated an opinion. Do you have one? >> >> Cheers, >> Joachim >> >> Am Mittwoch, den 22.04.2020, 12:26 +0200 schrieb Joachim Breitner: >>> Dear Committe, >>> >>> trying to summarize the discussion here. >>> >>> The main decision seems to be: Record based or module based. >>> >>> Record based is preferred by: >>> Arnaud (one of the authors), SPJ >>> >>> Module based is preferred by: >>> Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro, >>> me >>> >>> This is not a vote, merely a summary of sentimenss. But it seems that >>> maybe the onus to make stronger arguments for the record-based approach >>> is on Simon and Arnaud? >>> >>> >>> Related to the module based variant, there was some discussion about >>> whether the >>> * desugaring should go to a “qualified name”, that is then resolved >>> like any manually written name >>> (i.e. could conceptually be done in the parser) >>> * or if it should go directly a suitable “original name” of a suitable >>> function, even if not explicitly imported >>> (i.e. could conceptually be done in the renamer, but not the parser) >>> >>> I initially advocated for the latter, arguing with a “you shall not >>> have to import stuff you do not write explicitly” rule. >>> But Simon’s recent argument that >>> >>> import qualified Monad as M >>> >>> (i.e. _with_ qualification, but _without_ an import list) will give the >>> developer a good user experience, and if they try to do things like >>> >>> import Monad as M (runMonad) >>> … M.do … >>> >>> then, well, they shouldn’t. So I am happy to advocate for the module >>> based approach with the “must be in scope” rule. But maybe we should >>> keep the focus more on the fundamental question above. >>> >>> >>> >>> We could keep in mind that eventually, people will ask for M.if; M.[ >>> and other “qualified syntax”. But it seems that that will work equally >>> well with either choice here. >>> >>> Cheers, >>> Joachim >>> >>> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Mon May 4 12:57:55 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 04 May 2020 14:57:55 +0200 Subject: [ghc-steering-committee] #285: -XNoImplicitForAll, recommendation: accept In-Reply-To: References: <33139f4fee8951fed22bc949d9f3e30c2bb752ba.camel@joachim-breitner.de> <7c7ede815f1c20a3619ab40ecc0b550ccf079ce9.camel@joachim-breitner.de> Message-ID: Hi, great, merged. Cheers, Joachim Am Montag, den 04.05.2020, 11:31 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > I think it's good to go. > > Simon > > > -----Original Message----- > > From: ghc-steering-committee > > On Behalf Of Joachim Breitner > > Sent: 03 May 2020 12:22 > > To: ghc-steering-committee at haskell.org > > Subject: Re: [ghc-steering-committee] #285: -XNoImplicitForAll, > > recommendation: accept > > > > Hi, > > > > > > Am Montag, den 20.01.2020, 08:37 +0000 schrieb Simon Marlow: > > > Proposal #285 is currently under consideration: > > > https://github.com/ghc-proposals/ghc-proposals/pull/285 > > > > > > I previously recommended acceptance, and there was some followup > > > discussion on the GitHub thread where Simon PJ and Arnaud requested > > > changes. The changes, namely clarifications and more examples, have > > > all been implemented and those that requested changes have signed > > > off. > > > > > > I think we can accept the proposal now. Any final concerns? > > > > looks like this never happened, and Arnaud was the last to comment, and > > said “if I'm alone in this, I'm not going to argue further.”. > > > > Simon M, if you tell me so, I’ll merge it as accepted. > > > > Cheers, > > Joachim > > > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From iavor.diatchki at gmail.com Mon May 4 15:22:25 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 4 May 2020 08:22:25 -0700 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> Message-ID: You can define dynamic builders with the module based approach, there's an example on the GitHub thread. Iavor On Mon, May 4, 2020, 05:00 Tom Harding wrote: > I’ve been quiet so far because I think both outcomes are perfectly > sensible, and I don’t think I have anything to add that hasn’t already been > covered. > > If really pushed, I’d perhaps have a slight bias towards the record-based > approach, but really only because of the future possibility of dynamically > constructing builders. However, I don’t think that preference is strong > enough to be worth counting - I’m happy to abstain. > > Thanks, > Tom > > > On 2 May 2020, at 10:54, Cale Gibbard wrote: > > > > I greatly prefer the earlier module-based version of this where the > > definitions of the relevant functions are simply obtained from the > > qualified module and we don't have to talk about fully-settled types > > to explain how expressions are going to desugar. Even if it's not > > quite true in the case of GHC's internals that desugaring comes > > entirely before typechecking, I think it's really very helpful in both > > understanding the language ourselves and in explaining it to beginners > > if we can at least think about it that way. The more that the > > translation from surface syntax to core factors into a bunch of > > individually comprehensible translations, the better. > > > > On Sat, 2 May 2020 at 05:39, Joachim Breitner > wrote: > >> > >> Dear Committee, > >> > >> it seems discussion has ebbed down. Are there any new arguments that > >> can be brought forward? Did anyone have a change of mind which would > >> bring us closer to (or farther away from) consensus? Or should we vote? > >> > >> Simon Marlow, Chris, Cale, Tom: > >> You have not stated an opinion. Do you have one? > >> > >> Cheers, > >> Joachim > >> > >> Am Mittwoch, den 22.04.2020, 12:26 +0200 schrieb Joachim Breitner: > >>> Dear Committe, > >>> > >>> trying to summarize the discussion here. > >>> > >>> The main decision seems to be: Record based or module based. > >>> > >>> Record based is preferred by: > >>> Arnaud (one of the authors), SPJ > >>> > >>> Module based is preferred by: > >>> Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro, > >>> me > >>> > >>> This is not a vote, merely a summary of sentimenss. But it seems that > >>> maybe the onus to make stronger arguments for the record-based approach > >>> is on Simon and Arnaud? > >>> > >>> > >>> Related to the module based variant, there was some discussion about > >>> whether the > >>> * desugaring should go to a “qualified name”, that is then resolved > >>> like any manually written name > >>> (i.e. could conceptually be done in the parser) > >>> * or if it should go directly a suitable “original name” of a suitable > >>> function, even if not explicitly imported > >>> (i.e. could conceptually be done in the renamer, but not the parser) > >>> > >>> I initially advocated for the latter, arguing with a “you shall not > >>> have to import stuff you do not write explicitly” rule. > >>> But Simon’s recent argument that > >>> > >>> import qualified Monad as M > >>> > >>> (i.e. _with_ qualification, but _without_ an import list) will give the > >>> developer a good user experience, and if they try to do things like > >>> > >>> import Monad as M (runMonad) > >>> … M.do … > >>> > >>> then, well, they shouldn’t. So I am happy to advocate for the module > >>> based approach with the “must be in scope” rule. But maybe we should > >>> keep the focus more on the fundamental question above. > >>> > >>> > >>> > >>> We could keep in mind that eventually, people will ask for M.if; M.[ > >>> and other “qualified syntax”. But it seems that that will work equally > >>> well with either choice here. > >>> > >>> Cheers, > >>> Joachim > >>> > >>> > >> -- > >> Joachim Breitner > >> mail at joachim-breitner.de > >> http://www.joachim-breitner.de/ > >> > >> > >> _______________________________________________ > >> 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 tomjharding at live.co.uk Mon May 4 16:46:13 2020 From: tomjharding at live.co.uk (Tom Harding) Date: Mon, 4 May 2020 16:46:13 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> Message-ID: <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> I’m nervous to endorse any solution that requires implicit parameters generally, just because of the cognitive overhead involved in reading and understanding any code involving them. I think, for the particular problem of dynamic builders, the record approach ends up being more “idiomatic Haskell” (for my personal definition of idiomatic, of course). That said, I can’t deny that the solution works! Moreover, given that I don’t have a concrete example of a problem in mind, I wouldn’t want to hold up a final decision. Cheers, Tom On 4 May 2020, at 16:22, Iavor Diatchki > wrote: You can define dynamic builders with the module based approach, there's an example on the GitHub thread. Iavor On Mon, May 4, 2020, 05:00 Tom Harding > wrote: I’ve been quiet so far because I think both outcomes are perfectly sensible, and I don’t think I have anything to add that hasn’t already been covered. If really pushed, I’d perhaps have a slight bias towards the record-based approach, but really only because of the future possibility of dynamically constructing builders. However, I don’t think that preference is strong enough to be worth counting - I’m happy to abstain. Thanks, Tom > On 2 May 2020, at 10:54, Cale Gibbard > wrote: > > I greatly prefer the earlier module-based version of this where the > definitions of the relevant functions are simply obtained from the > qualified module and we don't have to talk about fully-settled types > to explain how expressions are going to desugar. Even if it's not > quite true in the case of GHC's internals that desugaring comes > entirely before typechecking, I think it's really very helpful in both > understanding the language ourselves and in explaining it to beginners > if we can at least think about it that way. The more that the > translation from surface syntax to core factors into a bunch of > individually comprehensible translations, the better. > > On Sat, 2 May 2020 at 05:39, Joachim Breitner > wrote: >> >> Dear Committee, >> >> it seems discussion has ebbed down. Are there any new arguments that >> can be brought forward? Did anyone have a change of mind which would >> bring us closer to (or farther away from) consensus? Or should we vote? >> >> Simon Marlow, Chris, Cale, Tom: >> You have not stated an opinion. Do you have one? >> >> Cheers, >> Joachim >> >> Am Mittwoch, den 22.04.2020, 12:26 +0200 schrieb Joachim Breitner: >>> Dear Committe, >>> >>> trying to summarize the discussion here. >>> >>> The main decision seems to be: Record based or module based. >>> >>> Record based is preferred by: >>> Arnaud (one of the authors), SPJ >>> >>> Module based is preferred by: >>> Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro, >>> me >>> >>> This is not a vote, merely a summary of sentimenss. But it seems that >>> maybe the onus to make stronger arguments for the record-based approach >>> is on Simon and Arnaud? >>> >>> >>> Related to the module based variant, there was some discussion about >>> whether the >>> * desugaring should go to a “qualified name”, that is then resolved >>> like any manually written name >>> (i.e. could conceptually be done in the parser) >>> * or if it should go directly a suitable “original name” of a suitable >>> function, even if not explicitly imported >>> (i.e. could conceptually be done in the renamer, but not the parser) >>> >>> I initially advocated for the latter, arguing with a “you shall not >>> have to import stuff you do not write explicitly” rule. >>> But Simon’s recent argument that >>> >>> import qualified Monad as M >>> >>> (i.e. _with_ qualification, but _without_ an import list) will give the >>> developer a good user experience, and if they try to do things like >>> >>> import Monad as M (runMonad) >>> … M.do … >>> >>> then, well, they shouldn’t. So I am happy to advocate for the module >>> based approach with the “must be in scope” rule. But maybe we should >>> keep the focus more on the fundamental question above. >>> >>> >>> >>> We could keep in mind that eventually, people will ask for M.if; M.[ >>> and other “qualified syntax”. But it seems that that will work equally >>> well with either choice here. >>> >>> Cheers, >>> Joachim >>> >>> >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon May 4 21:08:23 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 04 May 2020 23:08:23 +0200 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> Message-ID: <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> Dear Committee I took the liberty to re-asssign #303 to Alejandro; the authors rightfully asked for progress in the discussion thread. Cheers, Joachim Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: > Dear Committee, > > this is your secretary speaking: > > Constraint based arrow notation > has been proposed by Aleix King > https://github.com/ghc-proposals/ghc-proposals/pull/303 > https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md > > I propose Chris Done as the shepherd. > > Please guide us to a conclusion as outlined in > https://github.com/ghc-proposals/ghc-proposals#committee-process > > Thanks, > Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Tue May 5 06:03:06 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 5 May 2020 08:03:06 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> Message-ID: Sorry to have been quiet after Joachim's soliciting more input from me, Let me try to summarize why I prefer the records approach (and I think it sort of boils down to the same intuition as Simon (Peyton Jones)'s reasons): It boils down to: a record would define, in no ambiguous terms, a do notation desugaring strategy. Whereas in the module-based approach, a given do block is allowed to pick and mix different combinators from wherever it wants; even if they don't go together very well. - This makes it certain which combinators are working together. With the modules, who's to say that I am not mistakenly taking `(>>)` from a different location because I'm mixing modules together (and the module I think I'm using doesn't actually export `(>>)`)? I'd eventually find out, but it would be rather unpleasant to debug considering that I'm not even seeing `M.>>` in my code. - Error messages can tell me: “your builder doesn't support `>>`”, rather than telling me, “You're not importing an `M.>>`” which is a less ambiguous error. This feature, overall, makes more sense to me with records. On Mon, May 4, 2020 at 6:46 PM Tom Harding wrote: > I’m nervous to endorse any solution that requires implicit parameters > generally, just because of the cognitive overhead involved in reading and > understanding any code involving them. I think, for the particular problem > of dynamic builders, the record approach ends up being more “idiomatic > Haskell” (for my personal definition of idiomatic, of course). > > That said, I can’t deny that the solution works! Moreover, given that I > don’t have a concrete example of a problem in mind, I wouldn’t want to hold > up a final decision. > > Cheers, > Tom > > On 4 May 2020, at 16:22, Iavor Diatchki wrote: > > You can define dynamic builders with the module based approach, there's an > example on the GitHub thread. > > Iavor > > On Mon, May 4, 2020, 05:00 Tom Harding wrote: > >> I’ve been quiet so far because I think both outcomes are perfectly >> sensible, and I don’t think I have anything to add that hasn’t already been >> covered. >> >> If really pushed, I’d perhaps have a slight bias towards the record-based >> approach, but really only because of the future possibility of dynamically >> constructing builders. However, I don’t think that preference is strong >> enough to be worth counting - I’m happy to abstain. >> >> Thanks, >> Tom >> >> > On 2 May 2020, at 10:54, Cale Gibbard wrote: >> > >> > I greatly prefer the earlier module-based version of this where the >> > definitions of the relevant functions are simply obtained from the >> > qualified module and we don't have to talk about fully-settled types >> > to explain how expressions are going to desugar. Even if it's not >> > quite true in the case of GHC's internals that desugaring comes >> > entirely before typechecking, I think it's really very helpful in both >> > understanding the language ourselves and in explaining it to beginners >> > if we can at least think about it that way. The more that the >> > translation from surface syntax to core factors into a bunch of >> > individually comprehensible translations, the better. >> > >> > On Sat, 2 May 2020 at 05:39, Joachim Breitner >> wrote: >> >> >> >> Dear Committee, >> >> >> >> it seems discussion has ebbed down. Are there any new arguments that >> >> can be brought forward? Did anyone have a change of mind which would >> >> bring us closer to (or farther away from) consensus? Or should we vote? >> >> >> >> Simon Marlow, Chris, Cale, Tom: >> >> You have not stated an opinion. Do you have one? >> >> >> >> Cheers, >> >> Joachim >> >> >> >> Am Mittwoch, den 22.04.2020, 12:26 +0200 schrieb Joachim Breitner: >> >>> Dear Committe, >> >>> >> >>> trying to summarize the discussion here. >> >>> >> >>> The main decision seems to be: Record based or module based. >> >>> >> >>> Record based is preferred by: >> >>> Arnaud (one of the authors), SPJ >> >>> >> >>> Module based is preferred by: >> >>> Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro, >> >>> me >> >>> >> >>> This is not a vote, merely a summary of sentimenss. But it seems that >> >>> maybe the onus to make stronger arguments for the record-based >> approach >> >>> is on Simon and Arnaud? >> >>> >> >>> >> >>> Related to the module based variant, there was some discussion about >> >>> whether the >> >>> * desugaring should go to a “qualified name”, that is then resolved >> >>> like any manually written name >> >>> (i.e. could conceptually be done in the parser) >> >>> * or if it should go directly a suitable “original name” of a suitable >> >>> function, even if not explicitly imported >> >>> (i.e. could conceptually be done in the renamer, but not the parser) >> >>> >> >>> I initially advocated for the latter, arguing with a “you shall not >> >>> have to import stuff you do not write explicitly” rule. >> >>> But Simon’s recent argument that >> >>> >> >>> import qualified Monad as M >> >>> >> >>> (i.e. _with_ qualification, but _without_ an import list) will give >> the >> >>> developer a good user experience, and if they try to do things like >> >>> >> >>> import Monad as M (runMonad) >> >>> … M.do … >> >>> >> >>> then, well, they shouldn’t. So I am happy to advocate for the module >> >>> based approach with the “must be in scope” rule. But maybe we should >> >>> keep the focus more on the fundamental question above. >> >>> >> >>> >> >>> >> >>> We could keep in mind that eventually, people will ask for M.if; M.[ >> >>> and other “qualified syntax”. But it seems that that will work equally >> >>> well with either choice here. >> >>> >> >>> Cheers, >> >>> Joachim >> >>> >> >>> >> >> -- >> >> Joachim Breitner >> >> mail at joachim-breitner.de >> >> http://www.joachim-breitner.de/ >> >> >> >> >> >> _______________________________________________ >> >> ghc-steering-committee mailing list >> >> ghc-steering-committee at haskell.org >> >> >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ >> > ghc-steering-committee mailing list >> > ghc-steering-committee at haskell.org >> > >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue May 5 08:13:37 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 05 May 2020 10:13:37 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> Message-ID: Hi, let me try to kindly rebut your points to some extent. 1. Most criticism about the module-based approach boils down to “What if people alias unrelated modules to the same name?” Both in the discussion on visibility (export, or also import) and in this case. I’d say: Nobody aliases unrelated module! (And if some do, I don’t think they deserve to be the main deciding factor in this decision.) 2. Error messages come up too. But again, I don’t see any reason why GHC can’t give equally well error messages in both cases. Note that the desugaring _conceptually_ can happen in parsing, but the implementation certainly won’t, and thus can give informed error messages. So you’d either get maybe You have qualified the do block in … with Foo.builder, but Foo.builder is of type Foo.Builder and the record Builder does not have a field named (>>). vs. You have qualified the do block in … with Foo, but the module Foo does not export a value named (>>). Or, in case you are not importing enough. You have qualified the do block in … with Foo.builder, but you did not import the field accessor Foo.(>>). Did you want to add (>>) to the import list in …. vs. You have qualified the do block in … with Foo, and Foo exports (>>), but you did not import Foo.(>>). Did you want to add (>>) to the import list in …. (or many variations of this, including helpful wording in case the module name aliases multiple modules). BTW, your example seemd to compares the error conditions “builder does not provide (>>)” with “user forgot to import (>>)” – two separate error conditions, that can both occur in both proposals. Neither of these arguments refute your underlying preference for records (which I would absolutely share – if we didn't need this ad-hoc “fully settled” and odd “any type works as long as it has the right fields”). I think it boils down to whether the goal (records) justify the kludges (fully settled, a desugaring that looks up some constructor K withoutusing it). Cheers, Joachim (Can someone maybe just make GetField work with polytypes? Then we woudn’t have any of this discussion, I guess.) Am Dienstag, den 05.05.2020, 08:03 +0200 schrieb Spiwack, Arnaud: > Sorry to have been quiet after Joachim's soliciting more input from me, > > Let me try to summarize why I prefer the records approach (and I think it sort of boils down to the same intuition as Simon (Peyton Jones)'s reasons): > > It boils down to: a record would define, in no ambiguous terms, a do notation desugaring strategy. Whereas in the module-based approach, a given do block is allowed to pick and mix different combinators from wherever it wants; even if they don't go together very well. > > - This makes it certain which combinators are working together. With the modules, who's to say that I am not mistakenly taking `(>>)` from a different location because I'm mixing modules together (and the module I think I'm using doesn't actually export `(>>)`)? I'd eventually find out, but it would be rather unpleasant to debug considering that I'm not even seeing `M.>>` in my code. > - Error messages can tell me: “your builder doesn't support `>>`”, rather than telling me, “You're not importing an `M.>>`” which is a less ambiguous error. > > This feature, overall, makes more sense to me with records. > > On Mon, May 4, 2020 at 6:46 PM Tom Harding wrote: > > I’m nervous to endorse any solution that requires implicit parameters generally, just because of the cognitive overhead involved in reading and understanding any code involving them. I think, for the particular problem of dynamic builders, the record approach ends up being more “idiomatic Haskell” (for my personal definition of idiomatic, of course). > > > > That said, I can’t deny that the solution works! Moreover, given that I don’t have a concrete example of a problem in mind, I wouldn’t want to hold up a final decision. > > > > Cheers, > > Tom > > > > > On 4 May 2020, at 16:22, Iavor Diatchki wrote: > > > > > > You can define dynamic builders with the module based approach, there's an example on the GitHub thread. > > > > > > Iavor > > > > > > On Mon, May 4, 2020, 05:00 Tom Harding wrote: > > > > I’ve been quiet so far because I think both outcomes are perfectly sensible, and I don’t think I have anything to add that hasn’t already been covered. > > > > > > > > If really pushed, I’d perhaps have a slight bias towards the record-based approach, but really only because of the future possibility of dynamically constructing builders. However, I don’t think that preference is strong enough to be worth counting - I’m happy to abstain. > > > > > > > > Thanks, > > > > Tom > > > > > > > > > On 2 May 2020, at 10:54, Cale Gibbard wrote: > > > > > > > > > > I greatly prefer the earlier module-based version of this where the > > > > > definitions of the relevant functions are simply obtained from the > > > > > qualified module and we don't have to talk about fully-settled types > > > > > to explain how expressions are going to desugar. Even if it's not > > > > > quite true in the case of GHC's internals that desugaring comes > > > > > entirely before typechecking, I think it's really very helpful in both > > > > > understanding the language ourselves and in explaining it to beginners > > > > > if we can at least think about it that way. The more that the > > > > > translation from surface syntax to core factors into a bunch of > > > > > individually comprehensible translations, the better. > > > > > > > > > > On Sat, 2 May 2020 at 05:39, Joachim Breitner wrote: > > > > >> > > > > >> Dear Committee, > > > > >> > > > > >> it seems discussion has ebbed down. Are there any new arguments that > > > > >> can be brought forward? Did anyone have a change of mind which would > > > > >> bring us closer to (or farther away from) consensus? Or should we vote? > > > > >> > > > > >> Simon Marlow, Chris, Cale, Tom: > > > > >> You have not stated an opinion. Do you have one? > > > > >> > > > > >> Cheers, > > > > >> Joachim > > > > >> > > > > >> Am Mittwoch, den 22.04.2020, 12:26 +0200 schrieb Joachim Breitner: > > > > >>> Dear Committe, > > > > >>> > > > > >>> trying to summarize the discussion here. > > > > >>> > > > > >>> The main decision seems to be: Record based or module based. > > > > >>> > > > > >>> Record based is preferred by: > > > > >>> Arnaud (one of the authors), SPJ > > > > >>> > > > > >>> Module based is preferred by: > > > > >>> Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro, > > > > >>> me > > > > >>> > > > > >>> This is not a vote, merely a summary of sentimenss. But it seems that > > > > >>> maybe the onus to make stronger arguments for the record-based approach > > > > >>> is on Simon and Arnaud? > > > > >>> > > > > >>> > > > > >>> Related to the module based variant, there was some discussion about > > > > >>> whether the > > > > >>> * desugaring should go to a “qualified name”, that is then resolved > > > > >>> like any manually written name > > > > >>> (i.e. could conceptually be done in the parser) > > > > >>> * or if it should go directly a suitable “original name” of a suitable > > > > >>> function, even if not explicitly imported > > > > >>> (i.e. could conceptually be done in the renamer, but not the parser) > > > > >>> > > > > >>> I initially advocated for the latter, arguing with a “you shall not > > > > >>> have to import stuff you do not write explicitly” rule. > > > > >>> But Simon’s recent argument that > > > > >>> > > > > >>> import qualified Monad as M > > > > >>> > > > > >>> (i.e. _with_ qualification, but _without_ an import list) will give the > > > > >>> developer a good user experience, and if they try to do things like > > > > >>> > > > > >>> import Monad as M (runMonad) > > > > >>> … M.do … > > > > >>> > > > > >>> then, well, they shouldn’t. So I am happy to advocate for the module > > > > >>> based approach with the “must be in scope” rule. But maybe we should > > > > >>> keep the focus more on the fundamental question above. > > > > >>> > > > > >>> > > > > >>> > > > > >>> We could keep in mind that eventually, people will ask for M.if; M.[ > > > > >>> and other “qualified syntax”. But it seems that that will work equally > > > > >>> well with either choice here. > > > > >>> > > > > >>> Cheers, > > > > >>> Joachim > > > > >>> > > > > >>> > > > > >> -- > > > > >> Joachim Breitner > > > > >> mail at joachim-breitner.de > > > > >> http://www.joachim-breitner.de/ > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> ghc-steering-committee mailing list > > > > >> ghc-steering-committee at haskell.org > > > > >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > > _______________________________________________ > > > > > ghc-steering-committee mailing list > > > > > ghc-steering-committee at haskell.org > > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Tue May 5 08:32:25 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Tue, 5 May 2020 10:32:25 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> Message-ID: > 2. Error messages come up too. > > […] > > So you’d either get maybe > > You have qualified the do block in … with Foo.builder, but > Foo.builder is of type Foo.Builder and the record Builder > does not have a field named (>>). > > vs. > > You have qualified the do block in … with Foo, but the module > Foo does not export a value named (>>). > I want to stress that these, if they read as just as good English sentences, don't mean the same thing. The former says: you are using a construction, in your do notation, that your builder doesn't support. The latter says: you haven't imported the module which export this construction, which may or may not exist. Let me make up an example. It is not the case in `base`, but let's imagine that `MonadFail` ins in a different module than `Monad`, then would have to import `Control.Monad.Fail` in addition to `Control.Monad` in order to be able to use partial pattern matching. You may argue that it is bad API design. Which would be fair, but it is hard to assume that such an event can't occur, when designing the compiler. Neither of these arguments refute your underlying preference for > records (which I would absolutely share – if we didn't need this ad-hoc > “fully settled” and odd “any type works as long as it has the right > fields”). > > I think it boils down to whether the goal (records) justify the kludges > (fully settled, a desugaring that looks up some constructor K withoutusing > it). > It's also a question of whether one would consider these as kludgy. Or whether they sound rather natural to your ears. To me: rather natural, evidently. To you, and most other members of the committee, as far as I could gather, they seem to sound weird and somewhat repulsive. > (Can someone maybe just make GetField work with polytypes? Then we > woudn’t have any of this discussion, I guess.) > Cheers to that :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue May 5 10:48:16 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 5 May 2020 11:48:16 +0100 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: Message-ID: On Sat, 2 May 2020 at 10:39, Joachim Breitner wrote: > Dear Committee, > > it seems discussion has ebbed down. Are there any new arguments that > can be brought forward? Did anyone have a change of mind which would > bring us closer to (or farther away from) consensus? Or should we vote? > > Simon Marlow, Chris, Cale, Tom: > You have not stated an opinion. Do you have one? > Ideally the extension would use record overloading, but I understand why that can't work right now (thanks Richard for enlightening me). Given that, I'm not keen on introducing the concept of "fully settled types" - it feels like a kludge, and introducing a special type system concept for this one particular extension doesn't seem like the right tradeoff to me. Perhaps if it was available for general record selection too... but then we have to worry about the interaction with the existing overloaded record selection mechanism. On the other hand, the modules-based approach is simple to describe, conservative, and supports the important uses. It's not ideal, but on balance it seems like the right approach for now. Cheers Simon > > Cheers, > Joachim > > Am Mittwoch, den 22.04.2020, 12:26 +0200 schrieb Joachim Breitner: > > Dear Committe, > > > > trying to summarize the discussion here. > > > > The main decision seems to be: Record based or module based. > > > > Record based is preferred by: > > Arnaud (one of the authors), SPJ > > > > Module based is preferred by: > > Richard (after changing his mind), Eric, Iavor, Vitaly, Alejandro, > > me > > > > This is not a vote, merely a summary of sentimenss. But it seems that > > maybe the onus to make stronger arguments for the record-based approach > > is on Simon and Arnaud? > > > > > > Related to the module based variant, there was some discussion about > > whether the > > * desugaring should go to a “qualified name”, that is then resolved > > like any manually written name > > (i.e. could conceptually be done in the parser) > > * or if it should go directly a suitable “original name” of a suitable > > function, even if not explicitly imported > > (i.e. could conceptually be done in the renamer, but not the parser) > > > > I initially advocated for the latter, arguing with a “you shall not > > have to import stuff you do not write explicitly” rule. > > But Simon’s recent argument that > > > > import qualified Monad as M > > > > (i.e. _with_ qualification, but _without_ an import list) will give the > > developer a good user experience, and if they try to do things like > > > > import Monad as M (runMonad) > > … M.do … > > > > then, well, they shouldn’t. So I am happy to advocate for the module > > based approach with the “must be in scope” rule. But maybe we should > > keep the focus more on the fundamental question above. > > > > > > > > We could keep in mind that eventually, people will ask for M.if; M.[ > > and other “qualified syntax”. But it seems that that will work equally > > well with either choice here. > > > > Cheers, > > Joachim > > > > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 5 23:06:33 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 5 May 2020 23:06:33 +0000 Subject: [ghc-steering-committee] Chris Allen standing down Message-ID: Friends Chris Allen has asked to step down from the GHC Steering Committee - he just has too much else to do. Thank you Chris for your contributions! I hope that you will still keep a watching eye on GHC proposals as they go by - your perspective as a Haskell user is very important. We always risk being supplier-dominated. Joachim, will you update the committee list? I'm not sure if this is the right moment to seek new nominations. Any opinions? Thanks again, Chris. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed May 6 07:49:44 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 06 May 2020 09:49:44 +0200 Subject: [ghc-steering-committee] Chris Allen standing down In-Reply-To: References: Message-ID: <765f76eb406de6df8dc47c95780b8171d2534e6d.camel@joachim-breitner.de> Hi, Thanks, Chris, for your contributions; it was good to have your perspective on the committee, even though (or rather: because) it was often a different one than the rest of us. Am Dienstag, den 05.05.2020, 23:06 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > Joachim, will you update the committee list? Done! > I’m not sure if this is the right moment to seek new nominations. > Any opinions? Not needed right now, we have grown sufficiently last round. An amortizing algorithm, I guess. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Wed May 6 09:08:41 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 May 2020 09:08:41 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> Message-ID: I have finally devoted some time to thinking about this properly. TL;DR: I have made my peace with the module-qualified version. I agree with Arnaud’s points – I have always wanted to group the operations of the builder together – but the module-qualified version is so easy to explain, understand, and implement, that I think it wins. For me the other alternative would be to do nothing, and wait for a better idea to come along. E.g. as the proposal points out, we may have other reasons to want fully settled types. But it is really, really attractive to overload the do-notation for other strange monads. My only real anxiety is that we really will think of a better plan in a few years, and then be stuck with back-compat stuff of code that uses M.do. But maybe we should jump that bridge if we come to it. Simon From: ghc-steering-committee On Behalf Of Spiwack, Arnaud Sent: 05 May 2020 09:32 To: Joachim Breitner Cc: ]Ghc steering committee Subject: Re: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative 2. Error messages come up too. […] So you’d either get maybe You have qualified the do block in … with Foo.builder, but Foo.builder is of type Foo.Builder and the record Builder does not have a field named (>>). vs. You have qualified the do block in … with Foo, but the module Foo does not export a value named (>>). I want to stress that these, if they read as just as good English sentences, don't mean the same thing. The former says: you are using a construction, in your do notation, that your builder doesn't support. The latter says: you haven't imported the module which export this construction, which may or may not exist. Let me make up an example. It is not the case in `base`, but let's imagine that `MonadFail` ins in a different module than `Monad`, then would have to import `Control.Monad.Fail` in addition to `Control.Monad` in order to be able to use partial pattern matching. You may argue that it is bad API design. Which would be fair, but it is hard to assume that such an event can't occur, when designing the compiler. Neither of these arguments refute your underlying preference for records (which I would absolutely share – if we didn't need this ad-hoc “fully settled” and odd “any type works as long as it has the right fields”). I think it boils down to whether the goal (records) justify the kludges (fully settled, a desugaring that looks up some constructor K withoutusing it). It's also a question of whether one would consider these as kludgy. Or whether they sound rather natural to your ears. To me: rather natural, evidently. To you, and most other members of the committee, as far as I could gather, they seem to sound weird and somewhat repulsive. (Can someone maybe just make GetField work with polytypes? Then we woudn’t have any of this discussion, I guess.) Cheers to that :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Wed May 6 10:05:28 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 6 May 2020 11:05:28 +0100 Subject: [ghc-steering-committee] Chris Allen standing down In-Reply-To: <765f76eb406de6df8dc47c95780b8171d2534e6d.camel@joachim-breitner.de> References: <765f76eb406de6df8dc47c95780b8171d2534e6d.camel@joachim-breitner.de> Message-ID: <91698BAF-ED86-491E-A071-9839FEBC8E6A@richarde.dev> > On May 6, 2020, at 8:49 AM, Joachim Breitner wrote: > >> I’m not sure if this is the right moment to seek new nominations. >> Any opinions? > > Not needed right now, we have grown sufficiently last round. An > amortizing algorithm, I guess. I agree. We took on three members last round, and so can stand to wait a bit before growing again. Thanks, Chris, for your participation these last few years! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed May 6 13:51:39 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 06 May 2020 15:51:39 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> Message-ID: <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> Hi, glad that are converging! Arnaud, can you live with this too? If you do, then I’ll announce that we have accepted the proposal in the variant “6.1”, i.e. https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst#do-with-a-module-name without any strange special handling of scoping rules (i.e. not 6.1.2). I still slightly prefer them, but they were contentious, and should we later learn that users really want them, we can add them in a backward- compatible way, so no need to debate that contentious point now. Cheers, Joachim Am Mittwoch, den 06.05.2020, 09:08 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > I have finally devoted some time to thinking about this properly. > > TL;DR: I have made my peace with the module-qualified version. > > I agree with Arnaud’s points – I have always wanted to group the operations of the builder together – but the module-qualified version is so easy to explain, understand, and implement, that I think it wins. > > For me the other alternative would be to do nothing, and wait for a better idea to come along. E.g. as the proposal points out, we may have other reasons to want fully settled types. But it is really, really attractive to overload the do-notation for other strange monads. > > My only real anxiety is that we really will think of a better plan in a few years, and then be stuck with back-compat stuff of code that uses M.do. But maybe we should jump that bridge if we come to it. > > Simon > > From: ghc-steering-committee On Behalf Of Spiwack, Arnaud > Sent: 05 May 2020 09:32 > To: Joachim Breitner > Cc: ]Ghc steering committee > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative > > > > 2. Error messages come up too. > > > > […] > > > > So you’d either get maybe > > > > You have qualified the do block in … with Foo.builder, but > > Foo.builder is of type Foo.Builder and the record Builder > > does not have a field named (>>). > > > > vs. > > > > You have qualified the do block in … with Foo, but the module > > Foo does not export a value named (>>). > > > I want to stress that these, if they read as just as good English sentences, don't mean the same thing. The former says: you are using a construction, in your do notation, that your builder doesn't support. The latter says: you haven't imported the module which export this construction, which may or may not exist. > > Let me make up an example. It is not the case in `base`, but let's imagine that `MonadFail` ins in a different module than `Monad`, then would have to import `Control.Monad.Fail` in addition to `Control.Monad` in order to be able to use partial pattern matching. You may argue that it is bad API design. Which would be fair, but it is hard to assume that such an event can't occur, when designing the compiler. > > > Neither of these arguments refute your underlying preference for > > records (which I would absolutely share – if we didn't need this ad-hoc > > “fully settled” and odd “any type works as long as it has the right > > fields”). > > > > I think it boils down to whether the goal (records) justify the kludges > > (fully settled, a desugaring that looks up some constructor K withoutusing it). > > > It's also a question of whether one would consider these as kludgy. Or whether they sound rather natural to your ears. To me: rather natural, evidently. To you, and most other members of the committee, as far as I could gather, they seem to sound weird and somewhat repulsive. > > > (Can someone maybe just make GetField work with polytypes? Then we > > woudn’t have any of this discussion, I guess.) > > > Cheers to that :-) > _______________________________________________ > 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 arnaud.spiwack at tweag.io Wed May 6 13:55:45 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 6 May 2020 15:55:45 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> Message-ID: I can certainly live with the module-based version. There is one question to solve: should we use the standard names `(>>=)`, `(>>)` for desugaring? (so that the type class methods can be used directly). Or some dedicated names `desugaringBind`, … ? To avoid name clashes. On Wed, May 6, 2020 at 3:51 PM Joachim Breitner wrote: > Hi, > > glad that are converging! Arnaud, can you live with this too? > > If you do, then I’ll announce that we have accepted the proposal in the > variant “6.1”, i.e. > > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst#do-with-a-module-name > without any strange special handling of scoping rules (i.e. not 6.1.2). > > I still slightly prefer them, but they were contentious, and should we > later learn that users really want them, we can add them in a backward- > compatible way, so no need to debate that contentious point now. > > > Cheers, > Joachim > > Am Mittwoch, den 06.05.2020, 09:08 +0000 schrieb Simon Peyton Jones via > ghc-steering-committee: > > I have finally devoted some time to thinking about this properly. > > > > TL;DR: I have made my peace with the module-qualified version. > > > > I agree with Arnaud’s points – I have always wanted to group the > operations of the builder together – but the module-qualified version is so > easy to explain, understand, and implement, that I think it wins. > > > > For me the other alternative would be to do nothing, and wait for a > better idea to come along. E.g. as the proposal points out, we may have > other reasons to want fully settled types. But it is really, really > attractive to overload the do-notation for other strange monads. > > > > My only real anxiety is that we really will think of a better plan in a > few years, and then be stuck with back-compat stuff of code that uses > M.do. But maybe we should jump that bridge if we come to it. > > > > Simon > > > > From: ghc-steering-committee > On Behalf Of Spiwack, Arnaud > > Sent: 05 May 2020 09:32 > > To: Joachim Breitner > > Cc: ]Ghc steering committee > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, > recommendation: accept the alternative > > > > > > > 2. Error messages come up too. > > > > > > […] > > > > > > So you’d either get maybe > > > > > > You have qualified the do block in … with Foo.builder, but > > > Foo.builder is of type Foo.Builder and the record Builder > > > does not have a field named (>>). > > > > > > vs. > > > > > > You have qualified the do block in … with Foo, but the module > > > Foo does not export a value named (>>). > > > > > > I want to stress that these, if they read as just as good English > sentences, don't mean the same thing. The former says: you are using a > construction, in your do notation, that your builder doesn't support. The > latter says: you haven't imported the module which export this > construction, which may or may not exist. > > > > Let me make up an example. It is not the case in `base`, but let's > imagine that `MonadFail` ins in a different module than `Monad`, then would > have to import `Control.Monad.Fail` in addition to `Control.Monad` in order > to be able to use partial pattern matching. You may argue that it is bad > API design. Which would be fair, but it is hard to assume that such an > event can't occur, when designing the compiler. > > > > > Neither of these arguments refute your underlying preference for > > > records (which I would absolutely share – if we didn't need this > ad-hoc > > > “fully settled” and odd “any type works as long as it has the right > > > fields”). > > > > > > I think it boils down to whether the goal (records) justify the kludges > > > (fully settled, a desugaring that looks up some constructor K > withoutusing it). > > > > > > It's also a question of whether one would consider these as kludgy. Or > whether they sound rather natural to your ears. To me: rather natural, > evidently. To you, and most other members of the committee, as far as I > could gather, they seem to sound weird and somewhat repulsive. > > > > > (Can someone maybe just make GetField work with polytypes? Then we > > > woudn’t have any of this discussion, I guess.) > > > > > > Cheers to that :-) > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Wed May 6 14:02:58 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 May 2020 14:02:58 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> Message-ID: I'd rather see a final edit of the proposal, reflecting the final choices, before formally tying the bow. We did that with record dot syntax S | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 06 May 2020 14:52 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] #216: Qualified Do again, | recommendation: accept the alternative | | Hi, | | glad that are converging! Arnaud, can you live with this too? | | If you do, then I’ll announce that we have accepted the proposal in the | variant “6.1”, i.e. | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. | com%2Ftweag%2Fghc-proposals%2Fblob%2Flocal-do%2Fproposals%2F0000-local- | do.rst%23do-with-a-module- | name&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005ce08d | 7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637243699193608686 | &sdata=BahOAFyD0iEutyMzg0YzKBDtDe%2BTQTkfQak0tQtFLhU%3D&reserved= | 0 | without any strange special handling of scoping rules (i.e. not 6.1.2). | | I still slightly prefer them, but they were contentious, and should we | later learn that users really want them, we can add them in a backward- | compatible way, so no need to debate that contentious point now. | | | Cheers, | Joachim | | Am Mittwoch, den 06.05.2020, 09:08 +0000 schrieb Simon Peyton Jones via | ghc-steering-committee: | > I have finally devoted some time to thinking about this properly. | > | > TL;DR: I have made my peace with the module-qualified version. | > | > I agree with Arnaud’s points – I have always wanted to group the | operations of the builder together – but the module-qualified version is | so easy to explain, understand, and implement, that I think it wins. | > | > For me the other alternative would be to do nothing, and wait for a | better idea to come along. E.g. as the proposal points out, we may have | other reasons to want fully settled types. But it is really, really | attractive to overload the do-notation for other strange monads. | > | > My only real anxiety is that we really will think of a better plan in a | few years, and then be stuck with back-compat stuff of code that uses | M.do. But maybe we should jump that bridge if we come to it. | > | > Simon | > | > From: ghc-steering-committee On Behalf Of Spiwack, Arnaud | > Sent: 05 May 2020 09:32 | > To: Joachim Breitner | > Cc: ]Ghc steering committee | > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, | recommendation: accept the alternative | > | > | > > 2. Error messages come up too. | > > | > > […] | > > | > > So you’d either get maybe | > > | > > You have qualified the do block in … with Foo.builder, but | > > Foo.builder is of type Foo.Builder and the record Builder | > > does not have a field named (>>). | > > | > > vs. | > > | > > You have qualified the do block in … with Foo, but the module | > > Foo does not export a value named (>>). | > | > | > I want to stress that these, if they read as just as good English | sentences, don't mean the same thing. The former says: you are using a | construction, in your do notation, that your builder doesn't support. The | latter says: you haven't imported the module which export this | construction, which may or may not exist. | > | > Let me make up an example. It is not the case in `base`, but let's | imagine that `MonadFail` ins in a different module than `Monad`, then | would have to import `Control.Monad.Fail` in addition to `Control.Monad` | in order to be able to use partial pattern matching. You may argue that | it is bad API design. Which would be fair, but it is hard to assume that | such an event can't occur, when designing the compiler. | > | > > Neither of these arguments refute your underlying preference for | > > records (which I would absolutely share – if we didn't need this ad- | hoc | > > “fully settled” and odd “any type works as long as it has the right | > > fields”). | > > | > > I think it boils down to whether the goal (records) justify the | kludges | > > (fully settled, a desugaring that looks up some constructor K | withoutusing it). | > | > | > It's also a question of whether one would consider these as kludgy. Or | whether they sound rather natural to your ears. To me: rather natural, | evidently. To you, and most other members of the committee, as far as I | could gather, they seem to sound weird and somewhat repulsive. | > | > > (Can someone maybe just make GetField work with polytypes? Then we | > > woudn’t have any of this discussion, I guess.) | > | > | > Cheers to that :-) | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee at haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha | skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005 | ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936 | 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re | served=0 | -- | Joachim Breitner | mail at joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joac | him- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac514 | 49005ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63724369 | 9193618681&sdata=4a46m7moVg%2BH4dsGr%2F831WHPPQ79cdzfKMDp0wAwoSs%3D&a | mp;reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha | skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005 | ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936 | 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re | served=0 From mail at joachim-breitner.de Wed May 6 14:28:26 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 06 May 2020 16:28:26 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> Message-ID: Hi, Am Mittwoch, den 06.05.2020, 15:55 +0200 schrieb Spiwack, Arnaud: > There is one question to solve: should we use the standard names > `(>>=)`, `(>>)` for desugaring? (so that the type class methods can > be used directly). Or some dedicated names `desugaringBind`, … ? To > avoid name clashes. given that the recommended idiom is to only use this with a qualified module name, I think using the normal, well-known names is reasonable. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Wed May 6 14:30:41 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 06 May 2020 16:30:41 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> Message-ID: <9c88d9b9fdac6f88719c91201697259391c312de.camel@joachim-breitner.de> Hi, hmm, is that necessary? I think all we are saying is “your previous submission was actually fine”. Nothing has changed since then, as far as I can tell. That version is, I believe, this one: https://github.com/tweag/ghc-proposals/blob/2a1dcc29cc9db7a1f4e86b6cfb86d87cfa72c1cd/proposals/0000-local-do.rst But we can ping the committee once more, if you think that’s helpful. Cheers, Joachim Am Mittwoch, den 06.05.2020, 14:02 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > I'd rather see a final edit of the proposal, reflecting the final choices, before formally tying the bow. > > We did that with record dot syntax > > S > > > -----Original Message----- > > From: ghc-steering-committee > > On Behalf Of Joachim Breitner > > Sent: 06 May 2020 14:52 > > To: ghc-steering-committee at haskell.org > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, > > recommendation: accept the alternative > > > > Hi, > > > > glad that are converging! Arnaud, can you live with this too? > > > > If you do, then I’ll announce that we have accepted the proposal in the > > variant “6.1”, i.e. > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > > com%2Ftweag%2Fghc-proposals%2Fblob%2Flocal-do%2Fproposals%2F0000-local- > > do.rst%23do-with-a-module- > > name&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005ce08d > > 7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637243699193608686 > > &sdata=BahOAFyD0iEutyMzg0YzKBDtDe%2BTQTkfQak0tQtFLhU%3D&reserved= > > 0 > > without any strange special handling of scoping rules (i.e. not 6.1.2). > > > > I still slightly prefer them, but they were contentious, and should we > > later learn that users really want them, we can add them in a backward- > > compatible way, so no need to debate that contentious point now. > > > > > > Cheers, > > Joachim > > > > Am Mittwoch, den 06.05.2020, 09:08 +0000 schrieb Simon Peyton Jones via > > ghc-steering-committee: > > > I have finally devoted some time to thinking about this properly. > > > > > > TL;DR: I have made my peace with the module-qualified version. > > > > > > I agree with Arnaud’s points – I have always wanted to group the > > operations of the builder together – but the module-qualified version is > > so easy to explain, understand, and implement, that I think it wins. > > > > > > For me the other alternative would be to do nothing, and wait for a > > better idea to come along. E.g. as the proposal points out, we may have > > other reasons to want fully settled types. But it is really, really > > attractive to overload the do-notation for other strange monads. > > > > > > My only real anxiety is that we really will think of a better plan in a > > few years, and then be stuck with back-compat stuff of code that uses > > M.do. But maybe we should jump that bridge if we come to it. > > > > > > Simon > > > > > > From: ghc-steering-committee > bounces at haskell.org> On Behalf Of Spiwack, Arnaud > > > Sent: 05 May 2020 09:32 > > > To: Joachim Breitner > > > Cc: ]Ghc steering committee > > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, > > recommendation: accept the alternative > > > > > > > > > > 2. Error messages come up too. > > > > > > > > […] > > > > > > > > So you’d either get maybe > > > > > > > > You have qualified the do block in … with Foo.builder, but > > > > Foo.builder is of type Foo.Builder and the record Builder > > > > does not have a field named (>>). > > > > > > > > vs. > > > > > > > > You have qualified the do block in … with Foo, but the module > > > > Foo does not export a value named (>>). > > > > > > > > > I want to stress that these, if they read as just as good English > > sentences, don't mean the same thing. The former says: you are using a > > construction, in your do notation, that your builder doesn't support. The > > latter says: you haven't imported the module which export this > > construction, which may or may not exist. > > > > > > Let me make up an example. It is not the case in `base`, but let's > > imagine that `MonadFail` ins in a different module than `Monad`, then > > would have to import `Control.Monad.Fail` in addition to `Control.Monad` > > in order to be able to use partial pattern matching. You may argue that > > it is bad API design. Which would be fair, but it is hard to assume that > > such an event can't occur, when designing the compiler. > > > > > > > Neither of these arguments refute your underlying preference for > > > > records (which I would absolutely share – if we didn't need this ad- > > hoc > > > > “fully settled” and odd “any type works as long as it has the right > > > > fields”). > > > > > > > > I think it boils down to whether the goal (records) justify the > > kludges > > > > (fully settled, a desugaring that looks up some constructor K > > withoutusing it). > > > > > > > > > It's also a question of whether one would consider these as kludgy. Or > > whether they sound rather natural to your ears. To me: rather natural, > > evidently. To you, and most other members of the committee, as far as I > > could gather, they seem to sound weird and somewhat repulsive. > > > > > > > (Can someone maybe just make GetField work with polytypes? Then we > > > > woudn’t have any of this discussion, I guess.) > > > > > > > > > Cheers to that :-) > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha > > skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > > committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005 > > ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936 > > 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re > > served=0 > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joac > > him- > > breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac514 > > 49005ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63724369 > > 9193618681&sdata=4a46m7moVg%2BH4dsGr%2F831WHPPQ79cdzfKMDp0wAwoSs%3D&a > > mp;reserved=0 > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha > > skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > > committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005 > > ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936 > > 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re > > served=0 > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From rae at richarde.dev Wed May 6 14:56:33 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Wed, 6 May 2020 15:56:33 +0100 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <9c88d9b9fdac6f88719c91201697259391c312de.camel@joachim-breitner.de> References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9c88d9b9fdac6f88719c91201697259391c312de.camel@joachim-breitner.de> Message-ID: For me, the key point is that the proposal as merged into `master` is the correct, final proposal. I don't think we need a re-review after that is done, but I wouldn't want to just merge a proposal that's not in its final state. Richard > On May 6, 2020, at 3:30 PM, Joachim Breitner wrote: > > Hi, > > hmm, is that necessary? I think all we are saying is “your previous > submission was actually fine”. Nothing has changed since then, as far > as I can tell. That version is, I believe, this one: > > https://github.com/tweag/ghc-proposals/blob/2a1dcc29cc9db7a1f4e86b6cfb86d87cfa72c1cd/proposals/0000-local-do.rst > > But we can ping the committee once more, if you think that’s helpful. > > Cheers, > Joachim > > > > Am Mittwoch, den 06.05.2020, 14:02 +0000 schrieb Simon Peyton Jones via > ghc-steering-committee: >> I'd rather see a final edit of the proposal, reflecting the final choices, before formally tying the bow. >> >> We did that with record dot syntax >> >> S >> >>> -----Original Message----- >>> From: ghc-steering-committee >>> On Behalf Of Joachim Breitner >>> Sent: 06 May 2020 14:52 >>> To: ghc-steering-committee at haskell.org >>> Subject: Re: [ghc-steering-committee] #216: Qualified Do again, >>> recommendation: accept the alternative >>> >>> Hi, >>> >>> glad that are converging! Arnaud, can you live with this too? >>> >>> If you do, then I’ll announce that we have accepted the proposal in the >>> variant “6.1”, i.e. >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. >>> com%2Ftweag%2Fghc-proposals%2Fblob%2Flocal-do%2Fproposals%2F0000-local- >>> do.rst%23do-with-a-module- >>> name&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005ce08d >>> 7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637243699193608686 >>> &sdata=BahOAFyD0iEutyMzg0YzKBDtDe%2BTQTkfQak0tQtFLhU%3D&reserved= >>> 0 >>> without any strange special handling of scoping rules (i.e. not 6.1.2). >>> >>> I still slightly prefer them, but they were contentious, and should we >>> later learn that users really want them, we can add them in a backward- >>> compatible way, so no need to debate that contentious point now. >>> >>> >>> Cheers, >>> Joachim >>> >>> Am Mittwoch, den 06.05.2020, 09:08 +0000 schrieb Simon Peyton Jones via >>> ghc-steering-committee: >>>> I have finally devoted some time to thinking about this properly. >>>> >>>> TL;DR: I have made my peace with the module-qualified version. >>>> >>>> I agree with Arnaud’s points – I have always wanted to group the >>> operations of the builder together – but the module-qualified version is >>> so easy to explain, understand, and implement, that I think it wins. >>>> >>>> For me the other alternative would be to do nothing, and wait for a >>> better idea to come along. E.g. as the proposal points out, we may have >>> other reasons to want fully settled types. But it is really, really >>> attractive to overload the do-notation for other strange monads. >>>> >>>> My only real anxiety is that we really will think of a better plan in a >>> few years, and then be stuck with back-compat stuff of code that uses >>> M.do. But maybe we should jump that bridge if we come to it. >>>> >>>> Simon >>>> >>>> From: ghc-steering-committee >> bounces at haskell.org> On Behalf Of Spiwack, Arnaud >>>> Sent: 05 May 2020 09:32 >>>> To: Joachim Breitner >>>> Cc: ]Ghc steering committee >>>> Subject: Re: [ghc-steering-committee] #216: Qualified Do again, >>> recommendation: accept the alternative >>>> >>>> >>>>> 2. Error messages come up too. >>>>> >>>>> […] >>>>> >>>>> So you’d either get maybe >>>>> >>>>> You have qualified the do block in … with Foo.builder, but >>>>> Foo.builder is of type Foo.Builder and the record Builder >>>>> does not have a field named (>>). >>>>> >>>>> vs. >>>>> >>>>> You have qualified the do block in … with Foo, but the module >>>>> Foo does not export a value named (>>). >>>> >>>> >>>> I want to stress that these, if they read as just as good English >>> sentences, don't mean the same thing. The former says: you are using a >>> construction, in your do notation, that your builder doesn't support. The >>> latter says: you haven't imported the module which export this >>> construction, which may or may not exist. >>>> >>>> Let me make up an example. It is not the case in `base`, but let's >>> imagine that `MonadFail` ins in a different module than `Monad`, then >>> would have to import `Control.Monad.Fail` in addition to `Control.Monad` >>> in order to be able to use partial pattern matching. You may argue that >>> it is bad API design. Which would be fair, but it is hard to assume that >>> such an event can't occur, when designing the compiler. >>>> >>>>> Neither of these arguments refute your underlying preference for >>>>> records (which I would absolutely share – if we didn't need this ad- >>> hoc >>>>> “fully settled” and odd “any type works as long as it has the right >>>>> fields”). >>>>> >>>>> I think it boils down to whether the goal (records) justify the >>> kludges >>>>> (fully settled, a desugaring that looks up some constructor K >>> withoutusing it). >>>> >>>> >>>> It's also a question of whether one would consider these as kludgy. Or >>> whether they sound rather natural to your ears. To me: rather natural, >>> evidently. To you, and most other members of the committee, as far as I >>> could gather, they seem to sound weird and somewhat repulsive. >>>> >>>>> (Can someone maybe just make GetField work with polytypes? Then we >>>>> woudn’t have any of this discussion, I guess.) >>>> >>>> >>>> Cheers to that :-) >>>> _______________________________________________ >>>> ghc-steering-committee mailing list >>>> ghc-steering-committee at haskell.org >>>> >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha >>> skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- >>> committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005 >>> ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936 >>> 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re >>> served=0 >>> -- >>> Joachim Breitner >>> mail at joachim-breitner.de >>> >>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joac >>> him- >>> breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac514 >>> 49005ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63724369 >>> 9193618681&sdata=4a46m7moVg%2BH4dsGr%2F831WHPPQ79cdzfKMDp0wAwoSs%3D&a >>> mp;reserved=0 >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha >>> skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- >>> committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005 >>> ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936 >>> 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re >>> served=0 >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Wed May 6 15:30:32 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 06 May 2020 17:30:32 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9c88d9b9fdac6f88719c91201697259391c312de.camel@joachim-breitner.de> Message-ID: Hi, anyways, I’ll ask the authors to update the proposal, and notify the committee for a brief glance before it gets merged. Cheers, Joachim Am Mittwoch, den 06.05.2020, 15:56 +0100 schrieb Richard Eisenberg: > For me, the key point is that the proposal as merged into `master` is the correct, final proposal. I don't think we need a re-review after that is done, but I wouldn't want to just merge a proposal that's not in its final state. > > Richard > > > On May 6, 2020, at 3:30 PM, Joachim Breitner wrote: > > > > Hi, > > > > hmm, is that necessary? I think all we are saying is “your previous > > submission was actually fine”. Nothing has changed since then, as far > > as I can tell. That version is, I believe, this one: > > > > https://github.com/tweag/ghc-proposals/blob/2a1dcc29cc9db7a1f4e86b6cfb86d87cfa72c1cd/proposals/0000-local-do.rst > > > > But we can ping the committee once more, if you think that’s helpful. > > > > Cheers, > > Joachim > > > > > > > > Am Mittwoch, den 06.05.2020, 14:02 +0000 schrieb Simon Peyton Jones via > > ghc-steering-committee: > > > I'd rather see a final edit of the proposal, reflecting the final choices, before formally tying the bow. > > > > > > We did that with record dot syntax > > > > > > S > > > > > > > -----Original Message----- > > > > From: ghc-steering-committee > > > > On Behalf Of Joachim Breitner > > > > Sent: 06 May 2020 14:52 > > > > To: ghc-steering-committee at haskell.org > > > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, > > > > recommendation: accept the alternative > > > > > > > > Hi, > > > > > > > > glad that are converging! Arnaud, can you live with this too? > > > > > > > > If you do, then I’ll announce that we have accepted the proposal in the > > > > variant “6.1”, i.e. > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. > > > > com%2Ftweag%2Fghc-proposals%2Fblob%2Flocal-do%2Fproposals%2F0000-local- > > > > do.rst%23do-with-a-module- > > > > name&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005ce08d > > > > 7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637243699193608686 > > > > &sdata=BahOAFyD0iEutyMzg0YzKBDtDe%2BTQTkfQak0tQtFLhU%3D&reserved= > > > > 0 > > > > without any strange special handling of scoping rules (i.e. not 6.1.2). > > > > > > > > I still slightly prefer them, but they were contentious, and should we > > > > later learn that users really want them, we can add them in a backward- > > > > compatible way, so no need to debate that contentious point now. > > > > > > > > > > > > Cheers, > > > > Joachim > > > > > > > > Am Mittwoch, den 06.05.2020, 09:08 +0000 schrieb Simon Peyton Jones via > > > > ghc-steering-committee: > > > > > I have finally devoted some time to thinking about this properly. > > > > > > > > > > TL;DR: I have made my peace with the module-qualified version. > > > > > > > > > > I agree with Arnaud’s points – I have always wanted to group the > > > > operations of the builder together – but the module-qualified version is > > > > so easy to explain, understand, and implement, that I think it wins. > > > > > For me the other alternative would be to do nothing, and wait for a > > > > better idea to come along. E.g. as the proposal points out, we may have > > > > other reasons to want fully settled types. But it is really, really > > > > attractive to overload the do-notation for other strange monads. > > > > > My only real anxiety is that we really will think of a better plan in a > > > > few years, and then be stuck with back-compat stuff of code that uses > > > > M.do. But maybe we should jump that bridge if we come to it. > > > > > Simon > > > > > > > > > > From: ghc-steering-committee > > > bounces at haskell.org> On Behalf Of Spiwack, Arnaud > > > > > Sent: 05 May 2020 09:32 > > > > > To: Joachim Breitner > > > > > Cc: ]Ghc steering committee > > > > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, > > > > recommendation: accept the alternative > > > > > > > > > > > 2. Error messages come up too. > > > > > > > > > > > > […] > > > > > > > > > > > > So you’d either get maybe > > > > > > > > > > > > You have qualified the do block in … with Foo.builder, but > > > > > > Foo.builder is of type Foo.Builder and the record Builder > > > > > > does not have a field named (>>). > > > > > > > > > > > > vs. > > > > > > > > > > > > You have qualified the do block in … with Foo, but the module > > > > > > Foo does not export a value named (>>). > > > > > > > > > > I want to stress that these, if they read as just as good English > > > > sentences, don't mean the same thing. The former says: you are using a > > > > construction, in your do notation, that your builder doesn't support. The > > > > latter says: you haven't imported the module which export this > > > > construction, which may or may not exist. > > > > > Let me make up an example. It is not the case in `base`, but let's > > > > imagine that `MonadFail` ins in a different module than `Monad`, then > > > > would have to import `Control.Monad.Fail` in addition to `Control.Monad` > > > > in order to be able to use partial pattern matching. You may argue that > > > > it is bad API design. Which would be fair, but it is hard to assume that > > > > such an event can't occur, when designing the compiler. > > > > > > Neither of these arguments refute your underlying preference for > > > > > > records (which I would absolutely share – if we didn't need this ad- > > > > hoc > > > > > > “fully settled” and odd “any type works as long as it has the right > > > > > > fields”). > > > > > > > > > > > > I think it boils down to whether the goal (records) justify the > > > > kludges > > > > > > (fully settled, a desugaring that looks up some constructor K > > > > withoutusing it). > > > > > > > > > > It's also a question of whether one would consider these as kludgy. Or > > > > whether they sound rather natural to your ears. To me: rather natural, > > > > evidently. To you, and most other members of the committee, as far as I > > > > could gather, they seem to sound weird and somewhat repulsive. > > > > > > (Can someone maybe just make GetField work with polytypes? Then we > > > > > > woudn’t have any of this discussion, I guess.) > > > > > > > > > > Cheers to that :-) > > > > > _______________________________________________ > > > > > ghc-steering-committee mailing list > > > > > ghc-steering-committee at haskell.org > > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha > > > > skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > > > > committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005 > > > > ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936 > > > > 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re > > > > served=0 > > > > -- > > > > Joachim Breitner > > > > mail at joachim-breitner.de > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joac > > > > him- > > > > breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac514 > > > > 49005ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63724369 > > > > 9193618681&sdata=4a46m7moVg%2BH4dsGr%2F831WHPPQ79cdzfKMDp0wAwoSs%3D&a > > > > mp;reserved=0 > > > > > > > > > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > ghc-steering-committee at haskell.org > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha > > > > skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- > > > > committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005 > > > > ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936 > > > > 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re > > > > served=0 > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > > > _______________________________________________ > > 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 simonpj at microsoft.com Wed May 6 15:45:18 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 6 May 2020 15:45:18 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9c88d9b9fdac6f88719c91201697259391c312de.camel@joachim-breitner.de> Message-ID: Yes, I'm just saying I'd like to see the actual final proposal we are being asked to approve before approving it. You pointed to a previous version. But the current version doubtless has been improved in various ways ... let's not lose that. Eg I'd love to see the careful wording about fully settled types appear in the 'builder' alternative section. It's already written .. I'm not suggesting new work. not a big deal! Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 06 May 2020 16:31 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] #216: Qualified Do again, | recommendation: accept the alternative | | Hi, | | anyways, I’ll ask the authors to update the proposal, and notify the | committee for a brief glance before it gets merged. | | Cheers, | Joachim | | Am Mittwoch, den 06.05.2020, 15:56 +0100 schrieb Richard Eisenberg: | > For me, the key point is that the proposal as merged into `master` is | the correct, final proposal. I don't think we need a re-review after that | is done, but I wouldn't want to just merge a proposal that's not in its | final state. | > | > Richard | > | > > On May 6, 2020, at 3:30 PM, Joachim Breitner wrote: | > > | > > Hi, | > > | > > hmm, is that necessary? I think all we are saying is “your previous | > > submission was actually fine”. Nothing has changed since then, as far | > > as I can tell. That version is, I believe, this one: | > > | > > https://github.com/tweag/ghc- | proposals/blob/2a1dcc29cc9db7a1f4e86b6cfb86d87cfa72c1cd/proposals/0000- | local-do.rst | > > | > > But we can ping the committee once more, if you think that’s helpful. | > > | > > Cheers, | > > Joachim | > > | > > | > > | > > Am Mittwoch, den 06.05.2020, 14:02 +0000 schrieb Simon Peyton Jones | via | > > ghc-steering-committee: | > > > I'd rather see a final edit of the proposal, reflecting the final | choices, before formally tying the bow. | > > > | > > > We did that with record dot syntax | > > > | > > > S | > > > | > > > > -----Original Message----- | > > > > From: ghc-steering-committee | > > > > On Behalf Of Joachim Breitner | > > > > Sent: 06 May 2020 14:52 | > > > > To: ghc-steering-committee at haskell.org | > > > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, | > > > > recommendation: accept the alternative | > > > > | > > > > Hi, | > > > > | > > > > glad that are converging! Arnaud, can you live with this too? | > > > > | > > > > If you do, then I’ll announce that we have accepted the proposal | in the | > > > > variant “6.1”, i.e. | > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub. | > > > > com%2Ftweag%2Fghc-proposals%2Fblob%2Flocal-do%2Fproposals%2F0000- | local- | > > > > do.rst%23do-with-a-module- | > > > > | name&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005ce08d | > > > > | 7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637243699193608686 | > > > > | &sdata=BahOAFyD0iEutyMzg0YzKBDtDe%2BTQTkfQak0tQtFLhU%3D&reserved= | > > > > 0 | > > > > without any strange special handling of scoping rules (i.e. not | 6.1.2). | > > > > | > > > > I still slightly prefer them, but they were contentious, and | should we | > > > > later learn that users really want them, we can add them in a | backward- | > > > > compatible way, so no need to debate that contentious point now. | > > > > | > > > > | > > > > Cheers, | > > > > Joachim | > > > > | > > > > Am Mittwoch, den 06.05.2020, 09:08 +0000 schrieb Simon Peyton | Jones via | > > > > ghc-steering-committee: | > > > > > I have finally devoted some time to thinking about this | properly. | > > > > > | > > > > > TL;DR: I have made my peace with the module-qualified version. | > > > > > | > > > > > I agree with Arnaud’s points – I have always wanted to group | the | > > > > operations of the builder together – but the module-qualified | version is | > > > > so easy to explain, understand, and implement, that I think it | wins. | > > > > > For me the other alternative would be to do nothing, and wait | for a | > > > > better idea to come along. E.g. as the proposal points out, we | may have | > > > > other reasons to want fully settled types. But it is really, | really | > > > > attractive to overload the do-notation for other strange monads. | > > > > > My only real anxiety is that we really will think of a better | plan in a | > > > > few years, and then be stuck with back-compat stuff of code that | uses | > > > > M.do. But maybe we should jump that bridge if we come to it. | > > > > > Simon | > > > > > | > > > > > From: ghc-steering-committee > > > bounces at haskell.org> On Behalf Of Spiwack, Arnaud | > > > > > Sent: 05 May 2020 09:32 | > > > > > To: Joachim Breitner | > > > > > Cc: ]Ghc steering committee | > > > > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, | > > > > recommendation: accept the alternative | > > > > > | > > > > > > 2. Error messages come up too. | > > > > > > | > > > > > > […] | > > > > > > | > > > > > > So you’d either get maybe | > > > > > > | > > > > > > You have qualified the do block in … with Foo.builder, | but | > > > > > > Foo.builder is of type Foo.Builder and the record | Builder | > > > > > > does not have a field named (>>). | > > > > > > | > > > > > > vs. | > > > > > > | > > > > > > You have qualified the do block in … with Foo, but the | module | > > > > > > Foo does not export a value named (>>). | > > > > > | > > > > > I want to stress that these, if they read as just as good | English | > > > > sentences, don't mean the same thing. The former says: you are | using a | > > > > construction, in your do notation, that your builder doesn't | support. The | > > > > latter says: you haven't imported the module which export this | > > > > construction, which may or may not exist. | > > > > > Let me make up an example. It is not the case in `base`, but | let's | > > > > imagine that `MonadFail` ins in a different module than `Monad`, | then | > > > > would have to import `Control.Monad.Fail` in addition to | `Control.Monad` | > > > > in order to be able to use partial pattern matching. You may | argue that | > > > > it is bad API design. Which would be fair, but it is hard to | assume that | > > > > such an event can't occur, when designing the compiler. | > > > > > > Neither of these arguments refute your underlying preference | for | > > > > > > records (which I would absolutely share – if we didn't need | this ad- | > > > > hoc | > > > > > > “fully settled” and odd “any type works as long as it has the | right | > > > > > > fields”). | > > > > > > | > > > > > > I think it boils down to whether the goal (records) justify | the | > > > > kludges | > > > > > > (fully settled, a desugaring that looks up some constructor K | > > > > withoutusing it). | > > > > > | > > > > > It's also a question of whether one would consider these as | kludgy. Or | > > > > whether they sound rather natural to your ears. To me: rather | natural, | > > > > evidently. To you, and most other members of the committee, as | far as I | > > > > could gather, they seem to sound weird and somewhat repulsive. | > > > > > > (Can someone maybe just make GetField work with polytypes? | Then we | > > > > > > woudn’t have any of this discussion, I guess.) | > > > > > | > > > > > Cheers to that :-) | > > > > > _______________________________________________ | > > > > > ghc-steering-committee mailing list | > > > > > ghc-steering-committee at haskell.org | > > > > > | > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha | > > > > skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > > > > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005 | > > > > | ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936 | > > > > | 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re | > > > > served=0 | > > > > -- | > > > > Joachim Breitner | > > > > mail at joachim-breitner.de | > > > > | > > > > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joac | > > > > him- | > > > > | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac514 | > > > > | 49005ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63724369 | > > > > | 9193618681&sdata=4a46m7moVg%2BH4dsGr%2F831WHPPQ79cdzfKMDp0wAwoSs%3D&a | > > > > mp;reserved=0 | > > > > | > > > > | > > > > _______________________________________________ | > > > > ghc-steering-committee mailing list | > > > > ghc-steering-committee at haskell.org | > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.ha | > > > > skell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > > > > | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C1c351455ac51449005 | > > > > | ce08d7f1c4a47b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6372436991936 | > > > > | 18681&sdata=VoAprdrPQj326%2F7nVXdF0GUk7Y%2BPBAoHM4fBH7w27QE%3D&re | > > > > served=0 | > > > _______________________________________________ | > > > ghc-steering-committee mailing list | > > > ghc-steering-committee at haskell.org | > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee | > > -- | > > Joachim Breitner | > > mail at joachim-breitner.de | > > http://www.joachim-breitner.de/ | > > | > > | > > _______________________________________________ | > > 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/ | | | _______________________________________________ | 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 Fri May 8 22:02:13 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 09 May 2020 00:02:13 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> Message-ID: <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> Hi, Am Mittwoch, den 06.05.2020, 16:28 +0200 schrieb Joachim Breitner: > Hi, > > Am Mittwoch, den 06.05.2020, 15:55 +0200 schrieb Spiwack, Arnaud: > > There is one question to solve: should we use the standard names > > `(>>=)`, `(>>)` for desugaring? (so that the type class methods can > > be used directly). Or some dedicated names `desugaringBind`, … ? To > > avoid name clashes. > > given that the recommended idiom is to only use this with a qualified > module name, I think using the normal, well-known names is reasonable. do we have more opinions on this? If not we can go with the author’s proposal, which is to use the standard names. It’s natural that when I can write `M.do { a M.>> b ; c }` after all, and helpful if programmer can expect M.>> to be there for every module M that they would use to qualify `do`. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Fri May 8 22:40:29 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 8 May 2020 22:40:29 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> Message-ID: Hmm. I can see the attraction of using other less widely used names like M.qualifiedDoBind M.qualifiedDoFail M.qualifedDoMFix Then searching for `qualifiedDo` would find the things that are used for, well qualified do. Remember, by using the module-prefix form we are making it harder to group together the operations that make up the things used by qualified do -- (>>), (>>=) etc are among the most widely used lexemes in Haskell. I'm not immovable on this, but I think there's a case for using long, explicit names. If you end up saying qualifiedDoBind = (>>=) that would be a very good clue that you intend this operation to be used by Qualified Do. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 08 May 2020 23:02 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] #216: Qualified Do again, | recommendation: accept the alternative | | Hi, | | Am Mittwoch, den 06.05.2020, 16:28 +0200 schrieb Joachim Breitner: | > Hi, | > | > Am Mittwoch, den 06.05.2020, 15:55 +0200 schrieb Spiwack, Arnaud: | > > There is one question to solve: should we use the standard names | > > `(>>=)`, `(>>)` for desugaring? (so that the type class methods can | > > be used directly). Or some dedicated names `desugaringBind`, … ? To | > > avoid name clashes. | > | > given that the recommended idiom is to only use this with a qualified | > module name, I think using the normal, well-known names is reasonable. | | | do we have more opinions on this? If not we can go with the author’s | proposal, which is to use the standard names. It’s natural that when I can | write `M.do { a M.>> b ; c }` after all, and helpful if programmer can | expect M.>> to be there for every module M that they would use to qualify | `do`. | | | Cheers, | Joachim | -- | Joachim Breitner | mail at joachim-breitner.de | http://www.joachim-breitner.de/ | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Fri May 8 22:58:28 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 09 May 2020 00:58:28 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> Message-ID: Hmm indeed :-) Both ways are justifiable. Allow me to explain why using the normal operations seem to be a better trade off. Here is an hypothesis: Most people using do-notation throw in some (non-sugar) monad operations from time to time, e.g.: do doFoo z <- bar x >>= baz >>= quux return (f z) This will not change if they use qualifed monads, so we better allow them to write M.do doFoo z <- bar x M.>>= baz M.>>= quux M.return (f z) So I expect that any module M that is set up to be used qualified will want to export (>>=) and (>>) and return anyways. This observation does not require us to use these in the desugaring. But since they are there, it seems natural to use them. If we don’t, then * some modules export qualifiedDoBind and (>>=) which is redundant (and makes one wonder if they are the same) * a few modules might not export (>>=) (only qualifiedDoBind) for whatever reason This adds cognitive load on the user, who now has to check and remember for which M.do they also can use M.>>= I acknowledge the downside that such a module M may be less easy to recognize as “supports qualified do” just given the list of exports. (Some may call that a feature, e.g. Prelude.do would just work…) I hope that a good haddock module header can address that, maybe by having a section “Used of the Linear monad with QualifiedDo” or such. Cheers, Joachim Am Freitag, den 08.05.2020, 22:40 +0000 schrieb Simon Peyton Jones: > Hmm. I can see the attraction of using other less widely used names like > M.qualifiedDoBind > M.qualifiedDoFail > M.qualifedDoMFix > > Then searching for `qualifiedDo` would find the things that are used > for, well qualified do. Remember, by using the module-prefix form we > are making it harder to group together the operations that make up > the things used by qualified do -- (>>), (>>=) etc are among the most > widely used lexemes in Haskell. > > I'm not immovable on this, but I think there's a case for using long, explicit names. If you end up saying > qualifiedDoBind = (>>=) > that would be a very good clue that you intend this operation to be used by Qualified Do. > > Simon > > > -----Original Message----- > > From: ghc-steering-committee > > On Behalf Of Joachim Breitner > > Sent: 08 May 2020 23:02 > > To: ghc-steering-committee at haskell.org > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, > > recommendation: accept the alternative > > > > Hi, > > > > Am Mittwoch, den 06.05.2020, 16:28 +0200 schrieb Joachim Breitner: > > > Hi, > > > > > > Am Mittwoch, den 06.05.2020, 15:55 +0200 schrieb Spiwack, Arnaud: > > > > There is one question to solve: should we use the standard names > > > > `(>>=)`, `(>>)` for desugaring? (so that the type class methods can > > > > be used directly). Or some dedicated names `desugaringBind`, … ? To > > > > avoid name clashes. > > > > > > given that the recommended idiom is to only use this with a qualified > > > module name, I think using the normal, well-known names is reasonable. > > > > do we have more opinions on this? If not we can go with the author’s > > proposal, which is to use the standard names. It’s natural that when I can > > write `M.do { a M.>> b ; c }` after all, and helpful if programmer can > > expect M.>> to be there for every module M that they would use to qualify > > `do`. > > > > > > Cheers, > > Joachim > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From trupill at gmail.com Sat May 9 19:12:41 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Sat, 9 May 2020 21:12:41 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> Message-ID: I am with Joachim in the use of "normal" names as opposed to special "qualifiedX". At least in my case, I tend to use >>= and >> here and there in my monadic code, so having them exported from the same module would be desirable. In fact, I would expect those modules to also export something akin to <$> and <*>. Alejandro El sáb., 9 may. 2020 a las 0:58, Joachim Breitner () escribió: > Hmm indeed :-) > > Both ways are justifiable. Allow me to explain why using the normal > operations seem to be a better trade off. > > Here is an hypothesis: > > Most people using do-notation throw in some (non-sugar) monad > operations from time to time, e.g.: > > do doFoo > z <- bar x >>= baz >>= quux > return (f z) > > This will not change if they use qualifed monads, so we better allow > them to write > > M.do doFoo > z <- bar x M.>>= baz M.>>= quux > M.return (f z) > > So I expect that any module M that is set up to be used qualified will > want to export (>>=) and (>>) and return anyways. > > This observation does not require us to use these in the desugaring. > But since they are there, it seems natural to use them. > > If we don’t, then > * some modules export qualifiedDoBind and (>>=) > which is redundant (and makes one wonder if they are the same) > * a few modules might not export (>>=) (only qualifiedDoBind) > for whatever reason > This adds cognitive load on the user, who now has to check and > remember for which M.do they also can use M.>>= > > I acknowledge the downside that such a module M may be less easy to > recognize as “supports qualified do” just given the list of exports. > (Some may call that a feature, e.g. Prelude.do would just work…) > I hope that a good haddock module header can address that, maybe by > having a section “Used of the Linear monad with QualifiedDo” or such. > > > Cheers, > Joachim > > Am Freitag, den 08.05.2020, 22:40 +0000 schrieb Simon Peyton Jones: > > Hmm. I can see the attraction of using other less widely used names like > > M.qualifiedDoBind > > M.qualifiedDoFail > > M.qualifedDoMFix > > > > Then searching for `qualifiedDo` would find the things that are used > > for, well qualified do. Remember, by using the module-prefix form we > > are making it harder to group together the operations that make up > > the things used by qualified do -- (>>), (>>=) etc are among the most > > widely used lexemes in Haskell. > > > > I'm not immovable on this, but I think there's a case for using long, > explicit names. If you end up saying > > qualifiedDoBind = (>>=) > > that would be a very good clue that you intend this operation to be used > by Qualified Do. > > > > Simon > > > > > -----Original Message----- > > > From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> > > > On Behalf Of Joachim Breitner > > > Sent: 08 May 2020 23:02 > > > To: ghc-steering-committee at haskell.org > > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, > > > recommendation: accept the alternative > > > > > > Hi, > > > > > > Am Mittwoch, den 06.05.2020, 16:28 +0200 schrieb Joachim Breitner: > > > > Hi, > > > > > > > > Am Mittwoch, den 06.05.2020, 15:55 +0200 schrieb Spiwack, Arnaud: > > > > > There is one question to solve: should we use the standard names > > > > > `(>>=)`, `(>>)` for desugaring? (so that the type class methods can > > > > > be used directly). Or some dedicated names `desugaringBind`, … ? To > > > > > avoid name clashes. > > > > > > > > given that the recommended idiom is to only use this with a qualified > > > > module name, I think using the normal, well-known names is > reasonable. > > > > > > do we have more opinions on this? If not we can go with the author’s > > > proposal, which is to use the standard names. It’s natural that when I > can > > > write `M.do { a M.>> b ; c }` after all, and helpful if programmer can > > > expect M.>> to be there for every module M that they would use to > qualify > > > `do`. > > > > > > > > > Cheers, > > > Joachim > > > -- > > > Joachim Breitner > > > mail at joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon May 11 08:12:22 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 11 May 2020 08:12:22 +0000 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> Message-ID: I agree that having longer names would mean that you may have to say module M( (>>=), (>>), fail , qualifiedBind, qualifiedThen, qualifiedFail ) where qualifiedBind = (>>=) qualifiedThen = (>>) qualifiedFail = fail …defns of (>>=) etc… but you could regard those extra lines as a feature, rather than a bug. They say “I’m planning to use these operators for M.do”. I like that. And I like being able to grep for things in a large codebase. (Grepping for (>>=) is useless.) But I can see that judgements might vary. Simon From: ghc-steering-committee On Behalf Of Alejandro Serrano Mena Sent: 09 May 2020 20:13 To: Joachim Breitner Cc: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative I am with Joachim in the use of "normal" names as opposed to special "qualifiedX". At least in my case, I tend to use >>= and >> here and there in my monadic code, so having them exported from the same module would be desirable. In fact, I would expect those modules to also export something akin to <$> and <*>. Alejandro El sáb., 9 may. 2020 a las 0:58, Joachim Breitner (>) escribió: Hmm indeed :-) Both ways are justifiable. Allow me to explain why using the normal operations seem to be a better trade off. Here is an hypothesis: Most people using do-notation throw in some (non-sugar) monad operations from time to time, e.g.: do doFoo z <- bar x >>= baz >>= quux return (f z) This will not change if they use qualifed monads, so we better allow them to write M.do doFoo z <- bar x M.>>= baz M.>>= quux M.return (f z) So I expect that any module M that is set up to be used qualified will want to export (>>=) and (>>) and return anyways. This observation does not require us to use these in the desugaring. But since they are there, it seems natural to use them. If we don’t, then * some modules export qualifiedDoBind and (>>=) which is redundant (and makes one wonder if they are the same) * a few modules might not export (>>=) (only qualifiedDoBind) for whatever reason This adds cognitive load on the user, who now has to check and remember for which M.do they also can use M.>>= I acknowledge the downside that such a module M may be less easy to recognize as “supports qualified do” just given the list of exports. (Some may call that a feature, e.g. Prelude.do would just work…) I hope that a good haddock module header can address that, maybe by having a section “Used of the Linear monad with QualifiedDo” or such. Cheers, Joachim Am Freitag, den 08.05.2020, 22:40 +0000 schrieb Simon Peyton Jones: > Hmm. I can see the attraction of using other less widely used names like > M.qualifiedDoBind > M.qualifiedDoFail > M.qualifedDoMFix > > Then searching for `qualifiedDo` would find the things that are used > for, well qualified do. Remember, by using the module-prefix form we > are making it harder to group together the operations that make up > the things used by qualified do -- (>>), (>>=) etc are among the most > widely used lexemes in Haskell. > > I'm not immovable on this, but I think there's a case for using long, explicit names. If you end up saying > qualifiedDoBind = (>>=) > that would be a very good clue that you intend this operation to be used by Qualified Do. > > Simon > > > -----Original Message----- > > From: ghc-steering-committee > > > On Behalf Of Joachim Breitner > > Sent: 08 May 2020 23:02 > > To: ghc-steering-committee at haskell.org > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, > > recommendation: accept the alternative > > > > Hi, > > > > Am Mittwoch, den 06.05.2020, 16:28 +0200 schrieb Joachim Breitner: > > > Hi, > > > > > > Am Mittwoch, den 06.05.2020, 15:55 +0200 schrieb Spiwack, Arnaud: > > > > There is one question to solve: should we use the standard names > > > > `(>>=)`, `(>>)` for desugaring? (so that the type class methods can > > > > be used directly). Or some dedicated names `desugaringBind`, … ? To > > > > avoid name clashes. > > > > > > given that the recommended idiom is to only use this with a qualified > > > module name, I think using the normal, well-known names is reasonable. > > > > do we have more opinions on this? If not we can go with the author’s > > proposal, which is to use the standard names. It’s natural that when I can > > write `M.do { a M.>> b ; c }` after all, and helpful if programmer can > > expect M.>> to be there for every module M that they would use to qualify > > `do`. > > > > > > Cheers, > > Joachim > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon May 11 12:12:54 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 11 May 2020 14:12:54 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> Message-ID: <212613034a6d9ccfa85118d14fe936178fb6303d.camel@joachim-breitner.de> Hi Am Montag, den 11.05.2020, 08:12 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > But I can see that judgements might vary. I can also live with either way. If that’s true for all of us, how about we let the proposal author decide on this small point? This way we don't have to come to agreement, and the authors get back some sense of ownership of this proposal, after all the back-and-forth with the comittee? I’ll send them link to the relevant posts by you and me to highlight the advantages of each variant. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From rae at richarde.dev Mon May 11 13:20:46 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 11 May 2020 14:20:46 +0100 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: <212613034a6d9ccfa85118d14fe936178fb6303d.camel@joachim-breitner.de> References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> <212613034a6d9ccfa85118d14fe936178fb6303d.camel@joachim-breitner.de> Message-ID: > On May 11, 2020, at 1:12 PM, Joachim Breitner wrote: > > how about we let the proposal author > decide on this small point? This way we don't have to come to > agreement, and the authors get back some sense of ownership of this > proposal, after all the back-and-forth with the comittee? How delightfully diplomatic. Yes, please. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Mon May 11 13:28:36 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Mon, 11 May 2020 15:28:36 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> <212613034a6d9ccfa85118d14fe936178fb6303d.camel@joachim-breitner.de> Message-ID: El lun., 11 may. 2020 a las 15:20, Richard Eisenberg () escribió: > > > On May 11, 2020, at 1:12 PM, Joachim Breitner > wrote: > > how about we let the proposal author > decide on this small point? This way we don't have to come to > agreement, and the authors get back some sense of ownership of this > proposal, after all the back-and-forth with the comittee? > > > How delightfully diplomatic. Yes, please. > I couldn't have expressed it better. I think Joachim's proposal is perfect :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue May 12 20:32:09 2020 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 12 May 2020 21:32:09 +0100 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> Message-ID: I really like using the standard names, but greppability is desirable too. So perhaps a reasonable convention would be module MyLib.QualifiedDo ( (>>=), (>>), fail ) where { ... } then import MyLib.QualifiedDo as MyLib ... MyLib.do { ... } you could easily grep for modules named `.QualifiedDo`. It would be just a convention, of course. Cheers Simon On Mon, 11 May 2020 at 09:12, Simon Peyton Jones via ghc-steering-committee wrote: > I agree that having longer names would mean that you may have to say > > > > module M( (>>=), (>>), fail > > , qualifiedBind, qualifiedThen, qualifiedFail ) where > > > > qualifiedBind = (>>=) > > qualifiedThen = (>>) > > qualifiedFail = fail > > > > …defns of (>>=) etc… > > > > but you could regard those extra lines as a feature, rather than a bug. > They say “I’m planning to use these operators for M.do”. I like that. > And I like being able to grep for things in a large codebase. (Grepping > for (>>=) is useless.) > > > > But I can see that judgements might vary. > > > > Simon > > > > *From:* ghc-steering-committee > *On Behalf Of *Alejandro Serrano Mena > *Sent:* 09 May 2020 20:13 > *To:* Joachim Breitner > *Cc:* ghc-steering-committee at haskell.org > *Subject:* Re: [ghc-steering-committee] #216: Qualified Do again, > recommendation: accept the alternative > > > > I am with Joachim in the use of "normal" names as opposed to special > "qualifiedX". At least in my case, I tend to use >>= and >> here and there > in my monadic code, so having them exported from the same module would be > desirable. In fact, I would expect those modules to also export something > akin to <$> and <*>. > > > > Alejandro > > > > El sáb., 9 may. 2020 a las 0:58, Joachim Breitner (< > mail at joachim-breitner.de>) escribió: > > Hmm indeed :-) > > Both ways are justifiable. Allow me to explain why using the normal > operations seem to be a better trade off. > > Here is an hypothesis: > > Most people using do-notation throw in some (non-sugar) monad > operations from time to time, e.g.: > > do doFoo > z <- bar x >>= baz >>= quux > return (f z) > > This will not change if they use qualifed monads, so we better allow > them to write > > M.do doFoo > z <- bar x M.>>= baz M.>>= quux > M.return (f z) > > So I expect that any module M that is set up to be used qualified will > want to export (>>=) and (>>) and return anyways. > > This observation does not require us to use these in the desugaring. > But since they are there, it seems natural to use them. > > If we don’t, then > * some modules export qualifiedDoBind and (>>=) > which is redundant (and makes one wonder if they are the same) > * a few modules might not export (>>=) (only qualifiedDoBind) > for whatever reason > This adds cognitive load on the user, who now has to check and > remember for which M.do they also can use M.>>= > > I acknowledge the downside that such a module M may be less easy to > recognize as “supports qualified do” just given the list of exports. > (Some may call that a feature, e.g. Prelude.do would just work…) > I hope that a good haddock module header can address that, maybe by > having a section “Used of the Linear monad with QualifiedDo” or such. > > > Cheers, > Joachim > > Am Freitag, den 08.05.2020, 22:40 +0000 schrieb Simon Peyton Jones: > > Hmm. I can see the attraction of using other less widely used names like > > M.qualifiedDoBind > > M.qualifiedDoFail > > M.qualifedDoMFix > > > > Then searching for `qualifiedDo` would find the things that are used > > for, well qualified do. Remember, by using the module-prefix form we > > are making it harder to group together the operations that make up > > the things used by qualified do -- (>>), (>>=) etc are among the most > > widely used lexemes in Haskell. > > > > I'm not immovable on this, but I think there's a case for using long, > explicit names. If you end up saying > > qualifiedDoBind = (>>=) > > that would be a very good clue that you intend this operation to be used > by Qualified Do. > > > > Simon > > > > > -----Original Message----- > > > From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> > > > On Behalf Of Joachim Breitner > > > Sent: 08 May 2020 23:02 > > > To: ghc-steering-committee at haskell.org > > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, > > > recommendation: accept the alternative > > > > > > Hi, > > > > > > Am Mittwoch, den 06.05.2020, 16:28 +0200 schrieb Joachim Breitner: > > > > Hi, > > > > > > > > Am Mittwoch, den 06.05.2020, 15:55 +0200 schrieb Spiwack, Arnaud: > > > > > There is one question to solve: should we use the standard names > > > > > `(>>=)`, `(>>)` for desugaring? (so that the type class methods can > > > > > be used directly). Or some dedicated names `desugaringBind`, … ? To > > > > > avoid name clashes. > > > > > > > > given that the recommended idiom is to only use this with a qualified > > > > module name, I think using the normal, well-known names is > reasonable. > > > > > > do we have more opinions on this? If not we can go with the author’s > > > proposal, which is to use the standard names. It’s natural that when I > can > > > write `M.do { a M.>> b ; c }` after all, and helpful if programmer can > > > expect M.>> to be there for every module M that they would use to > qualify > > > `do`. > > > > > > > > > Cheers, > > > Joachim > > > -- > > > Joachim Breitner > > > mail at joachim-breitner.de > > > http://www.joachim-breitner.de/ > > > > > > > > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- > 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 iavor.diatchki at gmail.com Tue May 12 22:06:51 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 12 May 2020 15:06:51 -0700 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> Message-ID: I don't have an opinion on what the operations should be called, and am happy to leave it to others to decide. -Iavor On Tue, May 12, 2020 at 1:32 PM Simon Marlow wrote: > I really like using the standard names, but greppability is desirable too. > So perhaps a reasonable convention would be > > module MyLib.QualifiedDo ( (>>=), (>>), fail ) where { ... } > > then > > import MyLib.QualifiedDo as MyLib > > ... MyLib.do { ... } > > you could easily grep for modules named `.QualifiedDo`. It would be just a > convention, of course. > > Cheers > Simon > > > On Mon, 11 May 2020 at 09:12, Simon Peyton Jones via > ghc-steering-committee wrote: > >> I agree that having longer names would mean that you may have to say >> >> >> >> module M( (>>=), (>>), fail >> >> , qualifiedBind, qualifiedThen, qualifiedFail ) where >> >> >> >> qualifiedBind = (>>=) >> >> qualifiedThen = (>>) >> >> qualifiedFail = fail >> >> >> >> …defns of (>>=) etc… >> >> >> >> but you could regard those extra lines as a feature, rather than a bug. >> They say “I’m planning to use these operators for M.do”. I like that. >> And I like being able to grep for things in a large codebase. (Grepping >> for (>>=) is useless.) >> >> >> >> But I can see that judgements might vary. >> >> >> >> Simon >> >> >> >> *From:* ghc-steering-committee < >> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro >> Serrano Mena >> *Sent:* 09 May 2020 20:13 >> *To:* Joachim Breitner >> *Cc:* ghc-steering-committee at haskell.org >> *Subject:* Re: [ghc-steering-committee] #216: Qualified Do again, >> recommendation: accept the alternative >> >> >> >> I am with Joachim in the use of "normal" names as opposed to special >> "qualifiedX". At least in my case, I tend to use >>= and >> here and there >> in my monadic code, so having them exported from the same module would be >> desirable. In fact, I would expect those modules to also export something >> akin to <$> and <*>. >> >> >> >> Alejandro >> >> >> >> El sáb., 9 may. 2020 a las 0:58, Joachim Breitner (< >> mail at joachim-breitner.de>) escribió: >> >> Hmm indeed :-) >> >> Both ways are justifiable. Allow me to explain why using the normal >> operations seem to be a better trade off. >> >> Here is an hypothesis: >> >> Most people using do-notation throw in some (non-sugar) monad >> operations from time to time, e.g.: >> >> do doFoo >> z <- bar x >>= baz >>= quux >> return (f z) >> >> This will not change if they use qualifed monads, so we better allow >> them to write >> >> M.do doFoo >> z <- bar x M.>>= baz M.>>= quux >> M.return (f z) >> >> So I expect that any module M that is set up to be used qualified will >> want to export (>>=) and (>>) and return anyways. >> >> This observation does not require us to use these in the desugaring. >> But since they are there, it seems natural to use them. >> >> If we don’t, then >> * some modules export qualifiedDoBind and (>>=) >> which is redundant (and makes one wonder if they are the same) >> * a few modules might not export (>>=) (only qualifiedDoBind) >> for whatever reason >> This adds cognitive load on the user, who now has to check and >> remember for which M.do they also can use M.>>= >> >> I acknowledge the downside that such a module M may be less easy to >> recognize as “supports qualified do” just given the list of exports. >> (Some may call that a feature, e.g. Prelude.do would just work…) >> I hope that a good haddock module header can address that, maybe by >> having a section “Used of the Linear monad with QualifiedDo” or such. >> >> >> Cheers, >> Joachim >> >> Am Freitag, den 08.05.2020, 22:40 +0000 schrieb Simon Peyton Jones: >> > Hmm. I can see the attraction of using other less widely used names >> like >> > M.qualifiedDoBind >> > M.qualifiedDoFail >> > M.qualifedDoMFix >> > >> > Then searching for `qualifiedDo` would find the things that are used >> > for, well qualified do. Remember, by using the module-prefix form we >> > are making it harder to group together the operations that make up >> > the things used by qualified do -- (>>), (>>=) etc are among the most >> > widely used lexemes in Haskell. >> > >> > I'm not immovable on this, but I think there's a case for using long, >> explicit names. If you end up saying >> > qualifiedDoBind = (>>=) >> > that would be a very good clue that you intend this operation to be >> used by Qualified Do. >> > >> > Simon >> > >> > > -----Original Message----- >> > > From: ghc-steering-committee < >> ghc-steering-committee-bounces at haskell.org> >> > > On Behalf Of Joachim Breitner >> > > Sent: 08 May 2020 23:02 >> > > To: ghc-steering-committee at haskell.org >> > > Subject: Re: [ghc-steering-committee] #216: Qualified Do again, >> > > recommendation: accept the alternative >> > > >> > > Hi, >> > > >> > > Am Mittwoch, den 06.05.2020, 16:28 +0200 schrieb Joachim Breitner: >> > > > Hi, >> > > > >> > > > Am Mittwoch, den 06.05.2020, 15:55 +0200 schrieb Spiwack, Arnaud: >> > > > > There is one question to solve: should we use the standard names >> > > > > `(>>=)`, `(>>)` for desugaring? (so that the type class methods >> can >> > > > > be used directly). Or some dedicated names `desugaringBind`, … ? >> To >> > > > > avoid name clashes. >> > > > >> > > > given that the recommended idiom is to only use this with a >> qualified >> > > > module name, I think using the normal, well-known names is >> reasonable. >> > > >> > > do we have more opinions on this? If not we can go with the author’s >> > > proposal, which is to use the standard names. It’s natural that when >> I can >> > > write `M.do { a M.>> b ; c }` after all, and helpful if programmer can >> > > expect M.>> to be there for every module M that they would use to >> qualify >> > > `do`. >> > > >> > > >> > > Cheers, >> > > Joachim >> > > -- >> > > Joachim Breitner >> > > mail at joachim-breitner.de >> > > http://www.joachim-breitner.de/ >> >> > > >> > > >> > > _______________________________________________ >> > > ghc-steering-committee mailing list >> > > ghc-steering-committee at haskell.org >> > > >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> -- >> 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 arnaud.spiwack at tweag.io Wed May 13 06:22:38 2020 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 13 May 2020 08:22:38 +0200 Subject: [ghc-steering-committee] Proposal #320: recommendation: accept In-Reply-To: References: Message-ID: Simon (PJ) says, on the proposal, that this essentially amounts to documenting the current intended behaviour (but whose implementation is faulty). It does look reasonable regardless. On Mon, May 4, 2020 at 11:06 AM Richard Eisenberg wrote: > Hi committee, > > I am the shepherd for #320, about a tweak to the handling of > associated-type defaults in hs-boot and signature files. I recommend > acceptance. > > Proposal: > https://github.com/obsidiansystems/ghc-proposals/blob/signature-type-instances/proposals/0000-signature-instances.md > Recommendation (in GitHub thread): > https://github.com/ghc-proposals/ghc-proposals/pull/320#issuecomment-623346043 > > As stated in our published process ( > https://github.com/ghc-proposals/ghc-proposals#committee-process), > technical conversation should go on the GitHub thread, while evaluative > comments can go on this thread in the mailing list. > > I expect this will be boring and uncontroversial to many of us. I will > accept this in one week unless debate has sprung up. > > Thanks! > Richard > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed May 13 09:25:04 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 13 May 2020 11:25:04 +0200 Subject: [ghc-steering-committee] #216: Qualified Do again, recommendation: accept the alternative In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> <212613034a6d9ccfa85118d14fe936178fb6303d.camel@joachim-breitner.de> Message-ID: Hi, Am Montag, den 11.05.2020, 14:20 +0100 schrieb Richard Eisenberg: > How delightfully diplomatic. Yes, please. thanks! Done: https://github.com/ghc-proposals/ghc-proposals/pull/216#issuecomment-627864386 Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From eric at seidel.io Wed May 13 20:19:24 2020 From: eric at seidel.io (Eric Seidel) Date: Wed, 13 May 2020 15:19:24 -0500 Subject: [ghc-steering-committee] Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel In-Reply-To: References: Message-ID: <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io> Hi all, My wife and I just checked into the hospital to have our second child, so I’m going to be short on time for committee duties for a few weeks. I think it would be best to reassign this proposal so we don’t keep the authors waiting. I reviewed the proposal over the weekend and left some thoughts on GitHub. I’m supportive of the direction — partial patterns in do-notation are more consistent with the rest of the language — but I thought it would be a stronger proposal if we had a syntax for controlling the failure behavior. This would give people who currently rely on the MonadFail desugaring a cleaner migration path. John has another proposal (#327 iirc) exploring how that syntax might look, I suggested building on top of that proposal or combining the two. Eric Sent from my iPhone > On May 1, 2020, at 04:04, Joachim Breitner wrote: > > Dear Committee, > > this is your secretary speaking: > > NoFallibleDo proposal > has been proposed by Cale > https://github.com/ghc-proposals/ghc-proposals/pull/319 > https://github.com/obsidiansystems/ghc-proposals/blob/no-fallible-do/proposals/0000-no-fallible-do.rst > > I propose Eric Seidel as the shepherd. > > Please guide us to a conclusion as outlined in > https://github.com/ghc-proposals/ghc-proposals#committee-process > > Thanks, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Thu May 14 10:16:30 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 14 May 2020 12:16:30 +0200 Subject: [ghc-steering-committee] Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel In-Reply-To: <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io> References: <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io> Message-ID: <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de> Hi, Am Mittwoch, den 13.05.2020, 15:19 -0500 schrieb Eric Seidel: > My wife and I just checked into the hospital to have our second child Congrats, and all the best! > , so I’m going to be short on time for committee duties for a few > weeks. I think it would be best to reassign this proposal so we don’t > keep the authors waiting. Any volunteers? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From iavor.diatchki at gmail.com Thu May 14 15:28:41 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu, 14 May 2020 08:28:41 -0700 Subject: [ghc-steering-committee] Please review again: Make Q (TExp a) into a newtype #195 Message-ID: Hello, I am the shepherd for #195, about a small change to TH, to wrap `Q (TExp a)` into a newtype. This would be quite handy for a variety of reasons described in the proposal and the comments on the proposal thread: https://github.com/ghc-proposals/ghc-proposals/pull/195 During the last discussion we requested the proposal to be modified to clarify some points. Matt has done that, so it is time for another review. The previous discussion thread is here: https://mail.haskell.org/pipermail/ghc-steering-committee/2019-November/001260.html I still think this is a good idea, and recommend acceptance. Since we've already discussed this once, I'll assume acceptance in about a week, if I don't hear from anyone, although I'll wait until at least Simon PJ and Richard confirm that the issues they raised last time have been addressed. -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Thu May 14 15:30:41 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Thu, 14 May 2020 17:30:41 +0200 Subject: [ghc-steering-committee] Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel In-Reply-To: <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de> References: <80FD825A-1E63-4807-9DF0-AAF3FBDA4BA5@seidel.io> <3c19e58d154f41e2c98979eab095aec2f12094c4.camel@joachim-breitner.de> Message-ID: @Eric congratulations! enjoy! :) @Joachim I can take care of this, I think the direction Eric was pushing this is a good one. El jue., 14 may. 2020 a las 12:16, Joachim Breitner (< mail at joachim-breitner.de>) escribió: > Hi, > > Am Mittwoch, den 13.05.2020, 15:19 -0500 schrieb Eric Seidel: > > My wife and I just checked into the hospital to have our second child > > Congrats, and all the best! > > > , so I’m going to be short on time for committee duties for a few > > weeks. I think it would be best to reassign this proposal so we don’t > > keep the authors waiting. > > Any volunteers? > > Cheers, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Fri May 15 07:01:43 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Fri, 15 May 2020 09:01:43 +0200 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> Message-ID: Dear Committee, This proposal looks good to me. The author has done a lot of work to formalize the new rules, and has done a check that no packages using arrow syntax would be broken by this modification. Thus, I recommend we accept this proposal. Apart from the general discussion, I think it might be worth focusing on a specific part of the design: the use of a couple of type families to express "arrow stacks". I am not aware of other GHC extensions depending on particular type families. - As the author discusses, these type families ought to be wired-in, so they can benefit from improvement during type checking. Is this a good choice? It looks to be, but other may have a different opinion. - Would this type family pose a problem for optimization / specialization / ...? Kind regards, Alejandro El lun., 4 may. 2020 a las 23:08, Joachim Breitner (< mail at joachim-breitner.de>) escribió: > Dear Committee > > I took the liberty to re-asssign #303 to Alejandro; the authors > rightfully asked for progress in the discussion thread. > > Cheers, > Joachim > > Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: > > Dear Committee, > > > > this is your secretary speaking: > > > > Constraint based arrow notation > > has been proposed by Aleix King > > https://github.com/ghc-proposals/ghc-proposals/pull/303 > > > https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md > > > > I propose Chris Done as the shepherd. > > > > Please guide us to a conclusion as outlined in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > Thanks, > > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Fri May 15 09:03:03 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 15 May 2020 10:03:03 +0100 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> Message-ID: I have some concerns -- mostly: is the improvement worth the implementation complexity? I've posted on GitHub. Richard > On May 15, 2020, at 8:01 AM, Alejandro Serrano Mena wrote: > > Dear Committee, > This proposal looks good to me. The author has done a lot of work to formalize the new rules, and has done a check that no packages using arrow syntax would be broken by this modification. Thus, I recommend we accept this proposal. > > Apart from the general discussion, I think it might be worth focusing on a specific part of the design: the use of a couple of type families to express "arrow stacks". I am not aware of other GHC extensions depending on particular type families. > - As the author discusses, these type families ought to be wired-in, so they can benefit from improvement during type checking. Is this a good choice? It looks to be, but other may have a different opinion. > - Would this type family pose a problem for optimization / specialization / ...? > > Kind regards, > Alejandro > > El lun., 4 may. 2020 a las 23:08, Joachim Breitner (>) escribió: > Dear Committee > > I took the liberty to re-asssign #303 to Alejandro; the authors > rightfully asked for progress in the discussion thread. > > Cheers, > Joachim > > Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: > > Dear Committee, > > > > this is your secretary speaking: > > > > Constraint based arrow notation > > has been proposed by Aleix King > > https://github.com/ghc-proposals/ghc-proposals/pull/303 > > https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md > > > > I propose Chris Done as the shepherd. > > > > Please guide us to a conclusion as outlined in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > Thanks, > > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri May 15 10:13:06 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 15 May 2020 10:13:06 +0000 Subject: [ghc-steering-committee] Please review again: Make Q (TExp a) into a newtype #195 In-Reply-To: References: Message-ID: I’ve posted a comment on GitHub with some more questions. Iavor: please do nag if I am slow. Simon From: ghc-steering-committee On Behalf Of Iavor Diatchki Sent: 14 May 2020 16:29 To: ghc-steering-committee Subject: [ghc-steering-committee] Please review again: Make Q (TExp a) into a newtype #195 Hello, I am the shepherd for #195, about a small change to TH, to wrap `Q (TExp a)` into a newtype. This would be quite handy for a variety of reasons described in the proposal and the comments on the proposal thread: https://github.com/ghc-proposals/ghc-proposals/pull/195 During the last discussion we requested the proposal to be modified to clarify some points. Matt has done that, so it is time for another review. The previous discussion thread is here: https://mail.haskell.org/pipermail/ghc-steering-committee/2019-November/001260.html I still think this is a good idea, and recommend acceptance. Since we've already discussed this once, I'll assume acceptance in about a week, if I don't hear from anyone, although I'll wait until at least Simon PJ and Richard confirm that the issues they raised last time have been addressed. -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri May 15 13:52:49 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 15 May 2020 15:52:49 +0200 Subject: [ghc-steering-committee] #216: Qualified Do, final(?) version In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> <212613034a6d9ccfa85118d14fe936178fb6303d.camel@joachim-breitner.de> Message-ID: Dear Committee, Facundo Domínguez has updated the proposal to be based on module names again, see https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-do.rst (with a wealth of alternatives). He opted for desugaring to the well-known name, leaving the “recognizability” of the feature to other means (module names, documentation). Please have a final quick look if this document is fine to approve, and say so. I’ll wait for either explicit nods from people who were involved here, or just wait for a few days of silence, before merging this. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Fri May 15 13:54:01 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 15 May 2020 13:54:01 +0000 Subject: [ghc-steering-committee] #216: Qualified Do, final(?) version In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> <212613034a6d9ccfa85118d14fe936178fb6303d.camel@joachim-breitner.de> Message-ID: I think it's good to go now. Simon | -----Original Message----- | From: ghc-steering-committee | On Behalf Of Joachim Breitner | Sent: 15 May 2020 14:53 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] #216: Qualified Do, final(?) | version | | Dear Committee, | | Facundo Domínguez has updated the proposal to be based on module names | again, see | https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000- | local-do.rst | (with a wealth of alternatives). | | He opted for desugaring to the well-known name, leaving the | “recognizability” of the feature to other means (module names, | documentation). | | Please have a final quick look if this document is fine to approve, and | say so. I’ll wait for either explicit nods from people who were | involved here, or just wait for a few days of silence, before merging | this. | | Cheers, | Joachim | | | -- | Joachim Breitner | mail at joachim-breitner.de | http://www.joachim-breitner.de/ | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From trupill at gmail.com Tue May 19 06:36:25 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Tue, 19 May 2020 08:36:25 +0200 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> Message-ID: Dear Committee, When I took care of this proposal, the GitHub thread was quite dormant. However, it seems that right now there's quite some activity, and even proposals to completely redesign arrows. What is the right approach: let the discussion cool off, and then ask all of you to review the text (which I don't think is going to change substantially in any case) or move the proposal back to the previous state? Alejandro El vie., 15 may. 2020 a las 11:03, Richard Eisenberg () escribió: > I have some concerns -- mostly: is the improvement worth the > implementation complexity? I've posted on GitHub. > > Richard > > On May 15, 2020, at 8:01 AM, Alejandro Serrano Mena > wrote: > > Dear Committee, > This proposal looks good to me. The author has done a lot of work to > formalize the new rules, and has done a check that no packages using arrow > syntax would be broken by this modification. Thus, I recommend we accept > this proposal. > > Apart from the general discussion, I think it might be worth focusing on a > specific part of the design: the use of a couple of type families to > express "arrow stacks". I am not aware of other GHC extensions depending on > particular type families. > - As the author discusses, these type families ought to be wired-in, so > they can benefit from improvement during type checking. Is this a good > choice? It looks to be, but other may have a different opinion. > - Would this type family pose a problem for optimization / specialization > / ...? > > Kind regards, > Alejandro > > El lun., 4 may. 2020 a las 23:08, Joachim Breitner (< > mail at joachim-breitner.de>) escribió: > >> Dear Committee >> >> I took the liberty to re-asssign #303 to Alejandro; the authors >> rightfully asked for progress in the discussion thread. >> >> Cheers, >> Joachim >> >> Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: >> > Dear Committee, >> > >> > this is your secretary speaking: >> > >> > Constraint based arrow notation >> > has been proposed by Aleix King >> > https://github.com/ghc-proposals/ghc-proposals/pull/303 >> > >> https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md >> > >> > I propose Chris Done as the shepherd. >> > >> > Please guide us to a conclusion as outlined in >> > https://github.com/ghc-proposals/ghc-proposals#committee-process >> > >> > Thanks, >> > Joachim >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> > _______________________________________________ > 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 May 19 07:01:57 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 19 May 2020 07:01:57 +0000 (UTC) Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> Message-ID: <916ae81a-890a-4a8f-a35a-f8fbd885df4a@localhost> If there is active discussion, we usually put it back to the previous state, and wait for discussion to come to conclusions. 19.05.2020 08:36:42 Alejandro Serrano Mena : > Dear Committee, > When I took care of this proposal, the GitHub thread was quite dormant. However, it seems that right now there's quite some activity, and even proposals to completely redesign arrows. What is the right approach: let the discussion cool off, and then ask all of you to review the text (which I don't think is going to change substantially in any case) or move the proposal back to the previous state? > > > Alejandro > > > > El vie., 15 may. 2020 a las 11:03, Richard Eisenberg (< rae at richarde.dev >) escribió: > > > > I have some concerns -- mostly: is the improvement worth the implementation complexity? I've posted on GitHub. > > > > Richard > > > > > > > On May 15, 2020, at 8:01 AM, Alejandro Serrano Mena < trupill at gmail.com > wrote: > > > > > > Dear Committee, > > > This proposal looks good to me. The author has done a lot of work to formalize the new rules, and has done a check that no packages using arrow syntax would be broken by this modification. Thus, I recommend we accept this proposal. > > > > > > > > > Apart from the general discussion, I think it might be worth focusing on a specific part of the design: the use of a couple of type families to express "arrow stacks". I am not aware of other GHC extensions depending on particular type families. > > > - As the author discusses, these type families ought to be wired-in, so they can benefit from improvement during type checking. Is this a good choice? It looks to be, but other may have a different opinion. > > > - Would this type family pose a problem for optimization / specialization / ...? > > > > > > > > > Kind regards, > > > Alejandro > > > > > > > > > > > > El lun., 4 may. 2020 a las 23:08, Joachim Breitner (< mail at joachim-breitner.de >) escribió: > > > > > > > > > > Dear Committee > > > > > > > > I took the liberty to re-asssign #303 to Alejandro; the authors > > > > rightfully asked for progress in the discussion thread. > > > > > > > > Cheers, > > > > Joachim > > > > > > > > Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: > > > > > Dear Committee, > > > > > > > > > > this is your secretary speaking: > > > > > > > > > > Constraint based arrow notation > > > > > has been proposed by Aleix King > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/303 > > > > > https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md > > > > > > > > > > I propose Chris Done as the shepherd. > > > > > > > > > > Please guide us to a conclusion as outlined in > > > > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > > > > > > > Thanks, > > > > > Joachim > > > > -- > > > > Joachim Breitner > > > > mail at joachim-breitner.de > > > > http://www.joachim-breitner.de/ > > > > > > > > > > > > _______________________________________________ > > > > ghc-steering-committee mailing list > > > > ghc-steering-committee at haskell.org > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > > > > > > > > > _______________________________________________ > > > 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 May 19 18:30:50 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 19 May 2020 20:30:50 +0200 Subject: [ghc-steering-committee] Please review #275: Rebindable Application, Shepherd: Richard Eisenberg Message-ID: Dear Committee, this is your secretary speaking: Rebindable Application has been proposed by tydeu (Mac Malone) https://github.com/ghc-proposals/ghc-proposals/pull/275 https://github.com/tydeu/ghc-proposals/blob/overloaded-application/proposals/0000-rebindable-application.rst I propose Richard Eisenberg as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Thu May 21 17:45:09 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 21 May 2020 19:45:09 +0200 Subject: [ghc-steering-committee] #216: Qualified Do, final(?) version In-Reply-To: References: <7F02F8C9-1D0A-4F00-976F-7B4BB7E43CE7@live.co.uk> <95F168C6-93A2-4E53-8475-3A934A8473B5@live.co.uk> <352dc3df767053f824846fbb598d5252389958c9.camel@joachim-breitner.de> <9537dc7a39630628c8f4d1fa3ba38658ecd8f4c6.camel@joachim-breitner.de> <212613034a6d9ccfa85118d14fe936178fb6303d.camel@joachim-breitner.de> Message-ID: <6cc863a8f99a9b950e5a44022ab7dcb2ddd8bd34.camel@joachim-breitner.de> Accepted! Phew. Second most-commented proposal done. Am Freitag, den 15.05.2020, 13:54 +0000 schrieb Simon Peyton Jones via ghc-steering-committee: > I think it's good to go now. > > Simon > > > -----Original Message----- > > From: ghc-steering-committee > > On Behalf Of Joachim Breitner > > Sent: 15 May 2020 14:53 > > To: ghc-steering-committee at haskell.org > > Subject: Re: [ghc-steering-committee] #216: Qualified Do, final(?) > > version > > > > Dear Committee, > > > > Facundo Domínguez has updated the proposal to be based on module names > > again, see > > https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000- > > local-do.rst > > (with a wealth of alternatives). > > > > He opted for desugaring to the well-known name, leaving the > > “recognizability” of the feature to other means (module names, > > documentation). > > > > Please have a final quick look if this document is fine to approve, and > > say so. I’ll wait for either explicit nods from people who were > > involved here, or just wait for a few days of silence, before merging > > this. > > > > Cheers, > > Joachim > > > > > > -- > > Joachim Breitner > > mail at joachim-breitner.de > > http://www.joachim-breitner.de/ > > > > > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simonpj at microsoft.com Fri May 22 11:51:49 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 22 May 2020 11:51:49 +0000 Subject: [ghc-steering-committee] Please review again: Make Q (TExp a) into a newtype #195 In-Reply-To: References: Message-ID: Iavor See the GitHub thread. I’m happy to accept. But I’d love that API to be written down. Simon From: Simon Peyton Jones Sent: 15 May 2020 11:13 To: Iavor Diatchki ; ghc-steering-committee Subject: RE: [ghc-steering-committee] Please review again: Make Q (TExp a) into a newtype #195 I’ve posted a comment on GitHub with some more questions. Iavor: please do nag if I am slow. Simon From: ghc-steering-committee > On Behalf Of Iavor Diatchki Sent: 14 May 2020 16:29 To: ghc-steering-committee > Subject: [ghc-steering-committee] Please review again: Make Q (TExp a) into a newtype #195 Hello, I am the shepherd for #195, about a small change to TH, to wrap `Q (TExp a)` into a newtype. This would be quite handy for a variety of reasons described in the proposal and the comments on the proposal thread: https://github.com/ghc-proposals/ghc-proposals/pull/195 During the last discussion we requested the proposal to be modified to clarify some points. Matt has done that, so it is time for another review. The previous discussion thread is here: https://mail.haskell.org/pipermail/ghc-steering-committee/2019-November/001260.html I still think this is a good idea, and recommend acceptance. Since we've already discussed this once, I'll assume acceptance in about a week, if I don't hear from anyone, although I'll wait until at least Simon PJ and Richard confirm that the issues they raised last time have been addressed. -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From trupill at gmail.com Sun May 24 19:19:59 2020 From: trupill at gmail.com (Alejandro Serrano Mena) Date: Sun, 24 May 2020 21:19:59 +0200 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: <916ae81a-890a-4a8f-a35a-f8fbd885df4a@localhost> References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> <916ae81a-890a-4a8f-a35a-f8fbd885df4a@localhost> Message-ID: Hi everybody, The discussion in the GitHub thread seems to have come to a conclusion, and I encourage you to look at the proposal and give your opinion. The author of the proposal has written a very good introduction to the general idea of arrows that is quite useful (or at least has been for me!) to understand the context -> https://github.com/ghc-proposals/ghc-proposals/pull/303#issuecomment-631108435 Everybody that has discussed there seems to be willing to break backwards-compatibility, as the scenario where it breaks is quite rare in practice. In fact, the goal of the proposal is to make those scenarios simpler, so that "control operators" can be more easily used and defined. Note that the proposal also mentions some alternatives or points in the design space: - Should the proposal be under a different extension or under `Arrows`? - Should a flattened or nested tuple representation be used? This comments [ https://github.com/ghc-proposals/ghc-proposals/pull/303#issuecomment-633199848] may give you some additional information. - Should the type families described there be wired-in? Looking forward to hearing from everyone. This is a complex proposal, with possible future ramifications. If there's no discussion in one week, I'll write again to the list. Regards, Alejandro El mar., 19 may. 2020 a las 9:02, Joachim Breitner (< mail at joachim-breitner.de>) escribió: > If there is active discussion, we usually put it back to the previous > state, and wait for discussion to come to conclusions. > > 19.05.2020 08:36:42 Alejandro Serrano Mena : > > Dear Committee, > When I took care of this proposal, the GitHub thread was quite dormant. > However, it seems that right now there's quite some activity, and even > proposals to completely redesign arrows. What is the right approach: let > the discussion cool off, and then ask all of you to review the text (which > I don't think is going to change substantially in any case) or move the > proposal back to the previous state? > > Alejandro > > El vie., 15 may. 2020 a las 11:03, Richard Eisenberg () > escribió: > >> I have some concerns -- mostly: is the improvement worth the >> implementation complexity? I've posted on GitHub. >> >> Richard >> >> On May 15, 2020, at 8:01 AM, Alejandro Serrano Mena >> wrote: >> >> Dear Committee, >> This proposal looks good to me. The author has done a lot of work to >> formalize the new rules, and has done a check that no packages using arrow >> syntax would be broken by this modification. Thus, I recommend we accept >> this proposal. >> >> Apart from the general discussion, I think it might be worth focusing on >> a specific part of the design: the use of a couple of type families to >> express "arrow stacks". I am not aware of other GHC extensions depending on >> particular type families. >> - As the author discusses, these type families ought to be wired-in, so >> they can benefit from improvement during type checking. Is this a good >> choice? It looks to be, but other may have a different opinion. >> - Would this type family pose a problem for optimization / specialization >> / ...? >> >> Kind regards, >> Alejandro >> >> El lun., 4 may. 2020 a las 23:08, Joachim Breitner (< >> mail at joachim-breitner.de>) escribió: >> >>> Dear Committee >>> >>> I took the liberty to re-asssign #303 to Alejandro; the authors >>> rightfully asked for progress in the discussion thread. >>> >>> Cheers, >>> Joachim >>> >>> Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: >>> > Dear Committee, >>> > >>> > this is your secretary speaking: >>> > >>> > Constraint based arrow notation >>> > has been proposed by Aleix King >>> > https://github.com/ghc-proposals/ghc-proposals/pull/303 >>> > >>> https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md >>> > >>> > I propose Chris Done as the shepherd. >>> > >>> > Please guide us to a conclusion as outlined in >>> > https://github.com/ghc-proposals/ghc-proposals#committee-process >>> > >>> > Thanks, >>> > Joachim >>> -- >>> Joachim Breitner >>> mail at joachim-breitner.de >>> http://www.joachim-breitner.de/ >>> >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun May 24 21:51:41 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 24 May 2020 23:51:41 +0200 Subject: [ghc-steering-committee] Please review #292: ByteArray Literals, Shepherd: Vitaly Message-ID: Dear Committee, this is your secretary speaking: ByteArray Literals has been proposed by Andrew Martin (based on a proposal by Oleg Grenus) https://github.com/ghc-proposals/ghc-proposals/pull/292 https://github.com/andrewthad/ghc-proposals/blob/bytearray-literals/proposals/0000-bytearray-literals.rst I propose Vitaly as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From rae at richarde.dev Mon May 25 11:14:53 2020 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 25 May 2020 12:14:53 +0100 Subject: [ghc-steering-committee] Please review #303: Constraint based arrow notation, Shepherd: Alejandro In-Reply-To: References: <43b1824024f79622e11434d50d49ada8e5c02b38.camel@joachim-breitner.de> <0a90720d2488627492dc5823adee3f8514258016.camel@joachim-breitner.de> <916ae81a-890a-4a8f-a35a-f8fbd885df4a@localhost> Message-ID: <9212CD04-ABEC-4709-91EC-F315835A6DD4@richarde.dev> I'm in support of the proposal as written, perhaps with the exception of the special error-handling for ArrowStackTup (which I think is unnecessary). > On May 24, 2020, at 8:19 PM, Alejandro Serrano Mena wrote: > - Should the proposal be under a different extension or under `Arrows`? No. As the proposal authors argue, the backward-compatibility problem is essentially non-existent, because the feature is so inconvenient to use today that no one does. > - Should a flattened or nested tuple representation be used? This comments [https://github.com/ghc-proposals/ghc-proposals/pull/303#issuecomment-633199848 ] may give you some additional information. I prefer the flat tuples. If need be, this can revisited in the future, but the flat tuples seem better today. > - Should the type families described there be wired-in? I don't see a need for this. The type families will necessarily be part of the specification of these features, and so their appearance in error messages are not an example of abstraction leakage. Maybe we want to carefully normaliseType here or there to avoid them unnecessarily, but I see no need to wire-in. Richard > > Looking forward to hearing from everyone. This is a complex proposal, with possible future ramifications. If there's no discussion in one week, I'll write again to the list. > Regards, > Alejandro > > El mar., 19 may. 2020 a las 9:02, Joachim Breitner (>) escribió: > If there is active discussion, we usually put it back to the previous state, and wait for discussion to come to conclusions. > > 19.05.2020 08:36:42 Alejandro Serrano Mena >: > > Dear Committee, > When I took care of this proposal, the GitHub thread was quite dormant. However, it seems that right now there's quite some activity, and even proposals to completely redesign arrows. What is the right approach: let the discussion cool off, and then ask all of you to review the text (which I don't think is going to change substantially in any case) or move the proposal back to the previous state? > > Alejandro > > El vie., 15 may. 2020 a las 11:03, Richard Eisenberg (>) escribió: > I have some concerns -- mostly: is the improvement worth the implementation complexity? I've posted on GitHub. > > Richard > >> On May 15, 2020, at 8:01 AM, Alejandro Serrano Mena > wrote: >> >> Dear Committee, >> This proposal looks good to me. The author has done a lot of work to formalize the new rules, and has done a check that no packages using arrow syntax would be broken by this modification. Thus, I recommend we accept this proposal. >> >> Apart from the general discussion, I think it might be worth focusing on a specific part of the design: the use of a couple of type families to express "arrow stacks". I am not aware of other GHC extensions depending on particular type families. >> - As the author discusses, these type families ought to be wired-in, so they can benefit from improvement during type checking. Is this a good choice? It looks to be, but other may have a different opinion. >> - Would this type family pose a problem for optimization / specialization / ...? >> >> Kind regards, >> Alejandro >> >> El lun., 4 may. 2020 a las 23:08, Joachim Breitner (>) escribió: >> Dear Committee >> >> I took the liberty to re-asssign #303 to Alejandro; the authors >> rightfully asked for progress in the discussion thread. >> >> Cheers, >> Joachim >> >> Am Freitag, den 03.01.2020, 15:20 +0100 schrieb Joachim Breitner: >> > Dear Committee, >> > >> > this is your secretary speaking: >> > >> > Constraint based arrow notation >> > has been proposed by Aleix King >> > https://github.com/ghc-proposals/ghc-proposals/pull/303 >> > https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-notation/proposals/0000-constraint-based-arrow-notation.md >> > >> > I propose Chris Done as the shepherd. >> > >> > Please guide us to a conclusion as outlined in >> > https://github.com/ghc-proposals/ghc-proposals#committee-process >> > >> > Thanks, >> > Joachim >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue May 26 15:50:57 2020 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 26 May 2020 15:50:57 +0000 Subject: [ghc-steering-committee] #195 Message-ID: Iavor Matthew says > Please can we move on from this proposal! You are the shepherd. Iavor. Bringing the discussion to a conclusion is your role. I'm not arguing against acceptance. I have reservations about our overall TH story, but we should not let the best be the enemy of the good. Let's keep moving. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Tue May 26 16:53:03 2020 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 26 May 2020 09:53:03 -0700 Subject: [ghc-steering-committee] #195 In-Reply-To: References: Message-ID: Hello, OK, I did say that I'd take silence as acceptance, so we are unanimous in accepting #195. Joachim, could you mark it as accepted and merge it in? -Iavor On Tue, May 26, 2020 at 8:51 AM Simon Peyton Jones via ghc-steering-committee wrote: > Iavor > > Matthew says > > > Please can we move on from this proposal! > > You are the shepherd. Iavor. Bringing the discussion to a conclusion is > your role. > > I’m not arguing against acceptance. I have reservations about our > overall TH story, but we should not let the best be the enemy of the good. > Let’s keep moving. > > Simon > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue May 26 16:55:19 2020 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 26 May 2020 18:55:19 +0200 Subject: [ghc-steering-committee] #195 In-Reply-To: References: Message-ID: <1fde538abc3b75f579f8d9a6020b37c8ab23eb75.camel@joachim-breitner.de> Hi, will do Cheers, Joachim Am Dienstag, den 26.05.2020, 09:53 -0700 schrieb Iavor Diatchki: > Hello, > > OK, I did say that I'd take silence as acceptance, so we are unanimous in accepting #195. > Joachim, could you mark it as accepted and merge it in? > > -Iavor > > > > > > On Tue, May 26, 2020 at 8:51 AM Simon Peyton Jones via ghc-steering-committee wrote: > > Iavor > > Matthew says > > > Please can we move on from this proposal! > > You are the shepherd. Iavor. Bringing the discussion to a conclusion is your role. > > I’m not arguing against acceptance. I have reservations about our overall TH story, but we should not let the best be the enemy of the good. Let’s keep moving. > > Simon > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee at haskell.org > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/