From the 1991 memo "each constructor gets a context which is a subset of
(For some background to my thinking see here https://mail.haskell.org/pipermail/haskell-cafe/2020-September/132714.html ) 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. that given in the @data@ decl, containing all the constraints on the free type variables of the constructor signature, and no others." So we get (example from the 1998 Language Report) data Eq a => Set a = NilSet | ConsSet a (Set a) ===> NilSet :: forall a. Set a ===> ConsSet :: forall a. Eq a => a -> Set a 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 nilSet = NilSet :: Eq a => Set a 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 emptyS1 NilSet = True -- inferred :: Set a -> Bool emptyS1 _ = False emptyS2 (ConsSet _ _) = False -- inferred :: Eq a => Set a -> Bool emptyS2 _ = True 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? 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`). Would the concern in the 1991 memo still apply in 1999, or 2006 when Hugs development ceased? "I was persuaded ... by John's comments, and by the fact that many more cases of ambiguity are likely to arise otherwise." 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? AntC