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@joachim-breitner.de http://www.joachim-breitner.de/