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

[Simon Marlow]

On 21 March 2017 at 23:26, Roman Leshchinskiy <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> 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
> 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/d8676a84/attachment.html>