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