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

[Richard Eisenberg]

As do I (support both decisions that Chris proposes).

Thanks!
Richard

> On Apr 9, 2017, at 8:39 PM, Manuel M T Chakravarty <chak at justtesting.org> wrote:
> 
> I support both of the decisions that you propose.
> 
> Manuel
> 
>> Christopher Allen <cma at bitemyapp.com>:
>> 
>> 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