Wrapping up Constructor Synonyms and Pattern Synonym Signatures

Christopher Allen

9 Apr 2017 9 Apr '17

8:16 p.m.

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

Show replies by date

Manuel M T Chakravarty

10 Apr 10 Apr

12:39 a.m.

New subject: Wrapping up Constructor Synonyms and Pattern Synonym Signatures

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard Eisenberg

11:54 a.m.

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

2:12 p.m.

New subject: Wrapping up Constructor Synonyms and Pattern Synonym Signatures

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@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Simon Peyton Jones

3:22 p.m.

New subject: Wrapping up Constructor Synonyms and Pattern Synonym Signatures

| 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#defau... Simon | -----Original Message----- | From: ghc-steering-committee [mailto:ghc-steering-committee- | bounces@haskell.org] On Behalf Of Christopher Allen | Sent: 09 April 2017 21:17 | To: ghc-steering-committee@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@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee

Simon Marlow

13 Apr 13 Apr

8:06 a.m.

New subject: Wrapping up Constructor Synonyms and Pattern Synonym Signatures

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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Christopher Allen

28 Apr 28 Apr

1:43 a.m.

New subject: 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://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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com

Simon Peyton Jones

7:46 a.m.

New subject: Wrapping up Constructor Synonyms and Pattern Synonym Signatures

| 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@haskell.org] On Behalf Of Christopher Allen | Sent: 28 April 2017 02:43 | To: Simon Marlow | Cc: ghc-steering-committee@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@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@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee

Christopher Allen

2:52 p.m.

New subject: Wrapping up Constructor Synonyms and Pattern Synonym Signatures

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@haskell.org] On Behalf Of Christopher Allen | Sent: 28 April 2017 02:43 | To: Simon Marlow | Cc: ghc-steering-committee@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@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@haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- | committee

-- Chris Allen Currently working on http://haskellbook.com

2994

Age (days ago)

3013

Last active (days ago)

List overview

Download

8 comments

6 participants

participants (6)

Christopher Allen
Joachim Breitner
Manuel M T Chakravarty
Richard Eisenberg
Simon Marlow
Simon Peyton Jones