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