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

Joachim Breitner mail at joachim-breitner.de
Tue Mar 21 13:43:04 UTC 2017


Hi,

Am Dienstag, den 21.03.2017, 00:55 -0500 schrieb Christopher Allen:
> Proposal #41 is constructor synonyms. This would allow users to
> define variables with capitalized names and operators that begin with
> colons. They are meant to complement pattern synonyms. This example
> from the rendered proposal captures the idea and complementarity well
> I think:
> 
> 
> pattern NF :: a -> NF a
> pattern NF a <- UnsafeNF a
> 
> constructor NF :: NFData a => a -> NF a
> constructor NF a = a `deepseq` UnsafeNF a
> 
> pattern Zero :: (Eq a, Num a) => a
> pattern Zero <- ((== 0) -> True)
> 
> constructor Zero :: Num a => a
> constructor Zero = 0

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 guess I would be fine with it if "constructor" were only ever used
together with "pattern". In that case, it would be simply a different
syntax for the other proposal.

> Proposal #42 would add type signatures for bidirectional pattern
> synonym constructor functions.
>
> pattern Zero :: (Eq a, Num a) => a
> pattern Zero <- ((== 0) -> True) where
>   Zero :: Num a => a -- optional
>   Zero = 0
> 
> This would prevent the pattern’s Eq constraint from “infecting” using
> Zero as a constructor, which doesn’t actually need Eq.

In principle in favor of this.

I am less concerned about what :i would show. It could simply use
comments like in the following to explain directionality and possibly
different signatures.

:i Just   -- real constructor
Just :: a -> Maybe a
:i HashOf -- unidirectional
Hash :: Hashable a => Hash -> a  -- pattern matching only
:i Snoc   -- bidirectional, same types
Snoc :: [a] -> a -> [a]
:i Zero  
-- bidirectional, diffrent types, as above
Zero :: (Eq a, Num a) => a 
-- when matching
Zero :: Num a => a          -- when constructing


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.

Greetings,
Joachim


-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170321/13f66749/attachment.sig>


More information about the ghc-steering-committee mailing list