From chak at justtesting.org Fri Jun 1 07:30:44 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Fri, 1 Jun 2018 17:30:44 +1000 Subject: [ghc-steering-committee] Proposal: Or patterns #43 (Round 2) Message-ID: <6E4DEE9A-872E-4F67-AE9A-FEBD48BDC640@justtesting.org> We now have a revised version of the ”Or pattern” proposal #43 to consider: (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-patterns.rst (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 You may remember that we discuss this a while back https://mail.haskell.org/pipermail/ghc-steering-committee/2017-November/000231.html and finally decided to bounce it back to the authors with the following recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-358189327 We previously decided that we are inclined to accept this proposal if the authors change the points that we highlighted. Judging from the conversation of SimonPJ and Richard with the author on the GitHub thread, it appears to me that most of the issues have been addressed. However, Simon’s point • "Patterns that bind existentials, dictionaries, or equalities are rejected by the type checker". I disagree. Earlier I suggested "no variable bound by an or-pattern can have a type that mentions an existential variable bound by the or-pattern". That is much more friendly because you can still match against an existential constructor; you just can’t bind an existential variable. from > still doesn’t seem to be addressed, or am I misunderstanding? Overall, I propose to accept the proposal, possibly requiring that the above point be addressed. What do you all think? Cheers, Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From mail at joachim-breitner.de Sat Jun 2 17:44:37 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 02 Jun 2018 19:44:37 +0200 Subject: [ghc-steering-committee] Need more Trac tickets In-Reply-To: <249C4C71-370F-43C0-8CC9-36BD2799F07F@cs.brynmawr.edu> References: <249C4C71-370F-43C0-8CC9-36BD2799F07F@cs.brynmawr.edu> Message-ID: <6d91e7f9df1ae43ebd21f31f1bba2241d5600f68.camel@joachim-breitner.de> Hi, Am Dienstag, den 29.05.2018, 15:59 -0400 schrieb Richard Eisenberg: > Ryan Scott very helpfully this morning labeled the Trac tickets that > have grown from proposals. However, there remain a good many > proposals without corresponding Trac tickets. > > I propose that we make it a shepherd's responsibility to make sure > that a Trac ticket is created upon the acceptance of a proposal. > Specifically: a shepherd should encourage the proposer to make the > Trac ticket, and if this fails to happen, then for the shepherd to do > it himself. (Why have the proposer do it? 1. To lessen the burden on > the shepherd. 2. To subtly encourage the proposer to ponder the > possibility of implementing.) > > What do we think? We'll still have to make tickets for those accepted > proposals but with not tickets... I am not too keen on additional red tape, and would rather leave the process organically. If anyone, whether shepherd, proposer or anyone else is attached enough to the proposal to create a ticket. If not, then the proposal was probably a good but not very important idea, and may – as far as I am concerned – stay in the “can be implemented whenever someone feels like it” state eternally. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sat Jun 2 17:49:11 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 02 Jun 2018 19:49:11 +0200 Subject: [ghc-steering-committee] Array resizing primitives (#121), proposal: accept with modifications In-Reply-To: References: Message-ID: <6909d9ce6a90d971e65d0b98ea45df830cc25b77.camel@joachim-breitner.de> Hi, Am Freitag, den 18.05.2018, 09:24 +0100 schrieb Simon Marlow: > I propose that we accept https://github.com/ghc-proposals/ghc-proposals/pull/121 > With one modification (below). we all trust Simon, so this can be considered accepted. @Simon, do you want to apply this change > Suggested modifications: > * Remove the ArrayArray# primitives, add UniftedArray# primitives instead (see https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0021-unlifted-array.rst) to the proposal before I merge it? You should have the necessary permissions to edit the pull request directly. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sat Jun 2 17:53:33 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 02 Jun 2018 19:53:33 +0200 Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept In-Reply-To: References: Message-ID: Hi, Am Montag, den 30.04.2018, 19:20 -0500 schrieb Christopher Allen: > If no objections are raised, it should be assumed that no one opposes > this proposal. while the responses where not very enthusiastic, there was no actual opposition. Any lurking opposition ought to be raised soon. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sat Jun 2 18:08:48 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 02 Jun 2018 20:08:48 +0200 Subject: [ghc-steering-committee] Proposal: Binding existential type variables (#96) In-Reply-To: References: Message-ID: Hi, Am Sonntag, den 25.03.2018, 23:23 +0100 schrieb Roman Leshchinskiy: > The proposal is to add a way to name existential type variables in pattern matches: https://github.com/ghc-proposals/ghc-proposals/pull/96. since this proposal has been proposed, we have two new related (and partly competing) proposals (#126 and #128), had some good discussion and there is even talk of writing a paper. In light of that, I think we should either reject #96 in the current form, or at least bump it back to the discussion phase until we have settled on a final form. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rae at cs.brynmawr.edu Sat Jun 2 19:37:08 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sat, 2 Jun 2018 15:37:08 -0400 Subject: [ghc-steering-committee] Need more Trac tickets In-Reply-To: <6d91e7f9df1ae43ebd21f31f1bba2241d5600f68.camel@joachim-breitner.de> References: <249C4C71-370F-43C0-8CC9-36BD2799F07F@cs.brynmawr.edu> <6d91e7f9df1ae43ebd21f31f1bba2241d5600f68.camel@joachim-breitner.de> Message-ID: This idea originally rose during a conversation where a collaborator was looking for proposals to implement. He had assumed that all proposals in the repo were unimplemented (otherwise, in his thinking, they weren't proposals anymore). In any case, we discovered that it's not easy to tell whether a proposal is implemented or not. If it can be assumed that all implemented proposals have tickets, then I suppose we're OK, as long as the proposal is updated with the ticket. Richard > On Jun 2, 2018, at 1:44 PM, Joachim Breitner wrote: > > Hi, > > Am Dienstag, den 29.05.2018, 15:59 -0400 schrieb Richard Eisenberg: >> Ryan Scott very helpfully this morning labeled the Trac tickets that >> have grown from proposals. However, there remain a good many >> proposals without corresponding Trac tickets. >> >> I propose that we make it a shepherd's responsibility to make sure >> that a Trac ticket is created upon the acceptance of a proposal. >> Specifically: a shepherd should encourage the proposer to make the >> Trac ticket, and if this fails to happen, then for the shepherd to do >> it himself. (Why have the proposer do it? 1. To lessen the burden on >> the shepherd. 2. To subtly encourage the proposer to ponder the >> possibility of implementing.) >> >> What do we think? We'll still have to make tickets for those accepted >> proposals but with not tickets... > > I am not too keen on additional red tape, and would rather leave the > process organically. If anyone, whether shepherd, proposer or anyone > else is attached enough to the proposal to create a ticket. If not, > then the proposal was probably a good but not very important idea, and > may – as far as I am concerned – stay in the “can be implemented > whenever someone feels like it” state eternally. > > 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 Sat Jun 2 19:45:48 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 02 Jun 2018 21:45:48 +0200 Subject: [ghc-steering-committee] Need more Trac tickets In-Reply-To: References: <249C4C71-370F-43C0-8CC9-36BD2799F07F@cs.brynmawr.edu> <6d91e7f9df1ae43ebd21f31f1bba2241d5600f68.camel@joachim-breitner.de> Message-ID: <95d675e691f00b89685b093e336b5224d028c32d.camel@joachim-breitner.de> Hi, that sounds like we should use an “Implemented” label to clearly mark implemented proposals? Cheers, Joachim Am Samstag, den 02.06.2018, 15:37 -0400 schrieb Richard Eisenberg: > This idea originally rose during a conversation where a collaborator was looking for proposals to implement. He had assumed that all proposals in the repo were unimplemented (otherwise, in his thinking, they weren't proposals anymore). In any case, we discovered that it's not easy to tell whether a proposal is implemented or not. If it can be assumed that all implemented proposals have tickets, then I suppose we're OK, as long as the proposal is updated with the ticket. > > Richard > > > On Jun 2, 2018, at 1:44 PM, Joachim Breitner wrote: > > > > Hi, > > > > Am Dienstag, den 29.05.2018, 15:59 -0400 schrieb Richard Eisenberg: > > > Ryan Scott very helpfully this morning labeled the Trac tickets that > > > have grown from proposals. However, there remain a good many > > > proposals without corresponding Trac tickets. > > > > > > I propose that we make it a shepherd's responsibility to make sure > > > that a Trac ticket is created upon the acceptance of a proposal. > > > Specifically: a shepherd should encourage the proposer to make the > > > Trac ticket, and if this fails to happen, then for the shepherd to do > > > it himself. (Why have the proposer do it? 1. To lessen the burden on > > > the shepherd. 2. To subtly encourage the proposer to ponder the > > > possibility of implementing.) > > > > > > What do we think? We'll still have to make tickets for those accepted > > > proposals but with not tickets... > > > > I am not too keen on additional red tape, and would rather leave the > > process organically. If anyone, whether shepherd, proposer or anyone > > else is attached enough to the proposal to create a ticket. If not, > > then the proposal was probably a good but not very important idea, and > > may – as far as I am concerned – stay in the “can be implemented > > whenever someone feels like it” state eternally. > > > > 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rae at cs.brynmawr.edu Sat Jun 2 19:48:21 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sat, 2 Jun 2018 15:48:21 -0400 Subject: [ghc-steering-committee] Need more Trac tickets In-Reply-To: <95d675e691f00b89685b093e336b5224d028c32d.camel@joachim-breitner.de> References: <249C4C71-370F-43C0-8CC9-36BD2799F07F@cs.brynmawr.edu> <6d91e7f9df1ae43ebd21f31f1bba2241d5600f68.camel@joachim-breitner.de> <95d675e691f00b89685b093e336b5224d028c32d.camel@joachim-breitner.de> Message-ID: Perhaps, but can we do that on a file in a repo? I thought labels were attached to PRs, which are somewhat historical once the proposal is accepted. > On Jun 2, 2018, at 3:45 PM, Joachim Breitner wrote: > > Hi, > > that sounds like we should use an “Implemented” label to clearly mark > implemented proposals? > > Cheers, > Joachim > > Am Samstag, den 02.06.2018, 15:37 -0400 schrieb Richard Eisenberg: >> This idea originally rose during a conversation where a collaborator was looking for proposals to implement. He had assumed that all proposals in the repo were unimplemented (otherwise, in his thinking, they weren't proposals anymore). In any case, we discovered that it's not easy to tell whether a proposal is implemented or not. If it can be assumed that all implemented proposals have tickets, then I suppose we're OK, as long as the proposal is updated with the ticket. >> >> Richard >> >>> On Jun 2, 2018, at 1:44 PM, Joachim Breitner wrote: >>> >>> Hi, >>> >>> Am Dienstag, den 29.05.2018, 15:59 -0400 schrieb Richard Eisenberg: >>>> Ryan Scott very helpfully this morning labeled the Trac tickets that >>>> have grown from proposals. However, there remain a good many >>>> proposals without corresponding Trac tickets. >>>> >>>> I propose that we make it a shepherd's responsibility to make sure >>>> that a Trac ticket is created upon the acceptance of a proposal. >>>> Specifically: a shepherd should encourage the proposer to make the >>>> Trac ticket, and if this fails to happen, then for the shepherd to do >>>> it himself. (Why have the proposer do it? 1. To lessen the burden on >>>> the shepherd. 2. To subtly encourage the proposer to ponder the >>>> possibility of implementing.) >>>> >>>> What do we think? We'll still have to make tickets for those accepted >>>> proposals but with not tickets... >>> >>> I am not too keen on additional red tape, and would rather leave the >>> process organically. If anyone, whether shepherd, proposer or anyone >>> else is attached enough to the proposal to create a ticket. If not, >>> then the proposal was probably a good but not very important idea, and >>> may – as far as I am concerned – stay in the “can be implemented >>> whenever someone feels like it” state eternally. >>> >>> 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/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Sat Jun 2 19:53:04 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 02 Jun 2018 21:53:04 +0200 Subject: [ghc-steering-committee] Need more Trac tickets In-Reply-To: References: <249C4C71-370F-43C0-8CC9-36BD2799F07F@cs.brynmawr.edu> <6d91e7f9df1ae43ebd21f31f1bba2241d5600f68.camel@joachim-breitner.de> <95d675e691f00b89685b093e336b5224d028c32d.camel@joachim-breitner.de> Message-ID: <37ed013c4e77405f85669b53be9a201863f2713c.camel@joachim-breitner.de> Hi, hmm, good point… ok, let’s stick to the `implemented::` header in the proposal files to record the implementation status. We can eventually source that and create nice reports. Cheers, Joachim Am Samstag, den 02.06.2018, 15:48 -0400 schrieb Richard Eisenberg: > Perhaps, but can we do that on a file in a repo? I thought labels were attached to PRs, which are somewhat historical once the proposal is accepted. > > > On Jun 2, 2018, at 3:45 PM, Joachim Breitner wrote: > > > > Hi, > > > > that sounds like we should use an “Implemented” label to clearly mark > > implemented proposals? > > > > Cheers, > > Joachim > > > > Am Samstag, den 02.06.2018, 15:37 -0400 schrieb Richard Eisenberg: > > > This idea originally rose during a conversation where a collaborator was looking for proposals to implement. He had assumed that all proposals in the repo were unimplemented (otherwise, in his thinking, they weren't proposals anymore). In any case, we discovered that it's not easy to tell whether a proposal is implemented or not. If it can be assumed that all implemented proposals have tickets, then I suppose we're OK, as long as the proposal is updated with the ticket. > > > > > > Richard > > > > > > > On Jun 2, 2018, at 1:44 PM, Joachim Breitner wrote: > > > > > > > > Hi, > > > > > > > > Am Dienstag, den 29.05.2018, 15:59 -0400 schrieb Richard Eisenberg: > > > > > Ryan Scott very helpfully this morning labeled the Trac tickets that > > > > > have grown from proposals. However, there remain a good many > > > > > proposals without corresponding Trac tickets. > > > > > > > > > > I propose that we make it a shepherd's responsibility to make sure > > > > > that a Trac ticket is created upon the acceptance of a proposal. > > > > > Specifically: a shepherd should encourage the proposer to make the > > > > > Trac ticket, and if this fails to happen, then for the shepherd to do > > > > > it himself. (Why have the proposer do it? 1. To lessen the burden on > > > > > the shepherd. 2. To subtly encourage the proposer to ponder the > > > > > possibility of implementing.) > > > > > > > > > > What do we think? We'll still have to make tickets for those accepted > > > > > proposals but with not tickets... > > > > > > > > I am not too keen on additional red tape, and would rather leave the > > > > process organically. If anyone, whether shepherd, proposer or anyone > > > > else is attached enough to the proposal to create a ticket. If not, > > > > then the proposal was probably a good but not very important idea, and > > > > may – as far as I am concerned – stay in the “can be implemented > > > > whenever someone feels like it” state eternally. > > > > > > > > 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/ > > _______________________________________________ > > 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Sat Jun 2 20:04:55 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat, 2 Jun 2018 13:04:55 -0700 Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept In-Reply-To: References: Message-ID: Well, I think it is a bad idea. Obviously I don't think it has a huge impact on the language, but I think it encourages poor style, for very questionable befits. This is quite subjective, of course, but I think that this choice is at odds with Haskell's elegant surface syntax. We don't allow repeated punctuation in written prose,,,, why would we want in our programs?,,, On Sat, Jun 2, 2018, 10:53 AM Joachim Breitner wrote: > Hi, > > Am Montag, den 30.04.2018, 19:20 -0500 schrieb Christopher Allen: > > If no objections are raised, it should be assumed that no one opposes > > this proposal. > > while the responses where not very enthusiastic, there was no actual > opposition. Any lurking opposition ought to be raised soon. > > Cheers, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Fri Jun 8 19:53:35 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 8 Jun 2018 20:53:35 +0100 Subject: [ghc-steering-committee] Proposal: Or patterns #43 (Round 2) In-Reply-To: <6E4DEE9A-872E-4F67-AE9A-FEBD48BDC640@justtesting.org> References: <6E4DEE9A-872E-4F67-AE9A-FEBD48BDC640@justtesting.org> Message-ID: +1, but we should hear from Simon about the existential point. On 1 June 2018 at 08:30, Manuel M T Chakravarty wrote: > We now have a revised version of the ”Or pattern” proposal #43 to consider: > > (formatted) https://github.com/osa1/ghc-proposals/blob/or_ > patterns/proposals/0000-or-patterns.rst > (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 > > You may remember that we discuss this a while back > > https://mail.haskell.org/pipermail/ghc-steering-committee/ > 2017-November/000231.html > > and finally decided to bounce it back to the authors with the following > recommendation: > > https://github.com/ghc-proposals/ghc-proposals/pull/43# > issuecomment-358189327 > > We previously decided that we are inclined to accept this proposal if the > authors change the points that we highlighted. Judging from the > conversation of SimonPJ and Richard with the author on the GitHub thread, > it appears to me that most of the issues have been addressed. However, > Simon’s point > > • "Patterns that bind existentials, dictionaries, or equalities are > rejected by the type checker". I disagree. Earlier I suggested "no variable > bound by an or-pattern can have a type that mentions an existential > variable bound by the or-pattern". That is much more friendly because you > can still match against an existential constructor; you just can’t bind an > existential variable. > > from issuecomment-368933401> still doesn’t seem to be addressed, or am I > misunderstanding? > > Overall, I propose to accept the proposal, possibly requiring that the > above point be addressed. > > What do you all think? > > Cheers, > Manuel > > > _______________________________________________ > 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 Jun 8 22:16:34 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 8 Jun 2018 22:16:34 +0000 Subject: [ghc-steering-committee] Proposal: Or patterns #43 (Round 2) In-Reply-To: References: <6E4DEE9A-872E-4F67-AE9A-FEBD48BDC640@justtesting.org> Message-ID: See my reply on the Github thread. Richard what do you think? Can you post the paper? Simon From: ghc-steering-committee On Behalf Of Simon Marlow Sent: 08 June 2018 20:54 To: Manuel M T Chakravarty Cc: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Proposal: Or patterns #43 (Round 2) +1, but we should hear from Simon about the existential point. On 1 June 2018 at 08:30, Manuel M T Chakravarty > wrote: We now have a revised version of the ”Or pattern” proposal #43 to consider: (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-patterns.rst (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 You may remember that we discuss this a while back https://mail.haskell.org/pipermail/ghc-steering-committee/2017-November/000231.html and finally decided to bounce it back to the authors with the following recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-358189327 We previously decided that we are inclined to accept this proposal if the authors change the points that we highlighted. Judging from the conversation of SimonPJ and Richard with the author on the GitHub thread, it appears to me that most of the issues have been addressed. However, Simon’s point • "Patterns that bind existentials, dictionaries, or equalities are rejected by the type checker". I disagree. Earlier I suggested "no variable bound by an or-pattern can have a type that mentions an existential variable bound by the or-pattern". That is much more friendly because you can still match against an existential constructor; you just can’t bind an existential variable. from > still doesn’t seem to be addressed, or am I misunderstanding? Overall, I propose to accept the proposal, possibly requiring that the above point be addressed. What do you all think? Cheers, Manuel _______________________________________________ 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 cs.brynmawr.edu Wed Jun 13 15:19:39 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 13 Jun 2018 11:19:39 -0400 Subject: [ghc-steering-committee] Proposal: Or patterns #43 (Round 2) In-Reply-To: References: <6E4DEE9A-872E-4F67-AE9A-FEBD48BDC640@justtesting.org> Message-ID: The paper is up at https://cs.brynmawr.edu/~rae/papers/2018/pat-tyvars/pat-tyvars.pdf But do see recent conversation on the ticket, as this may be undergoing more revision, allowing, say, existentials to work with this feature. Richard > On Jun 8, 2018, at 6:16 PM, Simon Peyton Jones via ghc-steering-committee wrote: > > See my reply on the Github thread. > Richard what do you think? Can you post the paper? > > Simon > > From: ghc-steering-committee On Behalf Of Simon Marlow > Sent: 08 June 2018 20:54 > To: Manuel M T Chakravarty > Cc: ghc-steering-committee at haskell.org > Subject: Re: [ghc-steering-committee] Proposal: Or patterns #43 (Round 2) > > +1, but we should hear from Simon about the existential point. > > On 1 June 2018 at 08:30, Manuel M T Chakravarty > wrote: > We now have a revised version of the ”Or pattern” proposal #43 to consider: > > (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or- patterns.rst > (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 > > You may remember that we discuss this a while back > > https://mail.haskell.org/pipermail/ghc-steering-committee/2017-November/000231.html > > and finally decided to bounce it back to the authors with the following recommendation: > > https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-358189327 > > We previously decided that we are inclined to accept this proposal if the authors change the points that we highlighted. Judging from the conversation of SimonPJ and Richard with the author on the GitHub thread, it appears to me that most of the issues have been addressed. However, Simon’s point > > • "Patterns that bind existentials, dictionaries, or equalities are rejected by the type checker". I disagree. Earlier I suggested "no variable bound by an or-pattern can have a type that mentions an existential variable bound by the or-pattern". That is much more friendly because you can still match against an existential constructor; you just can’t bind an existential variable. > > from > still doesn’t seem to be addressed, or am I misunderstanding? > > Overall, I propose to accept the proposal, possibly requiring that the above point be addressed. > > What do you all think? > > Cheers, > Manuel > > > _______________________________________________ > 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 Wed Jun 13 20:54:36 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 13 Jun 2018 13:54:36 -0700 Subject: [ghc-steering-committee] Kinds without promotion (#106) Message-ID: Hello, it's been a couple of months since this was submitted to the committee, so I'd be interested to get some feedback. In summary, this proposal introduces a mechanism for defining new kinds without having to promote a datatype, thus avoiding pollution of the value level name space with unused constructors. This is not a particularly new idea, and folks have been asking for it for at least 6 years now (e.g., see #6024). A few of our projects at work make use of a lot of type-level indexing (using GATs, etc.) and while things mostly work pretty well, the clunkiness of having to promote datatypes when you just want to define a new kind is something that keeps popping up over and over again, which is why I was motivated to submit the proposal. Thoughts? -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Wed Jun 13 23:18:45 2018 From: cma at bitemyapp.com (Christopher Allen) Date: Wed, 13 Jun 2018 18:18:45 -0500 Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) Message-ID: The proposal I'm reviewing is: Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski https://github.com/ghc-proposals/ghc-proposals/pull/28 Having reviewed the proposal and gone through some of the GHC Trac history, I think we should accept this proposal. There are a couple of open questions, ambiguities, and potential downsides but the overall complexity of the proposal doesn't cause me great concern. Cheers, Chris Allen From rae at cs.brynmawr.edu Thu Jun 14 03:01:30 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 13 Jun 2018 23:01:30 -0400 Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) In-Reply-To: References: Message-ID: I have some reservations with the current proposal. I've posted on GitHub. Richard > On Jun 13, 2018, at 7:18 PM, Christopher Allen wrote: > > The proposal I'm reviewing is: > > Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski > > https://github.com/ghc-proposals/ghc-proposals/pull/28 > > Having reviewed the proposal and gone through some of the GHC Trac > history, I think we should accept this proposal. There are a couple of > open questions, ambiguities, and potential downsides but the overall > complexity of the proposal doesn't cause me great concern. > > > Cheers, > Chris Allen > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From simonpj at microsoft.com Fri Jun 15 09:26:29 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 15 Jun 2018 09:26:29 +0000 Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) In-Reply-To: References: Message-ID: I'm quite doubtful. I've posted a comment on the ticket to say why. Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Christopher Allen | Sent: 14 June 2018 00:19 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) | | The proposal I'm reviewing is: | | Bundling patterns with type synonyms by Bertram Felgenhauer and Joe | Hermaszewski | | https://github.com/ghc-proposals/ghc-proposals/pull/28 | | Having reviewed the proposal and gone through some of the GHC Trac history, | I think we should accept this proposal. There are a couple of open | questions, ambiguities, and potential downsides but the overall complexity | of the proposal doesn't cause me great concern. | | | Cheers, | Chris Allen | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Sat Jun 16 07:41:06 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 16 Jun 2018 09:41:06 +0200 Subject: [ghc-steering-committee] Proposal: Binding existential type variables (#96) In-Reply-To: References: Message-ID: <1a6201c0d0ce4019830e3680f1209c21adbe0636.camel@joachim-breitner.de> Hi, Am Samstag, den 02.06.2018, 20:08 +0200 schrieb Joachim Breitner: > Am Sonntag, den 25.03.2018, 23:23 +0100 schrieb Roman Leshchinskiy: > > The proposal is to add a way to name existential type variables in pattern matches: https://github.com/ghc-proposals/ghc-proposals/pull/96. > > since this proposal has been proposed, we have two new related (and > partly competing) proposals (#126 and #128), had some good discussion > and there is even talk of writing a paper. In light of that, I think we > should either reject #96 in the current form, or at least bump it back > to the discussion phase until we have settled on a final form. in the meantime we even have a paper that describes #126 and #128: https://arxiv.org/abs/1806.03476 which also describes why #96 may not be the best way forward. I asked at https://github.com/ghc-proposals/ghc-proposals/pull/96#issuecomment-396581800 if anyone still feels attached to that proposal, and nobody responded. Hence, I think we can safely reject this proposal (and focus on the other two). Roman, do you agree? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From chak at justtesting.org Sat Jun 16 08:33:17 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sat, 16 Jun 2018 18:33:17 +1000 Subject: [ghc-steering-committee] Proposal: Binding existential type variables (#96) In-Reply-To: <1a6201c0d0ce4019830e3680f1209c21adbe0636.camel@joachim-breitner.de> References: <1a6201c0d0ce4019830e3680f1209c21adbe0636.camel@joachim-breitner.de> Message-ID: <2D5A47F5-4095-4A30-B33E-1964DA3C6421@justtesting.org> Sounds good to me. Manuel > Am 16.06.2018 um 17:41 schrieb Joachim Breitner : > > Hi, > > Am Samstag, den 02.06.2018, 20:08 +0200 schrieb Joachim Breitner: >> Am Sonntag, den 25.03.2018, 23:23 +0100 schrieb Roman Leshchinskiy: >>> The proposal is to add a way to name existential type variables in pattern matches: https://github.com/ghc-proposals/ghc-proposals/pull/96. >> >> since this proposal has been proposed, we have two new related (and >> partly competing) proposals (#126 and #128), had some good discussion >> and there is even talk of writing a paper. In light of that, I think we >> should either reject #96 in the current form, or at least bump it back >> to the discussion phase until we have settled on a final form. > > in the meantime we even have a paper that describes #126 and #128: > https://arxiv.org/abs/1806.03476 > which also describes why #96 may not be the best way forward. > > I asked at > https://github.com/ghc-proposals/ghc-proposals/pull/96#issuecomment-396581800 > if anyone still feels attached to that proposal, and nobody responded. > Hence, I think we can safely reject this proposal (and focus on the > other two). > > Roman, do you agree? > > 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 rae at cs.brynmawr.edu Mon Jun 18 02:33:36 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 17 Jun 2018 22:33:36 -0400 Subject: [ghc-steering-committee] Proposal: Binding existential type variables (#96) In-Reply-To: <2D5A47F5-4095-4A30-B33E-1964DA3C6421@justtesting.org> References: <1a6201c0d0ce4019830e3680f1209c21adbe0636.camel@joachim-breitner.de> <2D5A47F5-4095-4A30-B33E-1964DA3C6421@justtesting.org> Message-ID: Yes, I think we should reject in favor of #126. > On Jun 16, 2018, at 4:33 AM, Manuel M T Chakravarty wrote: > > Sounds good to me. > > Manuel > >> Am 16.06.2018 um 17:41 schrieb Joachim Breitner : >> >> Hi, >> >> Am Samstag, den 02.06.2018, 20:08 +0200 schrieb Joachim Breitner: >>> Am Sonntag, den 25.03.2018, 23:23 +0100 schrieb Roman Leshchinskiy: >>>> The proposal is to add a way to name existential type variables in pattern matches: https://github.com/ghc-proposals/ghc-proposals/pull/96. >>> >>> since this proposal has been proposed, we have two new related (and >>> partly competing) proposals (#126 and #128), had some good discussion >>> and there is even talk of writing a paper. In light of that, I think we >>> should either reject #96 in the current form, or at least bump it back >>> to the discussion phase until we have settled on a final form. >> >> in the meantime we even have a paper that describes #126 and #128: >> https://arxiv.org/abs/1806.03476 >> which also describes why #96 may not be the best way forward. >> >> I asked at >> https://github.com/ghc-proposals/ghc-proposals/pull/96#issuecomment-396581800 >> if anyone still feels attached to that proposal, and nobody responded. >> Hence, I think we can safely reject this proposal (and focus on the >> other two). >> >> Roman, do you agree? >> >> 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 simonpj at microsoft.com Mon Jun 18 13:02:04 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 18 Jun 2018 13:02:04 +0000 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> Message-ID: Dear steering committee The or-pattern proposal has teen "under consideration" by this committee since 19 August 2017. That is nearly a year! I think we can decide. I favour acceptance subject to the points in my comment here https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-395906439 1. Typing rules, dealing with existentials, dictionaries etc. I make a concrete proposal and would welcome critique. https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-396851582 2. Syntax. I really think we should not use "|" because we already use that for guards -- and moreover (as the comment says) there's an obvious way to use guards *in* patterns not just *after* patterns. If not "|" then what? I'm ok with ";". But I guess "||" could also be considered. I think we owe it to the proposer not to drag our feet any more. Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Manuel M T Chakravarty | Sent: 01 November 2017 23:58 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Proposal: Or patterns (#43) | | Folks, | | I am sorry for taking a long time to get us going on this proposal. | | The ”Or pattern” proposal is about an extension to pattern matching: | | (formatted) | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-or- | patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 | d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&s | data=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D&reserved=0 | (PR thread) | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fghc-proposals%2Fghc- | proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54 | 5030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 | 5951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmhw%3D&reserved=0 | | Its basic idea is simple: allow multiple alternative patterns for each | alternative during pattern matching. Unfortunately, the interaction with | guards and some other languages features makes it significantly less | straight forward than one might initially think. | | I propose to accept this proposal provided we can agree to use the ”first | semantics” (aka single-match semantics) — see | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% | 2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-or- | patterns.rst%23interaction-with- | guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08d52184 | 6116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&sdata=Z | 5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0 | | My reason for insisting on the first semantics is that it is a simple | extension of the existing pattern semantics in the Report, whereas the | second semantics requires a more profound, non-local change. This, in | particular, also makes it easier to understand the implications of the first | semantics. (Also, OCaml has made that same choice.) | | However, even with the first semantics, I still have one concern about this | proposal. The story about the interaction with existential types is | currently only partial and there is no discussion of the interaction with | GADTs. It might be reasonable to ask for a complete specification of the | interaction with these features before making a final determination on this | proposal. Nevertheless, this proposal is quite elaborate and quite some work | has gone into it. Hence, I think, we owe it the authors of the proposal to | at least make a preliminary determination at this point. (In particular, if | it is not going to fly regardless of how GADTs are handled, we should say so | now.) | | Cheers, | Manuel | | PS: It is worth noting that Swift solved the problem of deciding between the | first and second semantics by choosing a syntax that avoids the ambiguity: | . It is | difficult to adapt this syntax to Haskell. If it where possible, I think, | this would be the best solution. | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From rae at cs.brynmawr.edu Mon Jun 18 16:12:35 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 18 Jun 2018 12:12:35 -0400 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> Message-ID: <3F540834-A309-47E5-BE7C-BFC4F0460F3A@cs.brynmawr.edu> Yes, I'm in favor of accepting. > On Jun 18, 2018, at 9:02 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > Dear steering committee > > The or-pattern proposal has teen "under consideration" by this committee since 19 August 2017. That is nearly a year! > > I think we can decide. I favour acceptance subject to the points in my comment here > https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-395906439 > > 1. Typing rules, dealing with existentials, dictionaries etc. > I make a concrete proposal and would welcome critique. > https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-396851582 > > 2. Syntax. I really think we should not use "|" because we already use that > for guards -- and moreover (as the comment says) there's an obvious way to > use guards *in* patterns not just *after* patterns. > > If not "|" then what? I'm ok with ";". But I guess "||" could also be considered. > > I think we owe it to the proposer not to drag our feet any more. > > Simon > > > | -----Original Message----- > | From: ghc-steering-committee On > | Behalf Of Manuel M T Chakravarty > | Sent: 01 November 2017 23:58 > | To: ghc-steering-committee at haskell.org > | Subject: [ghc-steering-committee] Proposal: Or patterns (#43) > | > | Folks, > | > | I am sorry for taking a long time to get us going on this proposal. > | > | The ”Or pattern” proposal is about an extension to pattern matching: > | > | (formatted) > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > | 2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-or- > | patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08 > | d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&s > | data=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D&reserved=0 > | (PR thread) > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > | 2Fghc-proposals%2Fghc- > | proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad54 > | 5030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 > | 5951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmhw%3D&reserved=0 > | > | Its basic idea is simple: allow multiple alternative patterns for each > | alternative during pattern matching. Unfortunately, the interaction with > | guards and some other languages features makes it significantly less > | straight forward than one might initially think. > | > | I propose to accept this proposal provided we can agree to use the ”first > | semantics” (aka single-match semantics) — see > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > | 2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-or- > | patterns.rst%23interaction-with- > | guards&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08d52184 > | 6116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&sdata=Z > | 5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0 > | > | My reason for insisting on the first semantics is that it is a simple > | extension of the existing pattern semantics in the Report, whereas the > | second semantics requires a more profound, non-local change. This, in > | particular, also makes it easier to understand the implications of the first > | semantics. (Also, OCaml has made that same choice.) > | > | However, even with the first semantics, I still have one concern about this > | proposal. The story about the interaction with existential types is > | currently only partial and there is no discussion of the interaction with > | GADTs. It might be reasonable to ask for a complete specification of the > | interaction with these features before making a final determination on this > | proposal. Nevertheless, this proposal is quite elaborate and quite some work > | has gone into it. Hence, I think, we owe it the authors of the proposal to > | at least make a preliminary determination at this point. (In particular, if > | it is not going to fly regardless of how GADTs are handled, we should say so > | now.) > | > | Cheers, > | Manuel > | > | PS: It is worth noting that Swift solved the problem of deciding between the > | first and second semantics by choosing a syntax that avoids the ambiguity: > | | apple.com%2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptual%2FSwift_P > | rogramming_Language%2FStatements.html%23%2F%2Fapple_ref%2Fswift%2Fgrammar%2F > | switch- > | statement&data=02%7C01%7Csimonpj%40microsoft.com%7Cc41b6be72ad545030e3c08d52 > | 1846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&sdat > | a=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reserved=0>. It is > | difficult to adapt this syntax to Haskell. If it where possible, I think, > | this would be the best solution. > | _______________________________________________ > | 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 iavor.diatchki at gmail.com Mon Jun 18 17:58:48 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 18 Jun 2018 10:58:48 -0700 Subject: [ghc-steering-committee] Proposal: Or patterns (#43) In-Reply-To: <3F540834-A309-47E5-BE7C-BFC4F0460F3A@cs.brynmawr.edu> References: <90AB84AA-2917-49E6-B4A9-DF5E634A722F@justtesting.org> <3F540834-A309-47E5-BE7C-BFC4F0460F3A@cs.brynmawr.edu> Message-ID: I am also for accepting this, especially if we use one of the alternative notations (I just posted another variation on the github ticket) On Mon, Jun 18, 2018 at 9:12 AM Richard Eisenberg wrote: > Yes, I'm in favor of accepting. > > > On Jun 18, 2018, at 9:02 AM, Simon Peyton Jones via > ghc-steering-committee wrote: > > > > Dear steering committee > > > > The or-pattern proposal has teen "under consideration" by this committee > since 19 August 2017. That is nearly a year! > > > > I think we can decide. I favour acceptance subject to the points in my > comment here > > > https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-395906439 > > > > 1. Typing rules, dealing with existentials, dictionaries etc. > > I make a concrete proposal and would welcome critique. > > > https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-396851582 > > > > 2. Syntax. I really think we should not use "|" because we already use > that > > for guards -- and moreover (as the comment says) there's an obvious > way to > > use guards *in* patterns not just *after* patterns. > > > > If not "|" then what? I'm ok with ";". But I guess "||" could also > be considered. > > > > I think we owe it to the proposer not to drag our feet any more. > > > > Simon > > > > > > | -----Original Message----- > > | From: ghc-steering-committee < > ghc-steering-committee-bounces at haskell.org> On > > | Behalf Of Manuel M T Chakravarty > > | Sent: 01 November 2017 23:58 > > | To: ghc-steering-committee at haskell.org > > | Subject: [ghc-steering-committee] Proposal: Or patterns (#43) > > | > > | Folks, > > | > > | I am sorry for taking a long time to get us going on this proposal. > > | > > | The ”Or pattern” proposal is about an extension to pattern matching: > > | > > | (formatted) > > | > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > > | 2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-or- > > | patterns.rst&data=02%7C01%7Csimonpj%40microsoft.com > %7Cc41b6be72ad545030e3c08 > > | > d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&s > > | data=ivKxIr7%2FprF1GhUBq%2BZRxJjmKqfPq%2BNOXmbw9JPJuQ8%3D&reserved=0 > > | (PR thread) > > | > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > > | 2Fghc-proposals%2Fghc- > > | proposals%2Fpull%2F43&data=02%7C01%7Csimonpj%40microsoft.com > %7Cc41b6be72ad54 > > | > 5030e3c08d521846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63645177480 > > | > 5951860&sdata=x0Xn%2BOS6mHZBWYolcaJfa5JCkbHa1pl552fNI1Swmhw%3D&reserved=0 > > | > > | Its basic idea is simple: allow multiple alternative patterns for each > > | alternative during pattern matching. Unfortunately, the interaction > with > > | guards and some other languages features makes it significantly less > > | straight forward than one might initially think. > > | > > | I propose to accept this proposal provided we can agree to use the > ”first > > | semantics” (aka single-match semantics) — see > > | > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com% > > | 2Fosa1%2Fghc-proposals%2Fblob%2For_patterns%2Fproposals%2F0000-or- > > | patterns.rst%23interaction-with- > > | guards&data=02%7C01%7Csimonpj%40microsoft.com > %7Cc41b6be72ad545030e3c08d52184 > > | > 6116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&sdata=Z > > | 5JJApLfReiCl0dKD2R%2Fvbs3pTZt84iEXDRhdbeVICA%3D&reserved=0 > > | > > | My reason for insisting on the first semantics is that it is a simple > > | extension of the existing pattern semantics in the Report, whereas the > > | second semantics requires a more profound, non-local change. This, in > > | particular, also makes it easier to understand the implications of > the first > > | semantics. (Also, OCaml has made that same choice.) > > | > > | However, even with the first semantics, I still have one concern > about this > > | proposal. The story about the interaction with existential types is > > | currently only partial and there is no discussion of the interaction > with > > | GADTs. It might be reasonable to ask for a complete specification of > the > > | interaction with these features before making a final determination > on this > > | proposal. Nevertheless, this proposal is quite elaborate and quite > some work > > | has gone into it. Hence, I think, we owe it the authors of the > proposal to > > | at least make a preliminary determination at this point. (In > particular, if > > | it is not going to fly regardless of how GADTs are handled, we should > say so > > | now.) > > | > > | Cheers, > > | Manuel > > | > > | PS: It is worth noting that Swift solved the problem of deciding > between the > > | first and second semantics by choosing a syntax that avoids the > ambiguity: > > | < > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper > . > > | apple.com > %2Flibrary%2Fcontent%2Fdocumentation%2FSwift%2FConceptual%2FSwift_P > > | > rogramming_Language%2FStatements.html%23%2F%2Fapple_ref%2Fswift%2Fgrammar%2F > > | switch- > > | statement&data=02%7C01%7Csimonpj%40microsoft.com > %7Cc41b6be72ad545030e3c08d52 > > | > 1846116%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636451774805951860&sdat > > | a=ax1RcoY80ERbid5inoe%2BCRYg%2FC4t0hVL5oGBasVTfhM%3D&reserved=0>. It > is > > | difficult to adapt this syntax to Haskell. If it where possible, I > think, > > | this would be the best solution. > > | _______________________________________________ > > | 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 chak at justtesting.org Tue Jun 19 02:17:07 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 19 Jun 2018 12:17:07 +1000 Subject: [ghc-steering-committee] Proposal: Or patterns #43 (Round 2) In-Reply-To: <6E4DEE9A-872E-4F67-AE9A-FEBD48BDC640@justtesting.org> References: <6E4DEE9A-872E-4F67-AE9A-FEBD48BDC640@justtesting.org> Message-ID: Let’s consolidate the discussion of Proposal #43 in this current thread about the revised proposal. And for reference, here is SimonPJ’s recent message posted in the old thread: SimonPJ’s message got support from Iavor and Richard, and SimonM previously expressed support on this Round 2 thread. In the meantime, the proposal has also been changed to use ’;’ as a separator (instead of the initially proposed ’|’). However, this still leaves us with https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-398086013 where the proposal author writes that he will update the proposal with new typing rules along SimonPJ’s suggestions within a few weeks. Hence, it seems to me that we need to wait with a formal decision until that update of the typing rules has happened. Do you agree, Simon? In any case, is anybody unhappy with any aspect other than ”what would and would not typecheck” (which will hopefully be addressed in those forthcoming typing rules)? If so, please speak now. Cheers, Manuel > 01.06.2018 17:30 Manuel M T Chakravarty : > > We now have a revised version of the ”Or pattern” proposal #43 to consider: > > (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or- patterns.rst > (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 > > You may remember that we discuss this a while back > > https://mail.haskell.org/pipermail/ghc-steering-committee/2017-November/000231.html > > and finally decided to bounce it back to the authors with the following recommendation: > > https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-358189327 > > We previously decided that we are inclined to accept this proposal if the authors change the points that we highlighted. Judging from the conversation of SimonPJ and Richard with the author on the GitHub thread, it appears to me that most of the issues have been addressed. However, Simon’s point > > • "Patterns that bind existentials, dictionaries, or equalities are rejected by the type checker". I disagree. Earlier I suggested "no variable bound by an or-pattern can have a type that mentions an existential variable bound by the or-pattern". That is much more friendly because you can still match against an existential constructor; you just can’t bind an existential variable. > > from > still doesn’t seem to be addressed, or am I misunderstanding? > > Overall, I propose to accept the proposal, possibly requiring that the above point be addressed. > > What do you all think? > > Cheers, > Manuel > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded message was scrubbed... From: Simon Peyton Jones Subject: RE: [ghc-steering-committee] Proposal: Or patterns (#43) Date: Mon, 18 Jun 2018 13:02:04 +0000 Size: 16392 URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From chak at justtesting.org Tue Jun 19 02:20:05 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 19 Jun 2018 12:20:05 +1000 Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) In-Reply-To: References: Message-ID: <4C18BD2C-98B9-4C0A-88D8-510532049AF3@justtesting.org> I do agree with Simon. Manuel > Am 15.06.2018 um 19:26 schrieb Simon Peyton Jones via ghc-steering-committee : > > I'm quite doubtful. I've posted a comment on the ticket to say why. > > Simon > > | -----Original Message----- > | From: ghc-steering-committee On > | Behalf Of Christopher Allen > | Sent: 14 June 2018 00:19 > | To: ghc-steering-committee at haskell.org > | Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) > | > | The proposal I'm reviewing is: > | > | Bundling patterns with type synonyms by Bertram Felgenhauer and Joe > | Hermaszewski > | > | https://github.com/ghc-proposals/ghc-proposals/pull/28 > | > | Having reviewed the proposal and gone through some of the GHC Trac history, > | I think we should accept this proposal. There are a couple of open > | questions, ambiguities, and potential downsides but the overall complexity > | of the proposal doesn't cause me great concern. > | > | > | Cheers, > | Chris Allen > | _______________________________________________ > | 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From simonpj at microsoft.com Tue Jun 19 07:45:30 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 19 Jun 2018 07:45:30 +0000 Subject: [ghc-steering-committee] Proposal: Or patterns #43 (Round 2) In-Reply-To: References: <6E4DEE9A-872E-4F67-AE9A-FEBD48BDC640@justtesting.org> Message-ID: The Haskell report does some things, including typing rules, by giving the desugaring, and saying “the original typechecks if the deguared version does). As it happens that approach is a very nice, simple way to say what or-patterns should typecheck; it deals with all the issues of existentials and locally-captured dictionaries (by ruling them out) at one blow. So I’d be content with a deguaring rule for or-patterns, along the lines I gave, saying that this governs the typing too. That should only take Omer a few minutes to add; indeed we could accept subject to that condition. Simon From: ghc-steering-committee On Behalf Of Manuel M T Chakravarty Sent: 19 June 2018 03:17 To: ghc-steering-committee at haskell.org Subject: Re: [ghc-steering-committee] Proposal: Or patterns #43 (Round 2) Let’s consolidate the discussion of Proposal #43 in this current thread about the revised proposal. And for reference, here is SimonPJ’s recent message posted in the old thread: SimonPJ’s message got support from Iavor and Richard, and SimonM previously expressed support on this Round 2 thread. In the meantime, the proposal has also been changed to use ’;’ as a separator (instead of the initially proposed ’|’). However, this still leaves us with https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-398086013 where the proposal author writes that he will update the proposal with new typing rules along SimonPJ’s suggestions within a few weeks. Hence, it seems to me that we need to wait with a formal decision until that update of the typing rules has happened. Do you agree, Simon? In any case, is anybody unhappy with any aspect other than ”what would and would not typecheck” (which will hopefully be addressed in those forthcoming typing rules)? If so, please speak now. Cheers, Manuel 01.06.2018 17:30 Manuel M T Chakravarty >: We now have a revised version of the ”Or pattern” proposal #43 to consider: (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-patterns.rst (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 You may remember that we discuss this a while back https://mail.haskell.org/pipermail/ghc-steering-committee/2017-November/000231.html and finally decided to bounce it back to the authors with the following recommendation: https://github.com/ghc-proposals/ghc-proposals/pull/43#issuecomment-358189327 We previously decided that we are inclined to accept this proposal if the authors change the points that we highlighted. Judging from the conversation of SimonPJ and Richard with the author on the GitHub thread, it appears to me that most of the issues have been addressed. However, Simon’s point • "Patterns that bind existentials, dictionaries, or equalities are rejected by the type checker". I disagree. Earlier I suggested "no variable bound by an or-pattern can have a type that mentions an existential variable bound by the or-pattern". That is much more friendly because you can still match against an existential constructor; you just can’t bind an existential variable. from > still doesn’t seem to be addressed, or am I misunderstanding? Overall, I propose to accept the proposal, possibly requiring that the above point be addressed. What do you all think? Cheers, Manuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Jun 20 21:14:52 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 20 Jun 2018 17:14:52 -0400 Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k} In-Reply-To: References: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu> <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de> <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu> <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de> <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu> Message-ID: I have posted the new proposal, at https://github.com/ghc-proposals/ghc-proposals/pull/148 I've also updated #99 to clarify where the new syntax is allowed. For Iavor's examples: > data T1 a = C1 a type T1 :: Type -> Type C1 :: forall a. a -> T1 a > data T2 (a :: k) = C2 { f2 :: Proxy a } type T2 :: forall k. k -> Type C2 :: forall k (a :: k). Proxy a -> T2 a f2 :: forall k (a :: k). T2 a -> Proxy a > data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a type T3 :: forall {k}. k -> Type C3 :: forall k (a :: k). Proxy a -> T3 a > data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a type T4 :: forall {k}. k -> Type C4 :: forall {k} (a :: k). Proxy a -> T3 a > data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a Rejected, as k is used dependently but is not lexically dependent. (This is no change.) It we have > data T5 k (a :: k) where C5 :: forall k (a :: k). Proxy a -> T5 k a we would get type T5 :: forall k -> k -> Type C5 :: forall k (a :: k). Proxy a -> T5 k a > data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a Rejected, like T6. If we revise to: > data T6 k (a :: k) where C6 :: forall {k} (a::k). Proxy a -> T6 k a we get type T6 :: forall k -> k -> Type C6 :: forall {k} (a::k). Proxy a -> T6 k a I've updated the proposal itself to include these examples. Does this help to clarify? Richard > On May 25, 2018, at 1:56 PM, Iavor Diatchki wrote: > > Hello, > > well, I thought that Richard was going to write a new proposal based on the feedback here, but it sounds like he is planning to revise #99, and then write a separate new one. I guess we should discuss the proposal again once the changes are in. I would encourage Richard to add some text and examples to clarify exactly what's in the proposal and what's not, and how things are supposed to work. Here are some examples, for which it would be illuminating (to me) to see the types/kinds of all names introduced. > > data T1 a = C1 a > data T2 (a :: k) = C2 { f2 :: Proxy a } > data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a > data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a > data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a > data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a > > -Iavor > > > On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones > wrote: > I’m keen to get #99 into GHC in some form. > > > > My motivation (which could be a fourth bullet in the proposal) is that it should be possible for a programmer to write a fully-explicit type signature for anything GHC can infer. But currently we can’t. For typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it down. > > > > based on the discussion so far, it seems that #99 in its current form might not be exactly what we want > > > > Can you summarise the reasons it might not be exactly what we want? > > > > Simon > > > > From: ghc-steering-committee > On Behalf Of Richard Eisenberg > Sent: 24 May 2018 21:17 > To: Iavor Diatchki > > Cc: ghc-steering-committee at haskell.org ; Joachim Breitner > > Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k} > > > > I do plan on turning Joachim's recent suggestion into a separate proposal, and then to modify #99. But the modification would remove only the bit about classes, not the feature overall. I don't have time to do this now, though -- will do next week. > > > > Richard > > > > > On May 24, 2018, at 1:54 PM, Iavor Diatchki > wrote: > > > > Hello, > > > > based on the discussion so far, it seems that #99 in its current form might not be exactly what we want, so I'd say that we should reject it for the moment. Overall, I agree that it would be nice to come up with a consistent notation for things that are currently happening in GHC but we can't write, so perhaps we could revisit this with a revised proposal at a later time? > > > > -Iavor > > > > > > > > > > On Sat, May 5, 2018 at 8:48 PM Joachim Breitner > wrote: > > Hi, > > Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg: > > Joachim, you are always a fount of interesting ideas. > > > > > On May 2, 2018, at 2:51 PM, Joachim Breitner > > .de> wrote: > > > > > > class C k (a : k) where meth :: a > > > meth :: forall {k} a. C k a -> k -> Constraint > > > > I think this is brilliant. But not only for this proposal! Imagine > > this: > > > > class Num a where > > fromInteger :: Integer -> a > > > > fromInteger :: Integer -> forall a. Num a => a > > > > If we do that, then #129 is essentially solved, at no further cost to > > anyone. (Note that in all Haskell98-style code, no one will ever be > > able to notice the changed type of fromInteger.) > > > > This approach also allows for the possibility of reordering > > quantified type variables for Haskell98-style constructors, if anyone > > should want to do it. > > > > And it allows for updated types (including quantified variable > > ordering, etc.) for record selectors. > > > > And it allows (maybe?) for giving good types to GADT record > > selectors: > > > > data X a where > > Foo :: { bar :: Int } -> X Int > > Quux :: { bar :: Bool } -> X Bool > > bar :: X a -> a > > > > GHC currently rejects the declaration for X, but it could be accepted > > if only we could specify the correct type of bar. And now we can. I > > don't particularly want to cook up the typing rules here, but I don't > > think I'm totally crazy. > > > > GADT record selectors aside, the rule for these could be that the > > top-level type signature must be equivalent w.r.t. the subtype > > relation with the original type signature. That is, if the new > > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy > > enough to check for. The implementation would probably do a little > > worker/wrapper stunt. > > I smell a new proposal… what does this mean for #99? Will you want to > revise it? > > Cheers, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Jun 22 18:00:44 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 22 Jun 2018 14:00:44 -0400 Subject: [ghc-steering-committee] Please Review: Remove TypeOperators => NoStarIsType "migration" (#146), Shepherd: Ben Gamari Message-ID: Dear Committee, this is your secretary speaking: Remove TypeOperators => NoStarIsType "migration" #146 by Oleg Grenrus was proposed. https://github.com/ghc-proposals/ghc-proposals/pull/28 I propose Ben Gamari as the shepherd, in case the decision needs to be coordinated with the 8.6 release. Ben, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From iavor.diatchki at gmail.com Fri Jun 22 18:14:22 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 22 Jun 2018 11:14:22 -0700 Subject: [ghc-steering-committee] Please Review: Remove TypeOperators => NoStarIsType "migration" (#146), Shepherd: Ben Gamari In-Reply-To: References: Message-ID: Here is the correct link to the proposal: https://github.com/ghc-proposals/ghc-proposals/pull/146 On Fri, Jun 22, 2018 at 11:01 AM Joachim Breitner wrote: > Dear Committee, > > this is your secretary speaking: > > Remove TypeOperators => NoStarIsType "migration" #146 by Oleg Grenrus > was proposed. > https://github.com/ghc-proposals/ghc-proposals/pull/28 > > I propose Ben Gamari as the shepherd, in case the decision needs to be > coordinated with the 8.6 release. > > Ben, please reach consensus as described in > https://github.com/ghc-proposals/ghc-proposals#committee-process > I suggest you make a recommendation, in a new e-mail thread with the > proposal number in the subject, about the decision, maybe point out > debatable points, and assume that anyone who stays quiet agrees with > you. > > Thanks, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sat Jun 23 16:13:29 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 23 Jun 2018 12:13:29 -0400 Subject: [ghc-steering-committee] Deprecating Exports (#134); Recommendation: accept In-Reply-To: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de> References: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de> Message-ID: <4486bc5bb722ddc615a0f2199c85dd20dca89910.camel@joachim-breitner.de> Dear Committee, Am Donnerstag, den 24.05.2018, 12:23 +0200 schrieb Joachim Breitner: > alanasp has proposed a Deprecating Exports mechanism: > https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst > > I suggest acceptance! thanks Iavor, Simon and Richard for refining the proposal (and sorry for missing some of the obvious shortcomings). I believe the author addressed the concerns, and now the proposal is better. I even more suggest acceptance. If there is still disagreement, please speak up. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sat Jun 23 16:14:29 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 23 Jun 2018 12:14:29 -0400 Subject: [ghc-steering-committee] Proposal: Binding existential type variables (#96) In-Reply-To: References: <1a6201c0d0ce4019830e3680f1209c21adbe0636.camel@joachim-breitner.de> <2D5A47F5-4095-4A30-B33E-1964DA3C6421@justtesting.org> Message-ID: <4f2fd23f9aa07c089ae3c2192a06422ce9099fbe.camel@joachim-breitner.de> Hi, allright, marked as rejected. Cheers, Joachim Am Sonntag, den 17.06.2018, 22:33 -0400 schrieb Richard Eisenberg: > Yes, I think we should reject in favor of #126. > > > On Jun 16, 2018, at 4:33 AM, Manuel M T Chakravarty wrote: > > > > Sounds good to me. > > > > Manuel > > > > > Am 16.06.2018 um 17:41 schrieb Joachim Breitner : > > > > > > Hi, > > > > > > Am Samstag, den 02.06.2018, 20:08 +0200 schrieb Joachim Breitner: > > > > Am Sonntag, den 25.03.2018, 23:23 +0100 schrieb Roman Leshchinskiy: > > > > > The proposal is to add a way to name existential type variables in pattern matches: https://github.com/ghc-proposals/ghc-proposals/pull/96. > > > > > > > > since this proposal has been proposed, we have two new related (and > > > > partly competing) proposals (#126 and #128), had some good discussion > > > > and there is even talk of writing a paper. In light of that, I think we > > > > should either reject #96 in the current form, or at least bump it back > > > > to the discussion phase until we have settled on a final form. > > > > > > in the meantime we even have a paper that describes #126 and #128: > > > https://arxiv.org/abs/1806.03476 > > > which also describes why #96 may not be the best way forward. > > > > > > I asked at > > > https://github.com/ghc-proposals/ghc-proposals/pull/96#issuecomment-396581800 > > > if anyone still feels attached to that proposal, and nobody responded. > > > Hence, I think we can safely reject this proposal (and focus on the > > > other two). > > > > > > Roman, do you agree? > > > > > > 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 -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sat Jun 23 17:00:40 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 23 Jun 2018 13:00:40 -0400 Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) In-Reply-To: References: Message-ID: Hi, Am Mittwoch, den 13.06.2018, 18:18 -0500 schrieb Christopher Allen: > Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski > > https://github.com/ghc-proposals/ghc-proposals/pull/28 > > > I think we should accept this proposal. There are a couple of > open questions, ambiguities, and potential downsides but the overall > complexity of the proposal doesn't cause me great concern. I agree with Simon that might not take the language in the direction we want to take it. In fact, if we had PatternSynonyms and ExplicitNamespaces back when Haskell was first specified, we might not have the T(K) syntax at all, and just a flat, explicit list of names, possibly requiring explicit namespace qualifier to disambiguate? Things like deprecating exports would have been easier then… So while I follow the motivation of the proposal, and I don’t have concrete other solution to offer, I am inclined to reject it: The problem it is solving does not seem to be too urgent, and my gut feeling says that there might be something better down the road. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sat Jun 23 17:06:50 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 23 Jun 2018 13:06:50 -0400 Subject: [ghc-steering-committee] Extra Commas (#87), Recommend: accept In-Reply-To: References: Message-ID: <47ade98bd4c094567e7f55c99eedf9f1e1841a13.camel@joachim-breitner.de> Hi, Am Donnerstag, den 03.05.2018, 17:14 +0000 schrieb Iavor Diatchki: > I don't like this proposal. I guess it is mostly a matter of taste, > but I think that comas should be used a separator and not a > terminator. I don't really buy either the CPP or "cleaner diffs" > motivation. this means that there is no consensus yet. I would not be sad if this proposal does not make it, and will not argue againt Iavor hier. Chris, as the shepherd, I would ask you to moderate a discussion here to see if we can find consensus. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Sat Jun 23 17:31:37 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sat, 23 Jun 2018 13:31:37 -0400 Subject: [ghc-steering-committee] Status Message-ID: <46a263c3c654270eb3e8ab1a5fd49e9e86744664.camel@joachim-breitner.de> Hi committee, high time for another status mail. Please look through this and see if anything is pending on you, of otherwise needs your attention. Since the last status update, we * were asked to review these proposals: #112 UnliftedArray# (Shepherd: Simon Marlow) #81 ExtraCommas (Shepherd: Chris) #121 Array resizing primitives (Shepherd: Simon Marlow) #129 TypeApplication and literals (Shepherd: Joachim) #125 Type annotated quoters (Shepherd: Manuel) #111 Linear types (Shepherd: Richard) #28 bundling patterns with type synonyms (Shepherd: Chris) #134 Deprecating Exports (Shepherd: Joachim) #146 Remove TypeOperators => NoStarIsType (Shepherd: Ben) * got a recommendation from shepherds about: #81 ExtraCommas (recommendation: accept) #99 forall {k} (recommendation: accept) #129 TypeApplication and literals (recommendation: accept) #112 UnliftedArray# (recommendation: accept) #121 Array resizing primitives (recommendation: accept) #134 Deprecating Exports (recommendation: accept) #43 Or patterns round two (recommendation: accept) #28 bundling patterns with type synonyms (recommendation: accept) * decided about the following proposals - Constraint vs. Type (accept) - Embrace Type in Type (accept) - PatternSignatures (reject) - Mutable constructor fields (needs revision) #112 UnliftedArray# (accept) #129 TypeApplication and literals (reject) #120 Deriving Via (accept) #103 Treat kind and type vars dientical (accept) #121 Array resizing primitives (accept) #96 Binding existential type variables (reject) We currently have to act on the following 13 proposals, which is one less than last round. Remove TypeOperators => NoStarIsType "migration" https://github.com/ghc-proposals/ghc-proposals/pull/146 Shepherd: Ben Status: Waiting for recommendation. Deprecating Exports https://github.com/ghc-proposals/ghc-proposals/pull/134 Shepherd: Joachim Recommendation: accept Status: Discussion ongoing Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Status: Waiting for recommendation. Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Waiting for recommendation. Linear types https://github.com/ghc-proposals/ghc-proposals/pull/111 Shepherd: Richard Status: Waiting for recommendation. Define Kinds Without Promotion https://github.com/ghc-proposals/ghc-proposals/pull/106 Shepherd: Ryan Status: Still waiting for recommendation. forall {k}, https://github.com/ghc-proposals/ghc-proposals/pull/99 Shepherd: Iavor Status: Ongoing discussion ExtraCommas https://github.com/ghc-proposals/ghc-proposals/pull/87 Shepherd: Chris Recommendation: accept Status: Ongoing discussion, met with some reservation. Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Discussion needs to happen Top-level kinds signatures https://github.com/ghc-proposals/ghc-proposals/pull/54 Shepherd: Roman Leshchinskiy Status: Waiting for recommendation. Or-Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Recommendation: accept Status: Round 2 being discussed Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Ryan Status: This is still lingering since last July! Bundling patterns with synonyms https://github.com/ghc-proposals/ghc-proposals/pull/28 Shepherd: Chris Recommendation: accept Status: Ongoing discussion, met with some resistance. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From rae at cs.brynmawr.edu Sun Jun 24 03:19:25 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sat, 23 Jun 2018 23:19:25 -0400 Subject: [ghc-steering-committee] Bundling patterns with type synonyms (#28) In-Reply-To: References: Message-ID: <61FD037C-4A8F-45F2-A0E1-9010380F8029@cs.brynmawr.edu> Agreed. Beyond my posted technical reservations, I believe that a better solution is out there. Richard > On Jun 23, 2018, at 1:00 PM, Joachim Breitner wrote: > > Hi, > > Am Mittwoch, den 13.06.2018, 18:18 -0500 schrieb Christopher Allen: >> Bundling patterns with type synonyms by Bertram Felgenhauer and Joe Hermaszewski >> >> https://github.com/ghc-proposals/ghc-proposals/pull/28 >> >> >> I think we should accept this proposal. There are a couple of >> open questions, ambiguities, and potential downsides but the overall >> complexity of the proposal doesn't cause me great concern. > > I agree with Simon that might not take the language in the direction we > want to take it. > > In fact, if we had PatternSynonyms and ExplicitNamespaces back when > Haskell was first specified, we might not have the T(K) syntax at all, > and just a flat, explicit list of names, possibly requiring explicit > namespace qualifier to disambiguate? Things like deprecating exports > would have been easier then… > > So while I follow the motivation of the proposal, and I don’t have > concrete other solution to offer, I am inclined to reject it: The > problem it is solving does not seem to be too urgent, and my gut > feeling says that there might be something better down the road. > > 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 rae at cs.brynmawr.edu Sun Jun 24 03:46:24 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sat, 23 Jun 2018 23:46:24 -0400 Subject: [ghc-steering-committee] Deprecating Exports (#134); Recommendation: accept In-Reply-To: <4486bc5bb722ddc615a0f2199c85dd20dca89910.camel@joachim-breitner.de> References: <4190e462230660bd0e95c781a5473bbd4dd47cbd.camel@joachim-breitner.de> <4486bc5bb722ddc615a0f2199c85dd20dca89910.camel@joachim-breitner.de> Message-ID: I have some reservations, though I like the overall idea. I've posted on GitHub. Richard > On Jun 23, 2018, at 12:13 PM, Joachim Breitner wrote: > > Dear Committee, > > Am Donnerstag, den 24.05.2018, 12:23 +0200 schrieb Joachim Breitner: >> alanasp has proposed a Deprecating Exports mechanism: >> https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating_exports_proposal.rst >> >> I suggest acceptance! > > thanks Iavor, Simon and Richard for refining the proposal (and sorry > for missing some of the obvious shortcomings). I believe the author > addressed the concerns, and now the proposal is better. > > I even more suggest acceptance. If there is still disagreement, please > speak up. > > 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 ben at well-typed.com Mon Jun 25 14:19:15 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 25 Jun 2018 10:19:15 -0400 Subject: [ghc-steering-committee] Remove TypeOperators => NoStarIsType "migration" (#146); Recommendation: accept Message-ID: <87wounvti9.fsf@smart-cactus.org> Hi everyone, We are being asked to consider pull request #146. This proposal is an amendment to the accepted Proposal 0020 [1], removing a migration mechanism which was found in practice to hurt more than help. Specifically, proposal 0020 currently specifies a migration period during which the -XNoStarIsType extension (which proposal 0020 introduces) will be implied by -XTypeOperators. The motivation for this was to ease the transition for packages which use * as a binary type operator. In practice it turned out that a significant number of packages are broken by this migration mechanism. Specifically, many packages use * in kind signatures while also enabling TypeOperators. The proposed amendment removes TypeOperator's implication of NoStarIsType. To be clear, this is ultimately a trade-off between optimising for users of (*) as a binary operator and users of * ~ Type. It just so happens that there are far more of the latter. Consequently, my recommendation is to accept the modified proposal. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/83 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mail at joachim-breitner.de Mon Jun 25 15:08:53 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 25 Jun 2018 11:08:53 -0400 Subject: [ghc-steering-committee] Remove TypeOperators => NoStarIsType "migration" (#146); Recommendation: accept In-Reply-To: <87wounvti9.fsf@smart-cactus.org> References: <87wounvti9.fsf@smart-cactus.org> Message-ID: <52f4d75e82693320790d0562495d5838d65e2e95.camel@joachim-breitner.de> Hi, Am Montag, den 25.06.2018, 10:19 -0400 schrieb Ben Gamari: > Consequently, > my recommendation is to accept the modified proposal. sounds good to me. Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at well-typed.com Mon Jun 25 16:07:58 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 25 Jun 2018 12:07:58 -0400 Subject: [ghc-steering-committee] Remove TypeOperators => NoStarIsType "migration" (#146); Recommendation: accept In-Reply-To: <87wounvti9.fsf@smart-cactus.org> References: <87wounvti9.fsf@smart-cactus.org> Message-ID: <87r2kux31v.fsf@smart-cactus.org> Ben Gamari writes: > Hi everyone, > ... > > The proposed amendment removes TypeOperator's implication of > NoStarIsType. To be clear, this is ultimately a trade-off between > optimising for users of (*) as a binary operator and users of * ~ Type. > It just so happens that there are far more of the latter. Consequently, > my recommendation is to accept the modified proposal. > Given that this is (hopefully) a relatively uncontroversial change, my plan is to move ahead with issuing alpha 1 with the new NoStarIsType semantics on Wednesday. If anyone on the committee feels strongly about the issue and would prefer that I not do this do let me know soon and we can discuss. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From chak at justtesting.org Tue Jun 26 03:40:54 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Tue, 26 Jun 2018 13:40:54 +1000 Subject: [ghc-steering-committee] Remove TypeOperators => NoStarIsType "migration" (#146); Recommendation: accept In-Reply-To: <87r2kux31v.fsf@smart-cactus.org> References: <87wounvti9.fsf@smart-cactus.org> <87r2kux31v.fsf@smart-cactus.org> Message-ID: <350C2CF5-326E-4889-A2E0-37DB94F4C627@justtesting.org> +1 > Am 26.06.2018 um 02:07 schrieb Ben Gamari : > > Signierter PGP-Teil > Ben Gamari writes: > >> Hi everyone, >> > ... >> >> The proposed amendment removes TypeOperator's implication of >> NoStarIsType. To be clear, this is ultimately a trade-off between >> optimising for users of (*) as a binary operator and users of * ~ Type. >> It just so happens that there are far more of the latter. Consequently, >> my recommendation is to accept the modified proposal. >> > Given that this is (hopefully) a relatively uncontroversial change, > my plan is to move ahead with issuing alpha 1 with the new NoStarIsType > semantics on Wednesday. If anyone on the committee feels strongly about > the issue and would prefer that I not do this do let me know soon and we > can discuss. > > Cheers, > > - Ben > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From simonpj at microsoft.com Tue Jun 26 08:50:47 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 26 Jun 2018 08:50:47 +0000 Subject: [ghc-steering-committee] Remove TypeOperators => NoStarIsType "migration" (#146); Recommendation: accept In-Reply-To: <350C2CF5-326E-4889-A2E0-37DB94F4C627@justtesting.org> References: <87wounvti9.fsf@smart-cactus.org> <87r2kux31v.fsf@smart-cactus.org> <350C2CF5-326E-4889-A2E0-37DB94F4C627@justtesting.org> Message-ID: I'm in favour. Simon | -----Original Message----- | From: ghc-steering-committee On | Behalf Of Manuel M T Chakravarty | Sent: 26 June 2018 04:41 | To: Ben Gamari | Cc: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Remove TypeOperators => NoStarIsType | "migration" (#146); Recommendation: accept | | +1 | | > Am 26.06.2018 um 02:07 schrieb Ben Gamari : | > | > Signierter PGP-Teil | > Ben Gamari writes: | > | >> Hi everyone, | >> | > ... | >> | >> The proposed amendment removes TypeOperator's implication of | >> NoStarIsType. To be clear, this is ultimately a trade-off between | >> optimising for users of (*) as a binary operator and users of * ~ Type. | >> It just so happens that there are far more of the latter. | >> Consequently, my recommendation is to accept the modified proposal. | >> | > Given that this is (hopefully) a relatively uncontroversial change, my | > plan is to move ahead with issuing alpha 1 with the new NoStarIsType | > semantics on Wednesday. If anyone on the committee feels strongly | > about the issue and would prefer that I not do this do let me know | > soon and we can discuss. | > | > Cheers, | > | > - Ben | > | > From iavor.diatchki at gmail.com Tue Jun 26 22:52:04 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Tue, 26 Jun 2018 15:52:04 -0700 Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k} In-Reply-To: References: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu> <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de> <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu> <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de> <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu> Message-ID: Hello, thanks for the revisions---I read through the new version, and I think I almost understand the plan. I would say that for this proposal it makes more sense to just deal with explicit specificities at the value level, and never have the curly braces in type constructors. Since we don't have an explicit kind application at the type level (e.g., we can't write `Proxy @Type`), I don't think it really makes sense to add the braces to type constructors. If we ever implemented THAT feature, then we can discuss which declarations should have explicit and which should have implicit parameters. In the current set of examples, I find it odd that `T2` does not have braces, but `T3` does. -Iavor On Wed, Jun 20, 2018 at 2:15 PM Richard Eisenberg wrote: > I have posted the new proposal, at > https://github.com/ghc-proposals/ghc-proposals/pull/148 > > I've also updated #99 to clarify where the new syntax is allowed. > > For Iavor's examples: > > data T1 a = C1 a > > > type T1 :: Type -> Type > C1 :: forall a. a -> T1 a > > data T2 (a :: k) = C2 { f2 :: Proxy a } > > > type T2 :: forall k. k -> Type > C2 :: forall k (a :: k). Proxy a -> T2 a > f2 :: forall k (a :: k). T2 a -> Proxy a > > data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a > > > type T3 :: forall {k}. k -> Type > C3 :: forall k (a :: k). Proxy a -> T3 a > > data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a > > > type T4 :: forall {k}. k -> Type > C4 :: forall {k} (a :: k). Proxy a -> T3 a > > data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a > > > Rejected, as k is used dependently but is not lexically dependent. (This > is no change.) It we have > > > data T5 k (a :: k) where C5 :: forall k (a :: k). Proxy a -> T5 k a > > we would get > > type T5 :: forall k -> k -> Type > C5 :: forall k (a :: k). Proxy a -> T5 k a > > data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a > > > Rejected, like T6. If we revise to: > > > data T6 k (a :: k) where C6 :: forall {k} (a::k). Proxy a -> T6 k a > > we get > > type T6 :: forall k -> k -> Type > C6 :: forall {k} (a::k). Proxy a -> T6 k a > > I've updated the proposal itself to include these examples. > > Does this help to clarify? > > Richard > > On May 25, 2018, at 1:56 PM, Iavor Diatchki > wrote: > > Hello, > > well, I thought that Richard was going to write a new proposal based on > the feedback here, but it sounds like he is planning to revise #99, and > then write a separate new one. I guess we should discuss the proposal > again once the changes are in. I would encourage Richard to add some text > and examples to clarify exactly what's in the proposal and what's not, and > how things are supposed to work. Here are some examples, for which it > would be illuminating (to me) to see the types/kinds of all names > introduced. > > data T1 a = C1 a > data T2 (a :: k) = C2 { f2 :: Proxy a } > data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a > data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a > data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a > data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a > > -Iavor > > > On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones > wrote: > >> I’m keen to get #99 into GHC in some form. >> >> >> >> My motivation (which could be a fourth bullet in the proposal) is that it >> should be possible for a programmer to write a fully-explicit type >> signature for anything GHC can infer. But currently we can’t. For >> typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it >> down. >> >> >> >> based on the discussion so far, it seems that #99 in its current form >> might not be exactly what we want >> >> >> >> Can you summarise the reasons it might not be exactly what we want? >> >> >> >> Simon >> >> >> >> *From:* ghc-steering-committee < >> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard >> Eisenberg >> *Sent:* 24 May 2018 21:17 >> *To:* Iavor Diatchki >> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner < >> mail at joachim-breitner.de> >> *Subject:* Re: [ghc-steering-committee] Discussion on proposal #99: >> forall {k} >> >> >> >> I do plan on turning Joachim's recent suggestion into a separate >> proposal, and then to modify #99. But the modification would remove only >> the bit about classes, not the feature overall. I don't have time to do >> this now, though -- will do next week. >> >> >> >> Richard >> >> >> >> On May 24, 2018, at 1:54 PM, Iavor Diatchki >> wrote: >> >> >> >> Hello, >> >> >> >> based on the discussion so far, it seems that #99 in its current form >> might not be exactly what we want, so I'd say that we should reject it for >> the moment. Overall, I agree that it would be nice to come up with a >> consistent notation for things that are currently happening in GHC but we >> can't write, so perhaps we could revisit this with a revised proposal at a >> later time? >> >> >> >> -Iavor >> >> >> >> >> >> >> >> >> >> On Sat, May 5, 2018 at 8:48 PM Joachim Breitner >> wrote: >> >> Hi, >> >> Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg: >> > Joachim, you are always a fount of interesting ideas. >> > >> > > On May 2, 2018, at 2:51 PM, Joachim Breitner > > > .de> wrote: >> > > >> > > class C k (a : k) where meth :: a >> > > meth :: forall {k} a. C k a -> k -> Constraint >> > >> > I think this is brilliant. But not only for this proposal! Imagine >> > this: >> > >> > class Num a where >> > fromInteger :: Integer -> a >> > >> > fromInteger :: Integer -> forall a. Num a => a >> > >> > If we do that, then #129 is essentially solved, at no further cost to >> > anyone. (Note that in all Haskell98-style code, no one will ever be >> > able to notice the changed type of fromInteger.) >> > >> > This approach also allows for the possibility of reordering >> > quantified type variables for Haskell98-style constructors, if anyone >> > should want to do it. >> > >> > And it allows for updated types (including quantified variable >> > ordering, etc.) for record selectors. >> > >> > And it allows (maybe?) for giving good types to GADT record >> > selectors: >> > >> > data X a where >> > Foo :: { bar :: Int } -> X Int >> > Quux :: { bar :: Bool } -> X Bool >> > bar :: X a -> a >> > >> > GHC currently rejects the declaration for X, but it could be accepted >> > if only we could specify the correct type of bar. And now we can. I >> > don't particularly want to cook up the typing rules here, but I don't >> > think I'm totally crazy. >> > >> > GADT record selectors aside, the rule for these could be that the >> > top-level type signature must be equivalent w.r.t. the subtype >> > relation with the original type signature. That is, if the new >> > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy >> > enough to check for. The implementation would probably do a little >> > worker/wrapper stunt. >> >> I smell a new proposal… what does this mean for #99? Will you want to >> revise it? >> >> Cheers, >> Joachim >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >> _______________________________________________ >> 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 cs.brynmawr.edu Thu Jun 28 04:44:54 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 28 Jun 2018 00:44:54 -0400 Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k} In-Reply-To: References: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu> <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de> <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu> <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de> <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu> Message-ID: <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu> But we morally *do* have explicit kind application. See accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0015-type-level-type-applications.rst So the only reason that we don't have it is that GHC hasn't caught up to its specification. (I have a student working on this now.) The reason that T2 and T3 are different here is that T2 mentions the k in the type declaration, while T3 mentions it only in the constructor declaration. Richard > On Jun 26, 2018, at 6:52 PM, Iavor Diatchki wrote: > > Hello, > thanks for the revisions---I read through the new version, and I think I almost understand the plan. I would say that for this proposal it makes more sense to just deal with explicit specificities at the value level, and never have the curly braces in type constructors. Since we don't have an explicit kind application at the type level (e.g., we can't write `Proxy @Type`), I don't think it really makes sense to add the braces to type constructors. If we ever implemented THAT feature, then we can discuss which declarations should have explicit and which should have implicit parameters. In the current set of examples, I find it odd that `T2` does not have braces, but `T3` does. > > -Iavor > > > > > > > On Wed, Jun 20, 2018 at 2:15 PM Richard Eisenberg > wrote: > I have posted the new proposal, at https://github.com/ghc-proposals/ghc-proposals/pull/148 > > I've also updated #99 to clarify where the new syntax is allowed. > > For Iavor's examples: > >> data T1 a = C1 a > > type T1 :: Type -> Type > C1 :: forall a. a -> T1 a > >> data T2 (a :: k) = C2 { f2 :: Proxy a } > > type T2 :: forall k. k -> Type > C2 :: forall k (a :: k). Proxy a -> T2 a > f2 :: forall k (a :: k). T2 a -> Proxy a > >> data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a > > type T3 :: forall {k}. k -> Type > C3 :: forall k (a :: k). Proxy a -> T3 a > >> data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a > > type T4 :: forall {k}. k -> Type > C4 :: forall {k} (a :: k). Proxy a -> T3 a > >> data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a > > Rejected, as k is used dependently but is not lexically dependent. (This is no change.) It we have > > > data T5 k (a :: k) where C5 :: forall k (a :: k). Proxy a -> T5 k a > > we would get > > type T5 :: forall k -> k -> Type > C5 :: forall k (a :: k). Proxy a -> T5 k a > >> data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a > > > Rejected, like T6. If we revise to: > > > data T6 k (a :: k) where C6 :: forall {k} (a::k). Proxy a -> T6 k a > > we get > > type T6 :: forall k -> k -> Type > C6 :: forall {k} (a::k). Proxy a -> T6 k a > > I've updated the proposal itself to include these examples. > > Does this help to clarify? > > Richard > >> On May 25, 2018, at 1:56 PM, Iavor Diatchki > wrote: >> >> Hello, >> >> well, I thought that Richard was going to write a new proposal based on the feedback here, but it sounds like he is planning to revise #99, and then write a separate new one. I guess we should discuss the proposal again once the changes are in. I would encourage Richard to add some text and examples to clarify exactly what's in the proposal and what's not, and how things are supposed to work. Here are some examples, for which it would be illuminating (to me) to see the types/kinds of all names introduced. >> >> data T1 a = C1 a >> data T2 (a :: k) = C2 { f2 :: Proxy a } >> data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a >> data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a >> data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a >> data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a >> >> -Iavor >> >> >> On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones > wrote: >> I’m keen to get #99 into GHC in some form. >> >> >> >> My motivation (which could be a fourth bullet in the proposal) is that it should be possible for a programmer to write a fully-explicit type signature for anything GHC can infer. But currently we can’t. For typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it down. >> >> >> >> based on the discussion so far, it seems that #99 in its current form might not be exactly what we want >> >> >> >> Can you summarise the reasons it might not be exactly what we want? >> >> >> >> Simon >> >> >> >> From: ghc-steering-committee > On Behalf Of Richard Eisenberg >> Sent: 24 May 2018 21:17 >> To: Iavor Diatchki > >> Cc: ghc-steering-committee at haskell.org ; Joachim Breitner > >> Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k} >> >> >> >> I do plan on turning Joachim's recent suggestion into a separate proposal, and then to modify #99. But the modification would remove only the bit about classes, not the feature overall. I don't have time to do this now, though -- will do next week. >> >> >> >> Richard >> >> >> >> >> On May 24, 2018, at 1:54 PM, Iavor Diatchki > wrote: >> >> >> >> Hello, >> >> >> >> based on the discussion so far, it seems that #99 in its current form might not be exactly what we want, so I'd say that we should reject it for the moment. Overall, I agree that it would be nice to come up with a consistent notation for things that are currently happening in GHC but we can't write, so perhaps we could revisit this with a revised proposal at a later time? >> >> >> >> -Iavor >> >> >> >> >> >> >> >> >> >> On Sat, May 5, 2018 at 8:48 PM Joachim Breitner > wrote: >> >> Hi, >> >> Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg: >> > Joachim, you are always a fount of interesting ideas. >> > >> > > On May 2, 2018, at 2:51 PM, Joachim Breitner > > > .de> wrote: >> > > >> > > class C k (a : k) where meth :: a >> > > meth :: forall {k} a. C k a -> k -> Constraint >> > >> > I think this is brilliant. But not only for this proposal! Imagine >> > this: >> > >> > class Num a where >> > fromInteger :: Integer -> a >> > >> > fromInteger :: Integer -> forall a. Num a => a >> > >> > If we do that, then #129 is essentially solved, at no further cost to >> > anyone. (Note that in all Haskell98-style code, no one will ever be >> > able to notice the changed type of fromInteger.) >> > >> > This approach also allows for the possibility of reordering >> > quantified type variables for Haskell98-style constructors, if anyone >> > should want to do it. >> > >> > And it allows for updated types (including quantified variable >> > ordering, etc.) for record selectors. >> > >> > And it allows (maybe?) for giving good types to GADT record >> > selectors: >> > >> > data X a where >> > Foo :: { bar :: Int } -> X Int >> > Quux :: { bar :: Bool } -> X Bool >> > bar :: X a -> a >> > >> > GHC currently rejects the declaration for X, but it could be accepted >> > if only we could specify the correct type of bar. And now we can. I >> > don't particularly want to cook up the typing rules here, but I don't >> > think I'm totally crazy. >> > >> > GADT record selectors aside, the rule for these could be that the >> > top-level type signature must be equivalent w.r.t. the subtype >> > relation with the original type signature. That is, if the new >> > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy >> > enough to check for. The implementation would probably do a little >> > worker/wrapper stunt. >> >> I smell a new proposal… what does this mean for #99? Will you want to >> revise it? >> >> Cheers, >> Joachim >> -- >> Joachim Breitner >> mail at joachim-breitner.de >> http://www.joachim-breitner.de/ >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> _______________________________________________ >> 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 cs.brynmawr.edu Thu Jun 28 05:04:12 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Thu, 28 Jun 2018 01:04:12 -0400 Subject: [ghc-steering-committee] Remove TypeOperators => NoStarIsType "migration" (#146); Recommendation: accept In-Reply-To: References: <87wounvti9.fsf@smart-cactus.org> <87r2kux31v.fsf@smart-cactus.org> <350C2CF5-326E-4889-A2E0-37DB94F4C627@justtesting.org> Message-ID: <72119264-4DAA-4986-B4CF-2E785C1B81D8@cs.brynmawr.edu> It's nice when experience guides us. +1 > On Jun 26, 2018, at 4:50 AM, Simon Peyton Jones via ghc-steering-committee wrote: > > I'm in favour. > > Simon > > | -----Original Message----- > | From: ghc-steering-committee On > | Behalf Of Manuel M T Chakravarty > | Sent: 26 June 2018 04:41 > | To: Ben Gamari > | Cc: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] Remove TypeOperators => NoStarIsType > | "migration" (#146); Recommendation: accept > | > | +1 > | > | > Am 26.06.2018 um 02:07 schrieb Ben Gamari : > | > > | > Signierter PGP-Teil > | > Ben Gamari writes: > | > > | >> Hi everyone, > | >> > | > ... > | >> > | >> The proposed amendment removes TypeOperator's implication of > | >> NoStarIsType. To be clear, this is ultimately a trade-off between > | >> optimising for users of (*) as a binary operator and users of * ~ Type. > | >> It just so happens that there are far more of the latter. > | >> Consequently, my recommendation is to accept the modified proposal. > | >> > | > Given that this is (hopefully) a relatively uncontroversial change, my > | > plan is to move ahead with issuing alpha 1 with the new NoStarIsType > | > semantics on Wednesday. If anyone on the committee feels strongly > | > about the issue and would prefer that I not do this do let me know > | > soon and we can discuss. > | > > | > Cheers, > | > > | > - Ben > | > > | > > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From iavor.diatchki at gmail.com Thu Jun 28 05:27:13 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 27 Jun 2018 22:27:13 -0700 Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k} In-Reply-To: <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu> References: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu> <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de> <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu> <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de> <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu> <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu> Message-ID: Ok, in that case it makes sense. Perhaps we should update the proposal to specify the rules that would allow me to compute the difference between `T2` and `T3`. Presumably there are similar rules for type families, data families, and classes? Once we've clarified this, I think we can accept this, unless there are any objections. On Wed, Jun 27, 2018 at 9:44 PM Richard Eisenberg wrote: > But we morally *do* have explicit kind application. See accepted proposal > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0015-type-level-type-applications.rst > So the only reason that we don't have it is that GHC hasn't caught up to > its specification. (I have a student working on this now.) > > The reason that T2 and T3 are different here is that T2 mentions the k in > the type declaration, while T3 mentions it only in the constructor > declaration. > > Richard > > > On Jun 26, 2018, at 6:52 PM, Iavor Diatchki > wrote: > > Hello, > thanks for the revisions---I read through the new version, and I think I > almost understand the plan. I would say that for this proposal it makes > more sense to just deal with explicit specificities at the value level, and > never have the curly braces in type constructors. Since we don't have an > explicit kind application at the type level (e.g., we can't write `Proxy > @Type`), I don't think it really makes sense to add the braces to type > constructors. If we ever implemented THAT feature, then we can discuss > which declarations should have explicit and which should have implicit > parameters. In the current set of examples, I find it odd that `T2` does > not have braces, but `T3` does. > > -Iavor > > > > > > > On Wed, Jun 20, 2018 at 2:15 PM Richard Eisenberg > wrote: > >> I have posted the new proposal, at >> https://github.com/ghc-proposals/ghc-proposals/pull/148 >> >> I've also updated #99 to clarify where the new syntax is allowed. >> >> For Iavor's examples: >> >> data T1 a = C1 a >> >> >> type T1 :: Type -> Type >> C1 :: forall a. a -> T1 a >> >> data T2 (a :: k) = C2 { f2 :: Proxy a } >> >> >> type T2 :: forall k. k -> Type >> C2 :: forall k (a :: k). Proxy a -> T2 a >> f2 :: forall k (a :: k). T2 a -> Proxy a >> >> data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a >> >> >> type T3 :: forall {k}. k -> Type >> C3 :: forall k (a :: k). Proxy a -> T3 a >> >> data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a >> >> >> type T4 :: forall {k}. k -> Type >> C4 :: forall {k} (a :: k). Proxy a -> T3 a >> >> data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a >> >> >> Rejected, as k is used dependently but is not lexically dependent. (This >> is no change.) It we have >> >> > data T5 k (a :: k) where C5 :: forall k (a :: k). Proxy a -> T5 k a >> >> we would get >> >> type T5 :: forall k -> k -> Type >> C5 :: forall k (a :: k). Proxy a -> T5 k a >> >> data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a >> >> >> Rejected, like T6. If we revise to: >> >> > data T6 k (a :: k) where C6 :: forall {k} (a::k). Proxy a -> T6 k a >> >> we get >> >> type T6 :: forall k -> k -> Type >> C6 :: forall {k} (a::k). Proxy a -> T6 k a >> >> I've updated the proposal itself to include these examples. >> >> Does this help to clarify? >> >> Richard >> >> On May 25, 2018, at 1:56 PM, Iavor Diatchki >> wrote: >> >> Hello, >> >> well, I thought that Richard was going to write a new proposal based on >> the feedback here, but it sounds like he is planning to revise #99, and >> then write a separate new one. I guess we should discuss the proposal >> again once the changes are in. I would encourage Richard to add some text >> and examples to clarify exactly what's in the proposal and what's not, and >> how things are supposed to work. Here are some examples, for which it >> would be illuminating (to me) to see the types/kinds of all names >> introduced. >> >> data T1 a = C1 a >> data T2 (a :: k) = C2 { f2 :: Proxy a } >> data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a >> data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a >> data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a >> data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a >> >> -Iavor >> >> >> On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones >> wrote: >> >>> I’m keen to get #99 into GHC in some form. >>> >>> >>> >>> My motivation (which could be a fourth bullet in the proposal) is that >>> it should be possible for a programmer to write a fully-explicit type >>> signature for anything GHC can infer. But currently we can’t. For >>> typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it >>> down. >>> >>> >>> >>> based on the discussion so far, it seems that #99 in its current form >>> might not be exactly what we want >>> >>> >>> >>> Can you summarise the reasons it might not be exactly what we want? >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* ghc-steering-committee < >>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Richard >>> Eisenberg >>> *Sent:* 24 May 2018 21:17 >>> *To:* Iavor Diatchki >>> *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner < >>> mail at joachim-breitner.de> >>> *Subject:* Re: [ghc-steering-committee] Discussion on proposal #99: >>> forall {k} >>> >>> >>> >>> I do plan on turning Joachim's recent suggestion into a separate >>> proposal, and then to modify #99. But the modification would remove only >>> the bit about classes, not the feature overall. I don't have time to do >>> this now, though -- will do next week. >>> >>> >>> >>> Richard >>> >>> >>> >>> On May 24, 2018, at 1:54 PM, Iavor Diatchki >>> wrote: >>> >>> >>> >>> Hello, >>> >>> >>> >>> based on the discussion so far, it seems that #99 in its current form >>> might not be exactly what we want, so I'd say that we should reject it for >>> the moment. Overall, I agree that it would be nice to come up with a >>> consistent notation for things that are currently happening in GHC but we >>> can't write, so perhaps we could revisit this with a revised proposal at a >>> later time? >>> >>> >>> >>> -Iavor >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, May 5, 2018 at 8:48 PM Joachim Breitner < >>> mail at joachim-breitner.de> wrote: >>> >>> Hi, >>> >>> Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg: >>> > Joachim, you are always a fount of interesting ideas. >>> > >>> > > On May 2, 2018, at 2:51 PM, Joachim Breitner >> > > .de> wrote: >>> > > >>> > > class C k (a : k) where meth :: a >>> > > meth :: forall {k} a. C k a -> k -> Constraint >>> > >>> > I think this is brilliant. But not only for this proposal! Imagine >>> > this: >>> > >>> > class Num a where >>> > fromInteger :: Integer -> a >>> > >>> > fromInteger :: Integer -> forall a. Num a => a >>> > >>> > If we do that, then #129 is essentially solved, at no further cost to >>> > anyone. (Note that in all Haskell98-style code, no one will ever be >>> > able to notice the changed type of fromInteger.) >>> > >>> > This approach also allows for the possibility of reordering >>> > quantified type variables for Haskell98-style constructors, if anyone >>> > should want to do it. >>> > >>> > And it allows for updated types (including quantified variable >>> > ordering, etc.) for record selectors. >>> > >>> > And it allows (maybe?) for giving good types to GADT record >>> > selectors: >>> > >>> > data X a where >>> > Foo :: { bar :: Int } -> X Int >>> > Quux :: { bar :: Bool } -> X Bool >>> > bar :: X a -> a >>> > >>> > GHC currently rejects the declaration for X, but it could be accepted >>> > if only we could specify the correct type of bar. And now we can. I >>> > don't particularly want to cook up the typing rules here, but I don't >>> > think I'm totally crazy. >>> > >>> > GADT record selectors aside, the rule for these could be that the >>> > top-level type signature must be equivalent w.r.t. the subtype >>> > relation with the original type signature. That is, if the new >>> > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy >>> > enough to check for. The implementation would probably do a little >>> > worker/wrapper stunt. >>> >>> I smell a new proposal… what does this mean for #99? Will you want to >>> revise it? >>> >>> Cheers, >>> Joachim >>> -- >>> Joachim Breitner >>> mail at joachim-breitner.de >>> http://www.joachim-breitner.de/ >>> >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee at haskell.org >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>> _______________________________________________ >>> 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 chak at justtesting.org Fri Jun 29 03:16:30 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Fri, 29 Jun 2018 13:16:30 +1000 Subject: [ghc-steering-committee] Or patterns #43 (Round 2.5) Message-ID: <286EAD48-F614-4DB1-8C4F-55F7B2B7B609@justtesting.org> As a reaction to SimonPJ’s suggestion in the ”Round 2” thread https://mail.haskell.org/pipermail/ghc-steering-committee/2018-June/000601.html we have now got a revised revised-proposal for or-patterns at (formatted) https://github.com/osa1/ghc-proposals/blob/or_patterns/proposals/0000-or-patterns.rst (PR thread) https://github.com/ghc-proposals/ghc-proposals/pull/43 Except for Simon’s reservations, I previously proposed to accept the proposal. Simon wrote that we ought to accept it after the requested change, which has now happened. Hence, I will mark the proposal as accepted *unless* I hear a dissenting opinion by the end of next week. Cheers, Manuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 874 bytes Desc: Message signed with OpenPGP URL: From iavor.diatchki at gmail.com Fri Jun 29 18:25:52 2018 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Fri, 29 Jun 2018 11:25:52 -0700 Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k} In-Reply-To: References: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu> <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de> <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu> <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de> <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu> <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu> Message-ID: I am supportive of accepting the proposal, but I think that we should address the point raised by Joachim on the the git-hub thread first ( https://github.com/ghc-proposals/ghc-proposals/pull/99#issuecomment-401060976). It really is not quite clear if the specificity is a property of the type itself, or the thing that has that type. On Thu, Jun 28, 2018 at 1:07 AM Simon Peyton Jones wrote: > I’m keen on this proposal. I am very keen to be able to express in a type > or kind signature everything needful to use the value (or type > constructor). The proposal gives an example at the term level. It’d be > strengthened by an example at the type level. Eg > > type T1 :: forall {k}. (k->Type) -> k -> Type > > data T1 f a = MkT (f a) > > > > type T2 :: forall k. (k->Type) -> k -> Type > > data T2 f (a::k) = MkT2 (f a) > > > > Here T1 has an inferred kind variable, mentioned nowhere in the > declaration. The kind signature (which I have written as if it were code, > which is the subject of a separate proposal) is inferred as shown. > > > > T2 mentions k, so its kind signature looks a bit different. > > > > What’s the difference? It’s exactly in explicit kind application. You can > write (T1 @Type Maybe Int), but T2 can’t have that explicit kind argument. > > > > The whole business of Required/Specified/Inferred is more complicated than > I like, but if we have it (which we do right now) we should allow the > programmer to specify exactly what they mean. > > > > (An alternative is to abolish the Specified/Inferred distinction, but that > carries significant costs of its own and no one is proposing it.) > > > > Let’s accept! > > > > Simon > > > > *From:* Richard Eisenberg > *Sent:* 28 June 2018 05:45 > *To:* Iavor Diatchki > *Cc:* Simon Peyton Jones ; > ghc-steering-committee at haskell.org; Joachim Breitner < > mail at joachim-breitner.de> > > > *Subject:* Re: [ghc-steering-committee] Discussion on proposal #99: > forall {k} > > > > But we morally *do* have explicit kind application. See accepted proposal > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0015-type-level-type-applications.rst > > So the only reason that we don't have it is that GHC hasn't caught up to > its specification. (I have a student working on this now.) > > > > The reason that T2 and T3 are different here is that T2 mentions the k in > the type declaration, while T3 mentions it only in the constructor > declaration. > > > > Richard > > > > On Jun 26, 2018, at 6:52 PM, Iavor Diatchki > wrote: > > > > Hello, > > thanks for the revisions---I read through the new version, and I think I > almost understand the plan. I would say that for this proposal it makes > more sense to just deal with explicit specificities at the value level, and > never have the curly braces in type constructors. Since we don't have an > explicit kind application at the type level (e.g., we can't write `Proxy > @Type`), I don't think it really makes sense to add the braces to type > constructors. If we ever implemented THAT feature, then we can discuss > which declarations should have explicit and which should have implicit > parameters. In the current set of examples, I find it odd that `T2` does > not have braces, but `T3` does. > > > > -Iavor > > > > > > > > > > > > > > On Wed, Jun 20, 2018 at 2:15 PM Richard Eisenberg > wrote: > > I have posted the new proposal, at > https://github.com/ghc-proposals/ghc-proposals/pull/148 > > > > > I've also updated #99 to clarify where the new syntax is allowed. > > > > For Iavor's examples: > > > > data T1 a = C1 a > > > > type T1 :: Type -> Type > > C1 :: forall a. a -> T1 a > > > > data T2 (a :: k) = C2 { f2 :: Proxy a } > > > > type T2 :: forall k. k -> Type > > C2 :: forall k (a :: k). Proxy a -> T2 a > > f2 :: forall k (a :: k). T2 a -> Proxy a > > > > data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a > > > > type T3 :: forall {k}. k -> Type > > C3 :: forall k (a :: k). Proxy a -> T3 a > > > > data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a > > > > type T4 :: forall {k}. k -> Type > > C4 :: forall {k} (a :: k). Proxy a -> T3 a > > > > data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a > > > > Rejected, as k is used dependently but is not lexically dependent. (This > is no change.) It we have > > > > > data T5 k (a :: k) where C5 :: forall k (a :: k). Proxy a -> T5 k a > > > > we would get > > > > type T5 :: forall k -> k -> Type > > C5 :: forall k (a :: k). Proxy a -> T5 k a > > > > data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a > > > > Rejected, like T6. If we revise to: > > > > > data T6 k (a :: k) where C6 :: forall {k} (a::k). Proxy a -> T6 k a > > > > we get > > > > type T6 :: forall k -> k -> Type > > C6 :: forall {k} (a::k). Proxy a -> T6 k a > > > > I've updated the proposal itself to include these examples. > > > > Does this help to clarify? > > > > Richard > > > > On May 25, 2018, at 1:56 PM, Iavor Diatchki > wrote: > > > > Hello, > > > > well, I thought that Richard was going to write a new proposal based on > the feedback here, but it sounds like he is planning to revise #99, and > then write a separate new one. I guess we should discuss the proposal > again once the changes are in. I would encourage Richard to add some text > and examples to clarify exactly what's in the proposal and what's not, and > how things are supposed to work. Here are some examples, for which it > would be illuminating (to me) to see the types/kinds of all names > introduced. > > > > data T1 a = C1 a > > data T2 (a :: k) = C2 { f2 :: Proxy a } > > data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a > > data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a > > data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a > > data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a > > > > -Iavor > > > > > > On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones > wrote: > > I’m keen to get #99 into GHC in some form. > > > > My motivation (which could be a fourth bullet in the proposal) is that it > should be possible for a programmer to write a fully-explicit type > signature for anything GHC can infer. But currently we can’t. For > typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it > down. > > > > based on the discussion so far, it seems that #99 in its current form > might not be exactly what we want > > > > Can you summarise the reasons it might not be exactly what we want? > > > > Simon > > > > *From:* ghc-steering-committee > *On Behalf Of *Richard Eisenberg > *Sent:* 24 May 2018 21:17 > *To:* Iavor Diatchki > *Cc:* ghc-steering-committee at haskell.org; Joachim Breitner < > mail at joachim-breitner.de> > *Subject:* Re: [ghc-steering-committee] Discussion on proposal #99: > forall {k} > > > > I do plan on turning Joachim's recent suggestion into a separate proposal, > and then to modify #99. But the modification would remove only the bit > about classes, not the feature overall. I don't have time to do this now, > though -- will do next week. > > > > Richard > > > > On May 24, 2018, at 1:54 PM, Iavor Diatchki > wrote: > > > > Hello, > > > > based on the discussion so far, it seems that #99 in its current form > might not be exactly what we want, so I'd say that we should reject it for > the moment. Overall, I agree that it would be nice to come up with a > consistent notation for things that are currently happening in GHC but we > can't write, so perhaps we could revisit this with a revised proposal at a > later time? > > > > -Iavor > > > > > > > > > > On Sat, May 5, 2018 at 8:48 PM Joachim Breitner > wrote: > > Hi, > > Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg: > > Joachim, you are always a fount of interesting ideas. > > > > > On May 2, 2018, at 2:51 PM, Joachim Breitner > > .de> wrote: > > > > > > class C k (a : k) where meth :: a > > > meth :: forall {k} a. C k a -> k -> Constraint > > > > I think this is brilliant. But not only for this proposal! Imagine > > this: > > > > class Num a where > > fromInteger :: Integer -> a > > > > fromInteger :: Integer -> forall a. Num a => a > > > > If we do that, then #129 is essentially solved, at no further cost to > > anyone. (Note that in all Haskell98-style code, no one will ever be > > able to notice the changed type of fromInteger.) > > > > This approach also allows for the possibility of reordering > > quantified type variables for Haskell98-style constructors, if anyone > > should want to do it. > > > > And it allows for updated types (including quantified variable > > ordering, etc.) for record selectors. > > > > And it allows (maybe?) for giving good types to GADT record > > selectors: > > > > data X a where > > Foo :: { bar :: Int } -> X Int > > Quux :: { bar :: Bool } -> X Bool > > bar :: X a -> a > > > > GHC currently rejects the declaration for X, but it could be accepted > > if only we could specify the correct type of bar. And now we can. I > > don't particularly want to cook up the typing rules here, but I don't > > think I'm totally crazy. > > > > GADT record selectors aside, the rule for these could be that the > > top-level type signature must be equivalent w.r.t. the subtype > > relation with the original type signature. That is, if the new > > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy > > enough to check for. The implementation would probably do a little > > worker/wrapper stunt. > > I smell a new proposal… what does this mean for #99? Will you want to > revise it? > > Cheers, > Joachim > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > _______________________________________________ > 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 Thu Jun 28 07:59:48 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 28 Jun 2018 07:59:48 +0000 Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k} In-Reply-To: <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu> References: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu> <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de> <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu> <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de> <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu> <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu> Message-ID: Joachim, One thing I occasionally find tricky is this: what proposals exist, in what state? One way to find out is to start here https://github.com/ghc-proposals/ghc-proposals and use the links for “accepted”, “dormant” etc. But * You have to look at several different lists, one by one. * There isn’t a ‘rejected’ list Worse, the numbering seems to change. IN Richard’s link below, it looks as if 0015-type-level-type-applcations is #15. But it isn’t. It actually appears in the list of accepted proposals as #80. That’s very confusing. I really thought the number was unique. It’s be great to have a single comprehensive list, with a unique ID, that says for each proposal what its status is. Is that possible? Clearly I (still) don’t really understand the pull-request model well enough, which is a bit embarrassing given how universal it has become. (Side question: does anyone have a favourite tutorial?) Simon From: Richard Eisenberg Sent: 28 June 2018 05:45 To: Iavor Diatchki Cc: Simon Peyton Jones ; ghc-steering-committee at haskell.org; Joachim Breitner Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k} But we morally *do* have explicit kind application. See accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0015-type-level-type-applications.rst So the only reason that we don't have it is that GHC hasn't caught up to its specification. (I have a student working on this now.) The reason that T2 and T3 are different here is that T2 mentions the k in the type declaration, while T3 mentions it only in the constructor declaration. Richard On Jun 26, 2018, at 6:52 PM, Iavor Diatchki > wrote: Hello, thanks for the revisions---I read through the new version, and I think I almost understand the plan. I would say that for this proposal it makes more sense to just deal with explicit specificities at the value level, and never have the curly braces in type constructors. Since we don't have an explicit kind application at the type level (e.g., we can't write `Proxy @Type`), I don't think it really makes sense to add the braces to type constructors. If we ever implemented THAT feature, then we can discuss which declarations should have explicit and which should have implicit parameters. In the current set of examples, I find it odd that `T2` does not have braces, but `T3` does. -Iavor On Wed, Jun 20, 2018 at 2:15 PM Richard Eisenberg > wrote: I have posted the new proposal, at https://github.com/ghc-proposals/ghc-proposals/pull/148 I've also updated #99 to clarify where the new syntax is allowed. For Iavor's examples: data T1 a = C1 a type T1 :: Type -> Type C1 :: forall a. a -> T1 a data T2 (a :: k) = C2 { f2 :: Proxy a } type T2 :: forall k. k -> Type C2 :: forall k (a :: k). Proxy a -> T2 a f2 :: forall k (a :: k). T2 a -> Proxy a data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a type T3 :: forall {k}. k -> Type C3 :: forall k (a :: k). Proxy a -> T3 a data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a type T4 :: forall {k}. k -> Type C4 :: forall {k} (a :: k). Proxy a -> T3 a data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a Rejected, as k is used dependently but is not lexically dependent. (This is no change.) It we have > data T5 k (a :: k) where C5 :: forall k (a :: k). Proxy a -> T5 k a we would get type T5 :: forall k -> k -> Type C5 :: forall k (a :: k). Proxy a -> T5 k a data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a Rejected, like T6. If we revise to: > data T6 k (a :: k) where C6 :: forall {k} (a::k). Proxy a -> T6 k a we get type T6 :: forall k -> k -> Type C6 :: forall {k} (a::k). Proxy a -> T6 k a I've updated the proposal itself to include these examples. Does this help to clarify? Richard On May 25, 2018, at 1:56 PM, Iavor Diatchki > wrote: Hello, well, I thought that Richard was going to write a new proposal based on the feedback here, but it sounds like he is planning to revise #99, and then write a separate new one. I guess we should discuss the proposal again once the changes are in. I would encourage Richard to add some text and examples to clarify exactly what's in the proposal and what's not, and how things are supposed to work. Here are some examples, for which it would be illuminating (to me) to see the types/kinds of all names introduced. data T1 a = C1 a data T2 (a :: k) = C2 { f2 :: Proxy a } data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a -Iavor On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones > wrote: I’m keen to get #99 into GHC in some form. My motivation (which could be a fourth bullet in the proposal) is that it should be possible for a programmer to write a fully-explicit type signature for anything GHC can infer. But currently we can’t. For typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it down. based on the discussion so far, it seems that #99 in its current form might not be exactly what we want Can you summarise the reasons it might not be exactly what we want? Simon From: ghc-steering-committee > On Behalf Of Richard Eisenberg Sent: 24 May 2018 21:17 To: Iavor Diatchki > Cc: ghc-steering-committee at haskell.org; Joachim Breitner > Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k} I do plan on turning Joachim's recent suggestion into a separate proposal, and then to modify #99. But the modification would remove only the bit about classes, not the feature overall. I don't have time to do this now, though -- will do next week. Richard On May 24, 2018, at 1:54 PM, Iavor Diatchki > wrote: Hello, based on the discussion so far, it seems that #99 in its current form might not be exactly what we want, so I'd say that we should reject it for the moment. Overall, I agree that it would be nice to come up with a consistent notation for things that are currently happening in GHC but we can't write, so perhaps we could revisit this with a revised proposal at a later time? -Iavor On Sat, May 5, 2018 at 8:48 PM Joachim Breitner > wrote: Hi, Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg: > Joachim, you are always a fount of interesting ideas. > > > On May 2, 2018, at 2:51 PM, Joachim Breitner > .de> wrote: > > > > class C k (a : k) where meth :: a > > meth :: forall {k} a. C k a -> k -> Constraint > > I think this is brilliant. But not only for this proposal! Imagine > this: > > class Num a where > fromInteger :: Integer -> a > > fromInteger :: Integer -> forall a. Num a => a > > If we do that, then #129 is essentially solved, at no further cost to > anyone. (Note that in all Haskell98-style code, no one will ever be > able to notice the changed type of fromInteger.) > > This approach also allows for the possibility of reordering > quantified type variables for Haskell98-style constructors, if anyone > should want to do it. > > And it allows for updated types (including quantified variable > ordering, etc.) for record selectors. > > And it allows (maybe?) for giving good types to GADT record > selectors: > > data X a where > Foo :: { bar :: Int } -> X Int > Quux :: { bar :: Bool } -> X Bool > bar :: X a -> a > > GHC currently rejects the declaration for X, but it could be accepted > if only we could specify the correct type of bar. And now we can. I > don't particularly want to cook up the typing rules here, but I don't > think I'm totally crazy. > > GADT record selectors aside, the rule for these could be that the > top-level type signature must be equivalent w.r.t. the subtype > relation with the original type signature. That is, if the new > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy > enough to check for. The implementation would probably do a little > worker/wrapper stunt. I smell a new proposal… what does this mean for #99? Will you want to revise it? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ 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 Thu Jun 28 08:07:23 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 28 Jun 2018 08:07:23 +0000 Subject: [ghc-steering-committee] Discussion on proposal #99: forall {k} In-Reply-To: <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu> References: <7EB6937A-086F-415C-81DC-C44BCA716DFB@cs.brynmawr.edu> <41f153f3940391752bdddc40b07c54fdc23d6ee9.camel@joachim-breitner.de> <0BCE745C-7B82-4F25-9F86-3858398EA3C3@cs.brynmawr.edu> <12800fff0ea2e9fd819402bbaac2e31d7fbddf1d.camel@joachim-breitner.de> <092EA358-6508-4942-A8AF-61E52A1342DB@cs.brynmawr.edu> <4E234B26-19EE-484F-8CA7-9719D44001E5@cs.brynmawr.edu> Message-ID: I’m keen on this proposal. I am very keen to be able to express in a type or kind signature everything needful to use the value (or type constructor). The proposal gives an example at the term level. It’d be strengthened by an example at the type level. Eg type T1 :: forall {k}. (k->Type) -> k -> Type data T1 f a = MkT (f a) type T2 :: forall k. (k->Type) -> k -> Type data T2 f (a::k) = MkT2 (f a) Here T1 has an inferred kind variable, mentioned nowhere in the declaration. The kind signature (which I have written as if it were code, which is the subject of a separate proposal) is inferred as shown. T2 mentions k, so its kind signature looks a bit different. What’s the difference? It’s exactly in explicit kind application. You can write (T1 @Type Maybe Int), but T2 can’t have that explicit kind argument. The whole business of Required/Specified/Inferred is more complicated than I like, but if we have it (which we do right now) we should allow the programmer to specify exactly what they mean. (An alternative is to abolish the Specified/Inferred distinction, but that carries significant costs of its own and no one is proposing it.) Let’s accept! Simon From: Richard Eisenberg Sent: 28 June 2018 05:45 To: Iavor Diatchki Cc: Simon Peyton Jones ; ghc-steering-committee at haskell.org; Joachim Breitner Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k} But we morally *do* have explicit kind application. See accepted proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0015-type-level-type-applications.rst So the only reason that we don't have it is that GHC hasn't caught up to its specification. (I have a student working on this now.) The reason that T2 and T3 are different here is that T2 mentions the k in the type declaration, while T3 mentions it only in the constructor declaration. Richard On Jun 26, 2018, at 6:52 PM, Iavor Diatchki > wrote: Hello, thanks for the revisions---I read through the new version, and I think I almost understand the plan. I would say that for this proposal it makes more sense to just deal with explicit specificities at the value level, and never have the curly braces in type constructors. Since we don't have an explicit kind application at the type level (e.g., we can't write `Proxy @Type`), I don't think it really makes sense to add the braces to type constructors. If we ever implemented THAT feature, then we can discuss which declarations should have explicit and which should have implicit parameters. In the current set of examples, I find it odd that `T2` does not have braces, but `T3` does. -Iavor On Wed, Jun 20, 2018 at 2:15 PM Richard Eisenberg > wrote: I have posted the new proposal, at https://github.com/ghc-proposals/ghc-proposals/pull/148 I've also updated #99 to clarify where the new syntax is allowed. For Iavor's examples: data T1 a = C1 a type T1 :: Type -> Type C1 :: forall a. a -> T1 a data T2 (a :: k) = C2 { f2 :: Proxy a } type T2 :: forall k. k -> Type C2 :: forall k (a :: k). Proxy a -> T2 a f2 :: forall k (a :: k). T2 a -> Proxy a data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a type T3 :: forall {k}. k -> Type C3 :: forall k (a :: k). Proxy a -> T3 a data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a type T4 :: forall {k}. k -> Type C4 :: forall {k} (a :: k). Proxy a -> T3 a data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a Rejected, as k is used dependently but is not lexically dependent. (This is no change.) It we have > data T5 k (a :: k) where C5 :: forall k (a :: k). Proxy a -> T5 k a we would get type T5 :: forall k -> k -> Type C5 :: forall k (a :: k). Proxy a -> T5 k a data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a Rejected, like T6. If we revise to: > data T6 k (a :: k) where C6 :: forall {k} (a::k). Proxy a -> T6 k a we get type T6 :: forall k -> k -> Type C6 :: forall {k} (a::k). Proxy a -> T6 k a I've updated the proposal itself to include these examples. Does this help to clarify? Richard On May 25, 2018, at 1:56 PM, Iavor Diatchki > wrote: Hello, well, I thought that Richard was going to write a new proposal based on the feedback here, but it sounds like he is planning to revise #99, and then write a separate new one. I guess we should discuss the proposal again once the changes are in. I would encourage Richard to add some text and examples to clarify exactly what's in the proposal and what's not, and how things are supposed to work. Here are some examples, for which it would be illuminating (to me) to see the types/kinds of all names introduced. data T1 a = C1 a data T2 (a :: k) = C2 { f2 :: Proxy a } data T3 a where C3 :: forall k (a::k). Proxy a -> T3 a data T4 a where C4 :: forall {k} (a::k). Proxy a -> T3 a data T5 k a where C5 :: forall k (a::k). Proxy a -> T5 k a data T6 k a where C6 :: forall {k} (a::k). Proxy a -> T6 k a -Iavor On Fri, May 25, 2018 at 2:02 AM Simon Peyton Jones > wrote: I’m keen to get #99 into GHC in some form. My motivation (which could be a fourth bullet in the proposal) is that it should be possible for a programmer to write a fully-explicit type signature for anything GHC can infer. But currently we can’t. For typeRep1 GHC infers the signature shown for typeRep3; but we can’t write it down. based on the discussion so far, it seems that #99 in its current form might not be exactly what we want Can you summarise the reasons it might not be exactly what we want? Simon From: ghc-steering-committee > On Behalf Of Richard Eisenberg Sent: 24 May 2018 21:17 To: Iavor Diatchki > Cc: ghc-steering-committee at haskell.org; Joachim Breitner > Subject: Re: [ghc-steering-committee] Discussion on proposal #99: forall {k} I do plan on turning Joachim's recent suggestion into a separate proposal, and then to modify #99. But the modification would remove only the bit about classes, not the feature overall. I don't have time to do this now, though -- will do next week. Richard On May 24, 2018, at 1:54 PM, Iavor Diatchki > wrote: Hello, based on the discussion so far, it seems that #99 in its current form might not be exactly what we want, so I'd say that we should reject it for the moment. Overall, I agree that it would be nice to come up with a consistent notation for things that are currently happening in GHC but we can't write, so perhaps we could revisit this with a revised proposal at a later time? -Iavor On Sat, May 5, 2018 at 8:48 PM Joachim Breitner > wrote: Hi, Am Mittwoch, den 02.05.2018, 16:10 -0400 schrieb Richard Eisenberg: > Joachim, you are always a fount of interesting ideas. > > > On May 2, 2018, at 2:51 PM, Joachim Breitner > .de> wrote: > > > > class C k (a : k) where meth :: a > > meth :: forall {k} a. C k a -> k -> Constraint > > I think this is brilliant. But not only for this proposal! Imagine > this: > > class Num a where > fromInteger :: Integer -> a > > fromInteger :: Integer -> forall a. Num a => a > > If we do that, then #129 is essentially solved, at no further cost to > anyone. (Note that in all Haskell98-style code, no one will ever be > able to notice the changed type of fromInteger.) > > This approach also allows for the possibility of reordering > quantified type variables for Haskell98-style constructors, if anyone > should want to do it. > > And it allows for updated types (including quantified variable > ordering, etc.) for record selectors. > > And it allows (maybe?) for giving good types to GADT record > selectors: > > data X a where > Foo :: { bar :: Int } -> X Int > Quux :: { bar :: Bool } -> X Bool > bar :: X a -> a > > GHC currently rejects the declaration for X, but it could be accepted > if only we could specify the correct type of bar. And now we can. I > don't particularly want to cook up the typing rules here, but I don't > think I'm totally crazy. > > GADT record selectors aside, the rule for these could be that the > top-level type signature must be equivalent w.r.t. the subtype > relation with the original type signature. That is, if the new > signature is t1 and the old was t2, then t1 <: t2 and t2 <: t1. Easy > enough to check for. The implementation would probably do a little > worker/wrapper stunt. I smell a new proposal… what does this mean for #99? Will you want to revise it? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ 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: