(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.
>From the 1991 memo "each constructor gets a context which is a subset of
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
_______________________________________________
Hugs-Users mailing list
Hugs-Users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/hugs-users
