[ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures
Simon Peyton Jones
simonpj at microsoft.com
Fri Apr 28 07:46:40 UTC 2017
| 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 <marlowsd at gmail.com>
| 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 <marlowsd at gmail.com>
| 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 <cma at bitemyapp.com>
| 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
More information about the ghc-steering-committee
mailing list