Digressing a bit, I wish it were possible to write the pattern above as
I agree! See: https://ghc.haskell.org/trac/ghc/wiki/ViewPatternsAlternative
Maybe we should work that up into a new GHC proposal.
Simon
From: ghc-steering-committee [mailto:ghc-steering-committee-bounces@haskell.org] On Behalf Of Simon Marlow
Sent: 23 March 2017 10:01
To: Roman Leshchinskiy
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. Yes, I think I agree with this too. The point of pattern synonyms is to let you define something that to the importer of a module looks exactly like a data constructor, while allowing the author of the module to change its implementation. It fills in a missing opportunity for abstraction in the language. But constructor synonyms go much further than this, allowing you to define something that looks like a data constructor but doesn't behave anything like one. It drops the requirement that the constructor be expressible as a pattern. If you want to do this, define a function! Why not solve the original problem by allowing a separate type signature on the constructor in the pattern synonym? There's already an example of this in the proposal: pattern Zero :: (Eq a, Num a) => a pattern Zero <- ((== 0) -> True) where Zero :: Num a => a Zero = 0 (the proposal has the signature on Zero slightly wrong, I think). This seems like it would address the problem but without also overly generalising what a conid can represent, and avoids the issues with import/export. Digressing a bit, I wish it were possible to write the pattern above as pattern Zero :: (Eq a, Num a) => a pattern Zero <- x | x == 0 where Zero :: Num a => a Zero = 0 because I think ViewPatterns were a mistake. But that's a proposal for another day :) Cheers Simon
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 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee