[ghc-steering-committee] Wrapping up Constructor Synonyms and Pattern Synonym Signatures

[Christopher Allen]

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://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