<div dir="ltr">Agree, I'm in favour of the conservative version of #42 and against #41.<div><br></div><div>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?</div><div><br></div><div>Cheers</div><div>Simon</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 April 2017 at 21:16, Christopher Allen <span dir="ltr"><<a href="mailto:cma@bitemyapp.com" target="_blank">cma@bitemyapp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you to those of you that replied. I'd like to preserve the<br>
syntactic distinction that construction synonyms eliminates. Your<br>
statements have shifted me to a reject on<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/41" rel="noreferrer" target="_blank">https://github.com/ghc-<wbr>proposals/ghc-proposals/pull/<wbr>41</a><br>
<br>
If no one has objections, I'd like to move to a reject as I think<br>
enough time has elapsed that it's unlikely to get any defenders. Speak<br>
up if you feel something was missed.<br>
<br>
<br>
Regarding <a href="https://github.com/ghc-proposals/ghc-proposals/pull/42" rel="noreferrer" target="_blank">https://github.com/ghc-<wbr>proposals/ghc-proposals/pull/<wbr>42</a><br>
<br>
Summarizing peoples' replies so far:<br>
<br>
Joachim: In favor, as long as :i does the right thing. Seems<br>
under-specified, suggested the following possible relationships<br>
between signature of the pattern and the constructor:<br>
<br>
* May not differ in anything but the constraints.<br>
* Must have the same return type.<br>
* Must have the same outer type constructor in their return type.<br>
* No relation.<br>
<br>
Roman: In favor of this proposal under the "May not differ in anything<br>
but the constraints" policy and against it under any of the other<br>
three.<br>
<br>
Simon PJ: In favor of #42 alone, but no holes. Agrees with Roman that<br>
that type of the constructor should be the same as that of the<br>
pattern.<br>
<br>
Simon Marlow: I believe the statement was in favor of #42 contra #41,<br>
but I didn't get a sense of how strongly or how Simon felt about the<br>
particulars.<br>
<br>
<br>
I agree with and want to highlight Roman's point regarding,<br>
<br>
>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.<br>
<br>
<br>
It seems to me like the respondents so far are in favor of #42, but<br>
want the strongest variant. I'd like to move to accept #42 with the<br>
"May not differ in anything but the constraints" variant. Any<br>
objections?<br>
<br>
<br>
Thank you Joachim for the status update last week.<br>
<br>
Thanks you for your time everyone,<br>
Chris Allen<br>
______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@<wbr>haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
</blockquote></div><br></div>