<div dir="ltr">(For some background to my thinking see here <a href="https://mail.haskell.org/pipermail/haskell-cafe/2020-September/132714.html" target="_blank">https://mail.haskell.org/pipermail/haskell-cafe/2020-September/132714.html</a> )<div><br></div><div>There's a part of the spec for DatatypeContexts that's been there since the beginning (1991), but doesn't seem right to me. The effect of the 1999 'clarification' to the spec makes it seem even less right.</div><div><br></div><div>From the 1991 memo "<span style="color:rgb(0,0,0);font-size:1em">each constructor gets a context which is a subset of that </span><span style="color:rgb(0,0,0);font-size:1em">given in the @data@ </span>decl<span style="color:rgb(0,0,0);font-size:1em">, containing all the constraints on the free </span><span style="font-size:1em;color:rgb(0,0,0)">type variables of the constructor signature, and no others.</span>"</div><div><br></div><div>So we get (example from the 1998 Language Report)</div><div><br></div><div>    data Eq a => Set a = NilSet | ConsSet a (Set a)</div><div><br></div><div>    ===> NilSet :: forall a. Set a</div><div>    ===> ConsSet :: forall a. Eq a => a -> Set a</div><div><br></div><div>Well, in the type signature for NilSet, `a` _is_ free, why can't it get the constraint? It's easy enough to give a signature with constraint for some appearance of `NilSet` -- except in the one place I desperately want one, that is in patterns. I can define</div><div><br></div><div>    nilSet = NilSet :: Eq a => Set a</div><div><br></div><div>and use that on rhs of function definitions, etc. The compiler doesn't seem to come crashing down around my ears. Whereas without the `Eq a`, you can write `NilSet :: Set (Int -> Int)` without complaint to produce an unusable value -- something that will cause complaints every other place you try to consume it or Cons to it. Compare</div><div><br></div><div>    emptyS1 NilSet = True           -- inferred :: Set a -> Bool</div><div>    emptyS1 _      = False</div><div><br></div><div>    emptyS2 (ConsSet _ _) = False  -- inferred :: Eq a => Set a -> Bool</div><div>    emptyS2 _             = True</div><div><br></div><div>Those two definitions are morally equivalent, but get different types. Note that prior to the 1999 'clarification' GHC would have given them both the same signature without the `Eq a`. The brains trust in 1999 was firmly of the mind the constraint should be exposed everywhere. If they'd been asked about that type for NilSet and how it didn't expose the constraint, I wonder what they'd say?</div><div><br></div><div>Anyhoo, this note is to say it seems easy enough to modify Hugs  to give the full set of constraints for every data constructor (and consequently get those exposed, so the two definitions form `emptyS` above get the same type, with the `Eq a`).</div><div><br></div><div>Would the concern in the 1991 memo still apply in 1999, or 2006 when Hugs development ceased? "<span style="color:rgb(0,0,0);font-size:1em">I was persuaded ... by John's comments, and </span><span style="color:rgb(0,0,0);font-size:1em">by the fact that many more cases of ambiguity are likely to arise </span><span style="font-size:1em;color:rgb(0,0,0)">otherwise.</span>" John Hughes(?) Anyway I can see no comments on the forum. Would the ambiguities be any worse than those for Numeric Literals being `Num a => a`? Or does the defaulting mechanism rescue those?</div><div><br></div><div>AntC</div></div>