[Haskell-cafe] Existential type variables in constraints

[Anthony Clayden]

> because UndecidableInstances is definitely required for this and I know
it's a problematic one.

Hi Juan, I'll knock that on the head at once. `UndecidableInstances` is not
"problematic" (or at least it's far less problematic than others you list).
Although we're lacking a proof that it can't lead to incoherence/type
unsafety, nobody's demonstrated unsafety due to `UndecidableInstances`
alone -- that is, providing the program compiles (i.e. instance resolution
terminates).

OTOH `FlexibleInstances` can give `OverlappingInstances` -- maybe
overlapping with those in some other module, thus giving the dreaded Orphan
instances problems. I'd be much more concerned about them.

> instance (Ord a, forall b c. (Ord b, Ord c)) => Class1 a where
>   fun1 = (<)


Why does that even mention `b` or `c`? There's no FunDep from `a`, to
get a FunDep there'd be a constraint `D a b c` or something. They seem
totally redundant.


> completely overlooked by the compiler


Yes. Quite. What do you expect the compiler to do? Even if the class
decl gave a signature for `fun1` mentioning `b`, `c`, those would be
_distinct_ tyvars, because they're not scoped in the class head.


> is there any way I can make this work?


Sorry, I don't know what you want to "work". Please at least show a
class decl with a FunDep. From your second message:


> it is possible in principle that (Ord a, Ord b) produces a functional dependency between a and b


No it isn't possible, even in principle: `(..., ...)` is a tuple
constructor, not a class; therefore no FunDep could apply.


AntC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210403/a5e33885/attachment.html>