<div dir="ltr"><font face="arial, sans-serif"><br></font><div><font face="arial, sans-serif">There's a discussion in May 1999 pointing out the H98 Report is "inexplicit" wrt the semantics of pattern matching on datatypes with a context.</font></div><div><font face="arial, sans-serif"><a href="http://web.archive.org/web/20151208175102/http://code.haskell.org/~dons/haskell-1990-2000/threads.html#04062">http://web.archive.org/web/20151208175102/http://code.haskell.org/~dons/haskell-1990-2000/threads.html#04062</a>, 'Contexts on datatype declarations', starting at SPJ's opener.<br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">The Report has this example, section 4.2.1:</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">> data Eq a => Set a = NilSet | ConsSet a (Set a) -- with inferred types<br></font></div><div><font face="arial, sans-serif">> -- NilSet :: forall a. Set a</font></div><div><font face="arial, sans-serif">> -- ConsSet :: forall a. Eq a => a -> Set a -> a</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">(If, per Wadler's response, he thinks "a <span style="color:rgb(0,0,0);font-size:1em">type will make no sense without the</span></font></div><div><font face="arial, sans-serif"><span style="color:rgb(0,0,0);font-size:1em">constraints</span>", what sense is there in having a `NilSet` without constraints?)</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Ref the q SPJ poses, it's _not_ the case that a selector function always gets the constraint inferred. (As of Hugs 2006 and GHC 8.10.)</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">If a selector function pattern matches on `ConsSet`, `Eq a =>` is indeed inferred. But if matching on only `NilSet`, or only on a bare var/wildcard pattern, no constraint. (In practice of course you would be matching on `ConsSet`, so this point is purely academic.)</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Anyhoo, this behaviour doesn't deliver Wadler's objective. And I find it weird you have to look at the term level to explain the type. Since `data Eq a => ...` prefixes the type and constructors, I'd expect the behaviour to apply at _type_ level.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">If I bend Hugs to behave same as-was GHC (no constraint inferred if purely matching), I get the benefit I can declare instances for constructor classes (including Foldable) over type constructor `Set`. Whereas the post-May 199 behaviour disallows this: pattern matching in the method decls wants an `Eq a =>`, but there's no means to pass in a dictionary.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I can't declare a Functor instance, because building the result applies the data constructors, so does want a dictionary; again there's no means to pass one in. I can simulate `fmap` via Foldable's `foldMap`, because that wants a Monoid instance for the builder, and that does see the element type as well as the constructor. (The builder can squish out resulting duplicates, so preserving the invariant of `Set`.) Not being able to declare `Set` an instance of Functor is a Good Thing. Nor of Monad</font></div><div><font face="arial, sans-serif"><a href="https://mail.haskell.org/pipermail/haskell-cafe/2004-March/005995.html">https://mail.haskell.org/pipermail/haskell-cafe/2004-March/005995.html</a><br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">As SPJ points out later in the 1999 thread</font></div><div><pre style="color:rgb(0,0,0)"><font face="arial, sans-serif">> But when you take a constructor *apart*, the invariant must hold
> by construction: you couldn't have built the thing you are taking
> apart unless invariant held. So enforcing the invariant again is
> redundant; and in addition it pollutes the type of selectors.</font></pre></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">(I note GHC's Pattern Synonyms seem to have fallen into the same hephalump trap of polluting constraints for matching with constraints needed only for building.)</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">If you're thinking "but hasn't GHC solved all this with GADTs?" I say no: their sweet spot is where there's different constraints down the structure; you can't help but hold a different dictionary at each node and 'Provide' it on pattern matching. Whereas for `Set` it's crucial you have exactly the same constraint 'all the way down', and all nodes type `Set a`.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">I can (just about) see use cases for datatypes that both have global contexts and GADT constructors.</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">AntC</font></div><div><br></div></div>