[ghc-steering-committee] Constructor synonyms, signatures on pattern synonym constructors

[Roman Leshchinskiy]

Hi,

I'm in a slightly difficult situation here since I quite dislike the
current pattern synonyms extension. I'll try nonetheless.

On Tue, Mar 21, 2017 at 1:43 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Dienstag, den 21.03.2017, 00:55 -0500 schrieb Christopher Allen:
>> Proposal #41 is constructor synonyms. This would allow users to
>> [...]
>
> it is worth pointing out that under this proposal,
>
> constructor FireMissles :: IO ()
> constructor FireMissles = fireMissles
>
> (without a pattern) is also valid. In other words: The capitalization
> of an identifier will no longer be of significance.
>
> This makes me dislike the proposal.

I completely agree. In fact, this proposal is basically about allowing
value variable names to start with an upper case letter so if we want
to go that way then I'm not sure why the keyword 'constructor' is
necessary at all. I would much prefer not to go that way, though, so
I'm against #41.

>> Proposal #42 would add type signatures for bidirectional pattern
>> synonym constructor functions.
>> [...]

This seems sensible provided there is a strong relation between the
types of the constructor and the pattern.

> The proposal does not address if the signatures of the constructor and
> the signature of the pattern have to be in any way related. Possible
> design choices are:
>  * 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.
> This ought to be clarified.

This is a very good point. I'd be in favour of this proposal under the
"May not differ in anything but the constraints" policy and against it
under any of the other three. 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.

Thanks,

Roman