From iavor.diatchki at gmail.com Sun Apr 2 23:26:25 2017 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sun, 2 Apr 2017 16:26:25 -0700 Subject: [ghc-steering-committee] Proposal: Accept proposal 37, Hex Float literals In-Reply-To: <1490627921.1781.2.camel@joachim-breitner.de> References: <1490052404.10470.4.camel@joachim-breitner.de> <1490627921.1781.2.camel@joachim-breitner.de> Message-ID: OK, I've marked it as accepted. On Mon, Mar 27, 2017 at 8:18 AM, Joachim Breitner wrote: > Hi, > > > Am Montag, den 20.03.2017, 19:26 -0400 schrieb Joachim Breitner: > > Am Montag, den 27.02.2017, 13:34 -0800 schrieb Iavor Diatchki: > > > I was assigned to be the shepherd for the Hex Float proposal > > > (https://github.com/ghc-proposals/ghc-proposals/pull/37), so I > > > would > > > like to propose that we accept it for implementation in GHC. > > > > there seems to be consensus on this. If nobody shouts out real soon > > now, I will official mark this as approved tomorrow or so. > > I think it would set better procedural precedent if the shepherd does > that. Iavor, can you mark the proposal as accepted (with a small > rationale) and close the PR? > > Thanks, > Joachim > > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Apr 3 02:53:30 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 02 Apr 2017 22:53:30 -0400 Subject: [ghc-steering-committee] Status Message-ID: <1491188010.14741.7.camel@joachim-breitner.de> [Please do not reply to this mail discussing individual proposals. Instead, reply to the appropriate thread, or start a new one.] Hi, we have now officially accepted Hex Floats https://github.com/ghc-proposals/ghc-proposals/pull/37 and rejected INCOMPLETE_CONTEXTS https://github.com/ghc-proposals/ghc-proposals/pull/34 Currently under discussion are: Constructor Synonyms and Pattern Synonym Signatures https://github.com/ghc-proposals/ghc-proposals/pull/41 https://github.com/ghc-proposals/ghc-proposals/pull/42 Shepherd: Chris Allen Proposal: Accept both Status: expecially the first one does not seem to attract consensus. Eval class https://github.com/ghc-proposals/ghc-proposals/pull/27 Shepherd: Richard Status: This came back after being sent to the author for revision. I guess at this point Richard should make a new decision suggestion. Also TODO (for Ben) Add @rleshchinskiy to the GitHub organization and remove @atzedijkstra https://github.com/orgs/ghc-proposals/people (or make me an owner there). Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- 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 simonpj at microsoft.com Mon Apr 3 08:49:22 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 3 Apr 2017 08:49:22 +0000 Subject: [ghc-steering-committee] Status In-Reply-To: <1491188010.14741.7.camel@joachim-breitner.de> References: <1491188010.14741.7.camel@joachim-breitner.de> Message-ID: | Constructor Synonyms and Pattern Synonym Signatures | https://github.com/ghc-proposals/ghc-proposals/pull/41 | https://github.com/ghc-proposals/ghc-proposals/pull/42 | Shepherd: Chris Allen | Proposal: Accept both | Status: expecially the first one does not seem to attract consensus. I don’t' think we should accept both: they clearly overlap. Even the author sees them as either/or. To me #42 seems fine, and desirably anyway; I prefer it to #41. Simon From cma at bitemyapp.com Sun Apr 9 20:16:41 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Sun, 9 Apr 2017 15:16:41 -0500 Subject: [ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures Message-ID: Thank you to those of you that replied. I'd like to preserve the syntactic distinction that construction synonyms eliminates. Your statements have shifted me to a reject on https://github.com/ghc-proposals/ghc-proposals/pull/41 If no one has objections, I'd like to move to a reject as I think enough time has elapsed that it's unlikely to get any defenders. Speak up if you feel something was missed. Regarding https://github.com/ghc-proposals/ghc-proposals/pull/42 Summarizing peoples' replies so far: Joachim: In favor, as long as :i does the right thing. Seems under-specified, suggested the following possible relationships between signature of the pattern and the constructor: * May not differ in anything but the constraints. * Must have the same return type. * Must have the same outer type constructor in their return type. * No relation. Roman: In favor of this proposal under the "May not differ in anything but the constraints" policy and against it under any of the other three. Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman that that type of the constructor should be the same as that of the pattern. Simon Marlow: I believe the statement was in favor of #42 contra #41, but I didn't get a sense of how strongly or how Simon felt about the particulars. I agree with and want to highlight Roman's point regarding, >A looser relationship between the constructor function and the pattern makes code significantly harder to read and the proposal doesn't include any justification for such a looser relationship so I would go with the strongest requirement possible. It seems to me like the respondents so far are in favor of #42, but want the strongest variant. I'd like to move to accept #42 with the "May not differ in anything but the constraints" variant. Any objections? Thank you Joachim for the status update last week. Thanks you for your time everyone, Chris Allen From chak at justtesting.org Mon Apr 10 00:39:58 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Mon, 10 Apr 2017 10:39:58 +1000 Subject: [ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures In-Reply-To: References: Message-ID: I support both of the decisions that you propose. Manuel > Christopher Allen : > > Thank you to those of you that replied. I'd like to preserve the > syntactic distinction that construction synonyms eliminates. Your > statements have shifted me to a reject on > https://github.com/ghc-proposals/ghc-proposals/pull/41 > > If no one has objections, I'd like to move to a reject as I think > enough time has elapsed that it's unlikely to get any defenders. Speak > up if you feel something was missed. > > > Regarding https://github.com/ghc-proposals/ghc-proposals/pull/42 > > Summarizing peoples' replies so far: > > Joachim: In favor, as long as :i does the right thing. Seems > under-specified, suggested the following possible relationships > between signature of the pattern and the constructor: > > * May not differ in anything but the constraints. > * Must have the same return type. > * Must have the same outer type constructor in their return type. > * No relation. > > Roman: In favor of this proposal under the "May not differ in anything > but the constraints" policy and against it under any of the other > three. > > Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman that > that type of the constructor should be the same as that of the > pattern. > > Simon Marlow: I believe the statement was in favor of #42 contra #41, > but I didn't get a sense of how strongly or how Simon felt about the > particulars. > > > I agree with and want to highlight Roman's point regarding, > >> A looser relationship between the constructor function and the pattern makes code significantly harder to read and the proposal doesn't include any justification for such a looser relationship so I would go with the strongest requirement possible. > > > It seems to me like the respondents so far are in favor of #42, but > want the strongest variant. I'd like to move to accept #42 with the > "May not differ in anything but the constraints" variant. Any > objections? > > > Thank you Joachim for the status update last week. > > Thanks you for your time everyone, > 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 rae at cs.brynmawr.edu Mon Apr 10 11:54:51 2017 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Mon, 10 Apr 2017 07:54:51 -0400 Subject: [ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures In-Reply-To: References: Message-ID: <843BEC3A-B76F-427C-B8E3-985D66F22C11@cs.brynmawr.edu> As do I (support both decisions that Chris proposes). Thanks! Richard > On Apr 9, 2017, at 8:39 PM, Manuel M T Chakravarty wrote: > > I support both of the decisions that you propose. > > Manuel > >> Christopher Allen : >> >> Thank you to those of you that replied. I'd like to preserve the >> syntactic distinction that construction synonyms eliminates. Your >> statements have shifted me to a reject on >> https://github.com/ghc-proposals/ghc-proposals/pull/41 >> >> If no one has objections, I'd like to move to a reject as I think >> enough time has elapsed that it's unlikely to get any defenders. Speak >> up if you feel something was missed. >> >> >> Regarding https://github.com/ghc-proposals/ghc-proposals/pull/42 >> >> Summarizing peoples' replies so far: >> >> Joachim: In favor, as long as :i does the right thing. Seems >> under-specified, suggested the following possible relationships >> between signature of the pattern and the constructor: >> >> * May not differ in anything but the constraints. >> * Must have the same return type. >> * Must have the same outer type constructor in their return type. >> * No relation. >> >> Roman: In favor of this proposal under the "May not differ in anything >> but the constraints" policy and against it under any of the other >> three. >> >> Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman that >> that type of the constructor should be the same as that of the >> pattern. >> >> Simon Marlow: I believe the statement was in favor of #42 contra #41, >> but I didn't get a sense of how strongly or how Simon felt about the >> particulars. >> >> >> I agree with and want to highlight Roman's point regarding, >> >>> A looser relationship between the constructor function and the pattern makes code significantly harder to read and the proposal doesn't include any justification for such a looser relationship so I would go with the strongest requirement possible. >> >> >> It seems to me like the respondents so far are in favor of #42, but >> want the strongest variant. I'd like to move to accept #42 with the >> "May not differ in anything but the constraints" variant. Any >> objections? >> >> >> Thank you Joachim for the status update last week. >> >> Thanks you for your time everyone, >> 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 From mail at joachim-breitner.de Mon Apr 10 14:12:15 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 10 Apr 2017 10:12:15 -0400 Subject: [ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures In-Reply-To: References: Message-ID: <1491833535.5089.3.camel@joachim-breitner.de> Hi, Am Sonntag, den 09.04.2017, 15:16 -0500 schrieb Christopher Allen: > If no one has objections, I'd like to move to a reject ✓ > > It seems to me like the respondents so far are in favor of #42, but > want the strongest variant. I'd like to move to accept #42 with the > "May not differ in anything but the constraints" variant. Any > objections? Also good. I suggest that you phrase your final summary (which you ideally post on the proposal discussion page) not too damning of the other variants. Something along the lines “the committee conservatively choose this most restricted variant to follow the principle of least surprise, and for lack of use-cases for a more loose approach. Should someone find a use-case for a more loose approach, a new proposal may of course be drafted”. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- 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 simonpj at microsoft.com Mon Apr 10 15:22:35 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 10 Apr 2017 15:22:35 +0000 Subject: [ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures In-Reply-To: References: Message-ID: | It seems to me like the respondents so far are in favor of #42, but | want the strongest variant. I'd like to move to accept #42 with the | "May not differ in anything but the constraints" variant. Any | objections? Yes, I agree; but I'd like the author to feel free to say why he wants a looser variant, if he does. Incidentally, we use the same rule of "differ only in context" in default method signatures http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#default-method-signatures Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Christopher Allen | Sent: 09 April 2017 21:17 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Wrapping up Constructor Synonyms and | Pattern Synonym Signatures | | Thank you to those of you that replied. I'd like to preserve the | syntactic distinction that construction synonyms eliminates. Your | statements have shifted me to a reject on | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F41&data=02%7C01%7Csimonpj%40microsoft.com%7C34ad4d0 | 7eee744a4ed1508d47f8559fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 | C636273658090436080&sdata=tPaXwm5D5BMML3EZBsX5zN1MLwM4Va%2FBXeMm0vlyH% | 2Bk%3D&reserved=0 | | If no one has objections, I'd like to move to a reject as I think | enough time has elapsed that it's unlikely to get any defenders. Speak | up if you feel something was missed. | | | Regarding | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F42&data=02%7C01%7Csimonpj%40microsoft.com%7C34ad4d0 | 7eee744a4ed1508d47f8559fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7 | C636273658090436080&sdata=I3HbbipKfDTiWs6xGUSa1mKyU43L8zffneaEdcZKYS4% | 3D&reserved=0 | | Summarizing peoples' replies so far: | | Joachim: In favor, as long as :i does the right thing. Seems under- | specified, suggested the following possible relationships between | signature of the pattern and the constructor: | | * May not differ in anything but the constraints. | * Must have the same return type. | * Must have the same outer type constructor in their return type. | * No relation. | | Roman: In favor of this proposal under the "May not differ in anything | but the constraints" policy and against it under any of the other | three. | | Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman that | that type of the constructor should be the same as that of the | pattern. | | Simon Marlow: I believe the statement was in favor of #42 contra #41, | but I didn't get a sense of how strongly or how Simon felt about the | particulars. | | | I agree with and want to highlight Roman's point regarding, | | >A looser relationship between the constructor function and the | pattern makes code significantly harder to read and the proposal | doesn't include any justification for such a looser relationship so I | would go with the strongest requirement possible. | | | It seems to me like the respondents so far are in favor of #42, but | want the strongest variant. I'd like to move to accept #42 with the | "May not differ in anything but the constraints" variant. Any | objections? | | | Thank you Joachim for the status update last week. | | Thanks you for your time everyone, | 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 Thu Apr 13 03:05:53 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 12 Apr 2017 23:05:53 -0400 Subject: [ghc-steering-committee] Please review: instance force, Shepherd: Manuel Message-ID: <1492052753.23652.2.camel@joachim-breitner.de> Hi, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/23 was brought before the committee. This was drafted by me, so I will hold myself back in the further discussion. I propose Manuel as the Shepherd. Yavor was more active on the PR, but he already got one assigned recently. Also, Manuel indicated that he was skeptical, so this way I cannot be accused of picking favorably. Manuel, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. FYI, the oher proposals under discussion at the moment are: Constructor Synonyms and Pattern Synonym Signatures https://github.com/ghc-proposals/ghc-proposals/pull/41 https://github.com/ghc-proposals/ghc-proposals/pull/42 Shepherd: Chris Allen Proposal: Accept 41, reject 42. Status: Consensus is reached. Chris should summarize the verdict and assign the labels appropriately. Eval class https://github.com/ghc-proposals/ghc-proposals/pull/27 Shepherd: Richard Status: This came back after being sent to the author for revision. I guess at this point Richard should make a new decision suggestion. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee at haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From marlowsd at gmail.com Thu Apr 13 08:06:41 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 13 Apr 2017 09:06:41 +0100 Subject: [ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures In-Reply-To: References: Message-ID: Agree, I'm in favour of the conservative version of #42 and against #41. But #42 also has a proposal for inference of the constructor type in the absence of a type signature, and gives several options there. I presume we want to be conservative and say that we're not making any changes to the behaviour in the absence of a type signature, right? Cheers Simon On 9 April 2017 at 21:16, Christopher Allen wrote: > Thank you to those of you that replied. I'd like to preserve the > syntactic distinction that construction synonyms eliminates. Your > statements have shifted me to a reject on > https://github.com/ghc-proposals/ghc-proposals/pull/41 > > If no one has objections, I'd like to move to a reject as I think > enough time has elapsed that it's unlikely to get any defenders. Speak > up if you feel something was missed. > > > Regarding https://github.com/ghc-proposals/ghc-proposals/pull/42 > > Summarizing peoples' replies so far: > > Joachim: In favor, as long as :i does the right thing. Seems > under-specified, suggested the following possible relationships > between signature of the pattern and the constructor: > > * May not differ in anything but the constraints. > * Must have the same return type. > * Must have the same outer type constructor in their return type. > * No relation. > > Roman: In favor of this proposal under the "May not differ in anything > but the constraints" policy and against it under any of the other > three. > > Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman that > that type of the constructor should be the same as that of the > pattern. > > Simon Marlow: I believe the statement was in favor of #42 contra #41, > but I didn't get a sense of how strongly or how Simon felt about the > particulars. > > > I agree with and want to highlight Roman's point regarding, > > >A looser relationship between the constructor function and the pattern > makes code significantly harder to read and the proposal doesn't include > any justification for such a looser relationship so I would go with the > strongest requirement possible. > > > It seems to me like the respondents so far are in favor of #42, but > want the strongest variant. I'd like to move to accept #42 with the > "May not differ in anything but the constraints" variant. Any > objections? > > > Thank you Joachim for the status update last week. > > Thanks you for your time everyone, > Chris Allen > _______________________________________________ > 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 Thu Apr 13 15:31:34 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 13 Apr 2017 11:31:34 -0400 Subject: [ghc-steering-committee] Please review: UNPACK on function arguments, Shepherd: Simon Marlow Message-ID: <1492097494.1059.4.camel@joachim-breitner.de> Dear Committee, this is your secretary speaking: https://github.com/ghc-proposals/ghc-proposals/pull/46 was brought before the committee. There was almost no discussion, and this is quite niche. I propose Simon Marlow as the Shepherd, given that he at least looked at it once, and his expertise in performance and RTS stuff. Simon, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. FYI, the oher proposals under discussion at the moment are: Constructor Synonyms and Pattern Synonym Signatures https://github.com/ghc-proposals/ghc-proposals/pull/41 https://github.com/ghc-proposals/ghc-proposals/pull/42 Shepherd: Chris Allen Proposal: Accept 41, reject 42. Status: Consensus is reached. Chris should summarize the verdict and assign the labels appropriately. Eval class https://github.com/ghc-proposals/ghc-proposals/pull/27 Shepherd: Richard Status: This came back after being sent to the author for revision. I guess at this point Richard should make a new decision suggestion. instance force https://github.com/ghc-proposals/ghc-proposals/pull/23 Shepherd: Manuel Status: Awaiting shepherd recommendation. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- 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 Wed Apr 26 11:45:36 2017 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Wed, 26 Apr 2017 21:45:36 +1000 Subject: [ghc-steering-committee] Proposal #23: instance force Message-ID: <61259656-7565-47F0-A6F3-89EC16C224BA@justtesting.org> We need to decide whether we like to accept the ”instance force" proposal: https://github.com/ghc-proposals/ghc-proposals/pull/23 While I understand and am in favour of the motivation behind the proposal, I like to propose to reject the proposal in its current form. My reasons are the following: * The proposal is an ad hoc approach to adding additional type constraints to qualified types involving a specific type class. * I am against adding the proposed ”instance force” declaration form as its *main* motivation is to simplify error messages and type signatures printed by GHCi — i.e., it is of a diagnostic and informative nature. * Something like that does IMHO not belong into the language, but needs to be part of the configuration of the compilation system. In other words, it ought to be a, e.g., compiler option or a language pragma, but not a declaration form. In summary, I’d like to suggest to find an alternative means to get GHC to add the additional constraints to simplify diagnostics and type queries without encumbering the language itself. Cheers, Manuel From mail at joachim-breitner.de Wed Apr 26 16:46:33 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 26 Apr 2017 12:46:33 -0400 Subject: [ghc-steering-committee] Proposal #23: instance force In-Reply-To: <61259656-7565-47F0-A6F3-89EC16C224BA@justtesting.org> References: <61259656-7565-47F0-A6F3-89EC16C224BA@justtesting.org> Message-ID: <1493225193.1120.5.camel@joachim-breitner.de> Hi, Am Mittwoch, den 26.04.2017, 21:45 +1000 schrieb Manuel M T Chakravarty: > * I am against adding the proposed ”instance force” declaration form > as its *main* motivation is to simplify error messages and type > signatures printed by GHCi — i.e., it is of a diagnostic and > informative nature. Hmm, maybe the proposal is unclear on that, but that is not the only motivation. The other main motivation is to make type inference easier and more predictable by avoiding ambiguous types, so that things like {-# LANGUAGE OverloadedStrings #-} print "Test" would work without problems. I believe than Ryan Trinkle expressed interest in a feature like this; he uses a type class to be able to swap out a real implementation of an interface with a testing stub, but in application code he _always_ wants the real implementation – although, to be honest, I think he is more interested in having a guarantee that the compiler optimizes the dictionary away completely, and maybe less in type inference. But I agree that a nicer means to this ends would be, well, nice. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- 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 marlowsd at gmail.com Thu Apr 27 08:02:24 2017 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 27 Apr 2017 09:02:24 +0100 Subject: [ghc-steering-committee] Proposal #23: instance force In-Reply-To: <61259656-7565-47F0-A6F3-89EC16C224BA@justtesting.org> References: <61259656-7565-47F0-A6F3-89EC16C224BA@justtesting.org> Message-ID: I agree with rejecting this proposal. I understand the motivation, but It doesn't feel right to me. I often want something like 'instance force IsString Text', but in many cases the module will also contain a few places where want to use String, so I wouldn't be able to use 'instance force IsString Text' for the whole module and I'd have to fall back to 'default Text' (which I do). So there's an odd overlap between 'instance force' and 'default', it would feel strange to have both of these features. I'm not sure we've fully explored the design space here. "The type of functions with occurrences of Cls that cannot be instantiated" - can this be rigorously defined? In general the approach seems quite ad-hoc. e.g. if I import a function f :: Cls t => t -> Int into a module with `instance force Cls Bool` then it gets instantiated, but instead if I wrapped it in a newtype newtype T = T (forall t . Cls t => t -> Int) f :: T then importing f would not instantiate Cls, presumably? Defaulting works in both of these cases though. Cheers Simon On 26 April 2017 at 12:45, Manuel M T Chakravarty wrote: > We need to decide whether we like to accept the ”instance force" proposal: > > https://github.com/ghc-proposals/ghc-proposals/pull/23 > > While I understand and am in favour of the motivation behind the proposal, > I like to propose to reject the proposal in its current form. > > My reasons are the following: > > * The proposal is an ad hoc approach to adding additional type constraints > to qualified types involving a specific type class. > > * I am against adding the proposed ”instance force” declaration form as > its *main* motivation is to simplify error messages and type signatures > printed by GHCi — i.e., it is of a diagnostic and informative nature. > > * Something like that does IMHO not belong into the language, but needs to > be part of the configuration of the compilation system. In other words, it > ought to be a, e.g., compiler option or a language pragma, but not a > declaration form. > > In summary, I’d like to suggest to find an alternative means to get GHC to > add the additional constraints to simplify diagnostics and type queries > without encumbering the language itself. > > 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 Thu Apr 27 22:56:46 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 27 Apr 2017 22:56:46 +0000 Subject: [ghc-steering-committee] Proposal #23: instance force In-Reply-To: <61259656-7565-47F0-A6F3-89EC16C224BA@justtesting.org> References: <61259656-7565-47F0-A6F3-89EC16C224BA@justtesting.org> Message-ID: I'm afraid I don't like this either. I think of it like this. It's like functional dependencies. With fundeps, if you have class C a b | a -> b instance C Int Bool and you have a "wanted" constraint (C Int t), then you add a new "wanted" constraint (t ~ Bool). With luck that forces t to be Bool (maybe it's a unification variable right now) and you can solve with the instance decl. This proposal say if you have instance force C Int Bool and you have a "wanted" constraint (C ty1 ty2), then add the wanted constraints (ty1 ~ Int) and (ty2 ~ Bool). Very similar in flavour and mechanism. No need to do this ill-specified "change the type of imported functions" stuff. It'd work fine for instance force C [a] too, which the proposal doesn't allow. That could mean (like fundeps) that if you have a "wanted" (C ty) then you get a new wanted (ty ~ [alpha]) where alpha is a fresh unification variable. That is, you are constraining the shape of the argument to C. But still I don't like it much. I don't understand this business of "C is effectively not in scope". I'm sure it won't be long before someone wants to export/import these 'instance force' decls. And yes it does have a funny overlap with the existing 'default' mechanism. Overall I think it's defensible, but doesn't pay its way in cost/benefit terms. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Manuel M T Chakravarty | Sent: 26 April 2017 12:46 | To: ghc-steering-committee at haskell.org | Subject: [ghc-steering-committee] Proposal #23: instance force | | We need to decide whether we like to accept the ”instance force" | proposal: | | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F23&data=02%7C01%7Csimonpj%40microsoft.com%7Ce91dc04dd2 | df4d1730aa08d48c99ca38%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63628 | 8039526075481&sdata=MKBjrTGX4kdlvBJMQeVzUxg2d%2BXBBHAlUS4FfEIPc5I%3D&rese | rved=0 | | While I understand and am in favour of the motivation behind the | proposal, I like to propose to reject the proposal in its current form. | | My reasons are the following: | | * The proposal is an ad hoc approach to adding additional type | constraints to qualified types involving a specific type class. | | * I am against adding the proposed ”instance force” declaration form as | its *main* motivation is to simplify error messages and type signatures | printed by GHCi — i.e., it is of a diagnostic and informative nature. | | * Something like that does IMHO not belong into the language, but needs | to be part of the configuration of the compilation system. In other | words, it ought to be a, e.g., compiler option or a language pragma, but | not a declaration form. | | In summary, I’d like to suggest to find an alternative means to get GHC | to add the additional constraints to simplify diagnostics and type | queries without encumbering the language itself. | | Cheers, | Manuel | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee From mail at joachim-breitner.de Fri Apr 28 00:19:55 2017 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 27 Apr 2017 20:19:55 -0400 Subject: [ghc-steering-committee] Proposal #23: instance force In-Reply-To: References: <61259656-7565-47F0-A6F3-89EC16C224BA@justtesting.org> Message-ID: <1493338795.29864.1.camel@joachim-breitner.de> Hi, I’ll try to refrain from pouncing on every point raised, and I am not trying to sway anyone’s mind (I don’t feel very strongly about the proposal and will not shed a tear if it does not go through), but allow me to comment on Am Donnerstag, den 27.04.2017, 22:56 +0000 schrieb Simon Peyton Jones: > No need to do this ill-specified "change the type of imported > functions" stuff. that I deliberately avoided talking about “Wanted” constraints and other Outside-In terminology, which I consider implementation details and which a language feature specification should, if at all possible, avoid. I might not have succeeded in giving a good specification, but there is a rather clear picture in my head, so I can clarify if there are open questions. > It'd work fine for >         instance force C [a] > too, which the proposal doesn't allow.  Not quite true. If there is a instance C [a] in scope around, then instance force C [a] would work fine. But you are right that the current wording (“from an empty context”) would prohibit it if the instance instance D a => C [a] where in scope. Should the tides turn (which seems unlikely) I can improve this part. Greetings, 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 cma at bitemyapp.com Fri Apr 28 01:43:06 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 27 Apr 2017 20:43:06 -0500 Subject: [ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures In-Reply-To: References: Message-ID: Your suggestions were most helpful anyone. Joachim, the wording you chose especially helped, thank you! Here are my proposed replies to #41 and #42: #41: This proposal is rejected as it abandons the syntactic distinction between constructors and the benefits described don't justify the loss. #42: This proposal is being accepted with some provisions. - The modifications should not change the behavior of existing pattern synonyms that have not specified a type signature. - The proposal doesn't address the relationship between signatures of the constructor and the signature of the pattern. The options discussed in order of most conservative to least were: * May not differ in anything but the constraints. * Must have the same return type. * Must have the same outer type constructor in their return type. * No relation. The committee chose the first, most restricted, variant to follow the principle of least surprise. If there's a strong belief that the looser relationships may be useful, those can be described in a new proposal. If there are no objections I will comment upon and close #41, comment on #42, and then merge #42. Thank you again everyone, Chris On Thu, Apr 13, 2017 at 3:06 AM, Simon Marlow wrote: > Agree, I'm in favour of the conservative version of #42 and against #41. > > But #42 also has a proposal for inference of the constructor type in the > absence of a type signature, and gives several options there. I presume we > want to be conservative and say that we're not making any changes to the > behaviour in the absence of a type signature, right? > > Cheers > Simon > > On 9 April 2017 at 21:16, Christopher Allen wrote: >> >> Thank you to those of you that replied. I'd like to preserve the >> syntactic distinction that construction synonyms eliminates. Your >> statements have shifted me to a reject on >> https://github.com/ghc-proposals/ghc-proposals/pull/41 >> >> If no one has objections, I'd like to move to a reject as I think >> enough time has elapsed that it's unlikely to get any defenders. Speak >> up if you feel something was missed. >> >> >> Regarding https://github.com/ghc-proposals/ghc-proposals/pull/42 >> >> Summarizing peoples' replies so far: >> >> Joachim: In favor, as long as :i does the right thing. Seems >> under-specified, suggested the following possible relationships >> between signature of the pattern and the constructor: >> >> * May not differ in anything but the constraints. >> * Must have the same return type. >> * Must have the same outer type constructor in their return type. >> * No relation. >> >> Roman: In favor of this proposal under the "May not differ in anything >> but the constraints" policy and against it under any of the other >> three. >> >> Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman that >> that type of the constructor should be the same as that of the >> pattern. >> >> Simon Marlow: I believe the statement was in favor of #42 contra #41, >> but I didn't get a sense of how strongly or how Simon felt about the >> particulars. >> >> >> I agree with and want to highlight Roman's point regarding, >> >> >A looser relationship between the constructor function and the pattern >> > makes code significantly harder to read and the proposal doesn't include any >> > justification for such a looser relationship so I would go with the >> > strongest requirement possible. >> >> >> It seems to me like the respondents so far are in favor of #42, but >> want the strongest variant. I'd like to move to accept #42 with the >> "May not differ in anything but the constraints" variant. Any >> objections? >> >> >> Thank you Joachim for the status update last week. >> >> Thanks you for your time everyone, >> Chris Allen >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee at haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > -- Chris Allen Currently working on http://haskellbook.com From simonpj at microsoft.com Fri Apr 28 07:40:52 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 28 Apr 2017 07:40:52 +0000 Subject: [ghc-steering-committee] Proposal #23: instance force In-Reply-To: <1493338795.29864.1.camel@joachim-breitner.de> References: <61259656-7565-47F0-A6F3-89EC16C224BA@justtesting.org> <1493338795.29864.1.camel@joachim-breitner.de> Message-ID: | that I deliberately avoided talking about “Wanted” constraints and | other Outside-In terminology, which I consider implementation details | and which a language feature specification should, if at all possible, | avoid. I might not have succeeded in giving a good specification, but I agree with that, and it's a valid criticism of my language. However, if you want to reason about what type should be inferred for f x = x==x && x>x (which is a user-facing thing, totally part of the language spec), then it's probably easier to say "From the use of (==) you get a wanted (Eq a) constraint, where x::a. From the use of (>) you get a wanted (Ord a). Both can be derived from a Given (Ord a)." or language like that. Understanding typing rules is, I think, harder. Moreover, it's quite hard to explain fundeps using typing rules. (Try it!) I was trying to draw the analogy, since we already have fundeps. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Joachim Breitner | Sent: 28 April 2017 01:20 | To: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Proposal #23: instance force | | Hi, | | I’ll try to refrain from pouncing on every point raised, and I am not | trying to sway anyone’s mind (I don’t feel very strongly about the | proposal and will not shed a tear if it does not go through), but | allow me to comment on | | Am Donnerstag, den 27.04.2017, 22:56 +0000 schrieb Simon Peyton Jones: | > No need to do this ill-specified "change the type of imported | > functions" stuff. | | that I deliberately avoided talking about “Wanted” constraints and | other Outside-In terminology, which I consider implementation details | and which a language feature specification should, if at all possible, | avoid. I might not have succeeded in giving a good specification, but | there is a rather clear picture in my head, so I can clarify if there | are open questions. | | > It'd work fine for | >         instance force C [a] | > too, which the proposal doesn't allow. | | Not quite true. If there is a | | instance C [a] | | in scope around, then | | instance force C [a] | | would work fine. | | | But you are right that the current wording (“from an empty context”) | would prohibit it if the instance | | instance D a => C [a] | | where in scope. | | Should the tides turn (which seems unlikely) I can improve this part. | | Greetings, | Joachim | | | | | -- | Joachim Breitner | mail at joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C4dbafc73718744 | 86953b08d48dcc51fe%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636289 | 356110063073&sdata=Zs%2BSqmtdFn7a%2Fvy7h2KC1m%2Fu%2Bj3DiOLHzSoIJ7y8BgM | %3D&reserved=0 From simonpj at microsoft.com Fri Apr 28 07:46:40 2017 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 28 Apr 2017 07:46:40 +0000 Subject: [ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures In-Reply-To: References: Message-ID: | If there are no objections I will comment upon and close #41, comment | on #42, and then merge #42. Yes -- but I'd like to see the author revise the text of #42 to incorporate feedback, so what we merge is the actual final proposal. Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces at haskell.org] On Behalf Of Christopher Allen | Sent: 28 April 2017 02:43 | To: Simon Marlow | Cc: ghc-steering-committee at haskell.org | Subject: Re: [ghc-steering-committee] Wrapping up Constructor Synonyms | and Pattern Synonym Signatures | | Your suggestions were most helpful anyone. Joachim, the wording you | chose especially helped, thank you! | | Here are my proposed replies to #41 and #42: | | #41: | | This proposal is rejected as it abandons the syntactic distinction | between constructors and the benefits described don't justify the | loss. | | | #42: This proposal is being accepted with some provisions. | | - The modifications should not change the behavior of existing pattern | synonyms that have not specified a type signature. | | - The proposal doesn't address the relationship between signatures of | the constructor and the signature of the pattern. The options | discussed in order of most conservative to least were: | * May not differ in anything but the constraints. | * Must have the same return type. | * Must have the same outer type constructor in their return type. | * No relation. | | The committee chose the first, most restricted, variant to follow the | principle of least surprise. If there's a strong belief that the | looser relationships may be useful, those can be described in a new | proposal. | | | If there are no objections I will comment upon and close #41, comment | on #42, and then merge #42. | | Thank you again everyone, | Chris | | | | | | On Thu, Apr 13, 2017 at 3:06 AM, Simon Marlow | wrote: | > Agree, I'm in favour of the conservative version of #42 and against | #41. | > | > But #42 also has a proposal for inference of the constructor type in | > the absence of a type signature, and gives several options there. I | > presume we want to be conservative and say that we're not making any | > changes to the behaviour in the absence of a type signature, right? | > | > Cheers | > Simon | > | > On 9 April 2017 at 21:16, Christopher Allen | wrote: | >> | >> Thank you to those of you that replied. I'd like to preserve the | >> syntactic distinction that construction synonyms eliminates. Your | >> statements have shifted me to a reject on | >> | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | >> ub.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F41&data=02%7C01%7Csim | >> | onpj%40microsoft.com%7C643cc13fb2564eee29f308d48dd7f244%7C72f988bf86f | >> | 141af91ab2d7cd011db47%7C1%7C0%7C636289406043033050&sdata=m090Oh7u4i3x | >> SXfTgj6uHqYnF4%2FnwBihOjhLfJy44dQ%3D&reserved=0 | >> | >> If no one has objections, I'd like to move to a reject as I think | >> enough time has elapsed that it's unlikely to get any defenders. | >> Speak up if you feel something was missed. | >> | >> | >> Regarding | >> | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | >> ub.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F42&data=02%7C01%7Csim | >> | onpj%40microsoft.com%7C643cc13fb2564eee29f308d48dd7f244%7C72f988bf86f | >> | 141af91ab2d7cd011db47%7C1%7C0%7C636289406043033050&sdata=rT%2FzUg328i | >> PKjA8dBKhZdVZObo1SQSJWlpmZtHTxm3E%3D&reserved=0 | >> | >> Summarizing peoples' replies so far: | >> | >> Joachim: In favor, as long as :i does the right thing. Seems | >> under-specified, suggested the following possible relationships | >> between signature of the pattern and the constructor: | >> | >> * May not differ in anything but the constraints. | >> * Must have the same return type. | >> * Must have the same outer type constructor in their return type. | >> * No relation. | >> | >> Roman: In favor of this proposal under the "May not differ in | >> anything but the constraints" policy and against it under any of | the | >> other three. | >> | >> Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman | that | >> that type of the constructor should be the same as that of the | >> pattern. | >> | >> Simon Marlow: I believe the statement was in favor of #42 contra | #41, | >> but I didn't get a sense of how strongly or how Simon felt about | the | >> particulars. | >> | >> | >> I agree with and want to highlight Roman's point regarding, | >> | >> >A looser relationship between the constructor function and the | >> >pattern makes code significantly harder to read and the proposal | >> >doesn't include any justification for such a looser relationship | so | >> >I would go with the strongest requirement possible. | >> | >> | >> It seems to me like the respondents so far are in favor of #42, but | >> want the strongest variant. I'd like to move to accept #42 with the | >> "May not differ in anything but the constraints" variant. Any | >> objections? | >> | >> | >> Thank you Joachim for the status update last week. | >> | >> Thanks you for your time everyone, | >> Chris Allen | >> _______________________________________________ | >> ghc-steering-committee mailing list | >> ghc-steering-committee at haskell.org | >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | commit | >> tee | > | > | | | | -- | Chris Allen | Currently working on | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskel | lbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C643cc13fb2564eee29f | 308d48dd7f244%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63628940604 | 3033050&sdata=5ExSGEwy6qgqGfi8HMtRjtkXVtObLQLBUN7xslCp%2BlU%3D&reserve | d=0 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee at haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee From cma at bitemyapp.com Fri Apr 28 14:52:20 2017 From: cma at bitemyapp.com (Christopher Allen) Date: Fri, 28 Apr 2017 09:52:20 -0500 Subject: [ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures In-Reply-To: References: Message-ID: That answers a question I had, thank you Simon. I'll do so. On Fri, Apr 28, 2017 at 2:46 AM, Simon Peyton Jones wrote: > | If there are no objections I will comment upon and close #41, comment > | on #42, and then merge #42. > > Yes -- but I'd like to see the author revise the text of #42 to incorporate feedback, so what we merge is the actual final proposal. > > Simon > > | -----Original Message----- > | From: ghc-steering-committee [mailto:ghc-steering-committee- > | bounces at haskell.org] On Behalf Of Christopher Allen > | Sent: 28 April 2017 02:43 > | To: Simon Marlow > | Cc: ghc-steering-committee at haskell.org > | Subject: Re: [ghc-steering-committee] Wrapping up Constructor Synonyms > | and Pattern Synonym Signatures > | > | Your suggestions were most helpful anyone. Joachim, the wording you > | chose especially helped, thank you! > | > | Here are my proposed replies to #41 and #42: > | > | #41: > | > | This proposal is rejected as it abandons the syntactic distinction > | between constructors and the benefits described don't justify the > | loss. > | > | > | #42: This proposal is being accepted with some provisions. > | > | - The modifications should not change the behavior of existing pattern > | synonyms that have not specified a type signature. > | > | - The proposal doesn't address the relationship between signatures of > | the constructor and the signature of the pattern. The options > | discussed in order of most conservative to least were: > | * May not differ in anything but the constraints. > | * Must have the same return type. > | * Must have the same outer type constructor in their return type. > | * No relation. > | > | The committee chose the first, most restricted, variant to follow the > | principle of least surprise. If there's a strong belief that the > | looser relationships may be useful, those can be described in a new > | proposal. > | > | > | If there are no objections I will comment upon and close #41, comment > | on #42, and then merge #42. > | > | Thank you again everyone, > | Chris > | > | > | > | > | > | On Thu, Apr 13, 2017 at 3:06 AM, Simon Marlow > | wrote: > | > Agree, I'm in favour of the conservative version of #42 and against > | #41. > | > > | > But #42 also has a proposal for inference of the constructor type in > | > the absence of a type signature, and gives several options there. I > | > presume we want to be conservative and say that we're not making any > | > changes to the behaviour in the absence of a type signature, right? > | > > | > Cheers > | > Simon > | > > | > On 9 April 2017 at 21:16, Christopher Allen > | wrote: > | >> > | >> Thank you to those of you that replied. I'd like to preserve the > | >> syntactic distinction that construction synonyms eliminates. Your > | >> statements have shifted me to a reject on > | >> > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > | >> ub.com%2Fghc-proposals%2Fghc- > | proposals%2Fpull%2F41&data=02%7C01%7Csim > | >> > | onpj%40microsoft.com%7C643cc13fb2564eee29f308d48dd7f244%7C72f988bf86f > | >> > | 141af91ab2d7cd011db47%7C1%7C0%7C636289406043033050&sdata=m090Oh7u4i3x > | >> SXfTgj6uHqYnF4%2FnwBihOjhLfJy44dQ%3D&reserved=0 > | >> > | >> If no one has objections, I'd like to move to a reject as I think > | >> enough time has elapsed that it's unlikely to get any defenders. > | >> Speak up if you feel something was missed. > | >> > | >> > | >> Regarding > | >> > | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > | >> ub.com%2Fghc-proposals%2Fghc- > | proposals%2Fpull%2F42&data=02%7C01%7Csim > | >> > | onpj%40microsoft.com%7C643cc13fb2564eee29f308d48dd7f244%7C72f988bf86f > | >> > | 141af91ab2d7cd011db47%7C1%7C0%7C636289406043033050&sdata=rT%2FzUg328i > | >> PKjA8dBKhZdVZObo1SQSJWlpmZtHTxm3E%3D&reserved=0 > | >> > | >> Summarizing peoples' replies so far: > | >> > | >> Joachim: In favor, as long as :i does the right thing. Seems > | >> under-specified, suggested the following possible relationships > | >> between signature of the pattern and the constructor: > | >> > | >> * May not differ in anything but the constraints. > | >> * Must have the same return type. > | >> * Must have the same outer type constructor in their return type. > | >> * No relation. > | >> > | >> Roman: In favor of this proposal under the "May not differ in > | >> anything but the constraints" policy and against it under any of > | the > | >> other three. > | >> > | >> Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman > | that > | >> that type of the constructor should be the same as that of the > | >> pattern. > | >> > | >> Simon Marlow: I believe the statement was in favor of #42 contra > | #41, > | >> but I didn't get a sense of how strongly or how Simon felt about > | the > | >> particulars. > | >> > | >> > | >> I agree with and want to highlight Roman's point regarding, > | >> > | >> >A looser relationship between the constructor function and the > | >> >pattern makes code significantly harder to read and the proposal > | >> >doesn't include any justification for such a looser relationship > | so > | >> >I would go with the strongest requirement possible. > | >> > | >> > | >> It seems to me like the respondents so far are in favor of #42, but > | >> want the strongest variant. I'd like to move to accept #42 with the > | >> "May not differ in anything but the constraints" variant. Any > | >> objections? > | >> > | >> > | >> Thank you Joachim for the status update last week. > | >> > | >> Thanks you for your time everyone, > | >> Chris Allen > | >> _______________________________________________ > | >> ghc-steering-committee mailing list > | >> ghc-steering-committee at haskell.org > | >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > | commit > | >> tee > | > > | > > | > | > | > | -- > | Chris Allen > | Currently working on > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskel > | lbook.com&data=02%7C01%7Csimonpj%40microsoft.com%7C643cc13fb2564eee29f > | 308d48dd7f244%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63628940604 > | 3033050&sdata=5ExSGEwy6qgqGfi8HMtRjtkXVtObLQLBUN7xslCp%2BlU%3D&reserve > | d=0 > | _______________________________________________ > | ghc-steering-committee mailing list > | ghc-steering-committee at haskell.org > | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > | committee -- Chris Allen Currently working on http://haskellbook.com