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