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

[Simon Peyton Jones]

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 at haskell.org] On Behalf Of Simon Marlow
Sent: 23 March 2017 10:01
To: Roman Leshchinskiy <rleshchinskiy at gmail.com>
Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] Constructor synonyms, signatures on pattern synonym constructors

On 21 March 2017 at 23:26, Roman Leshchinskiy <rleshchinskiy at gmail.com<mailto:rleshchinskiy at gmail.com>> wrote:
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<mailto: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.

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 at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170323/8f0b6eeb/attachment-0001.html>