[TYPES] A show-stopping problem for modular type classes?
Karl Crary
crary at cs.cmu.edu
Wed Oct 7 17:52:05 EDT 2009
Brian Hulley wrote:
> Thanks for pointing out that the compiler could just reject this
> clause: perhaps this would be an acceptable penalty to pay for the
> advantages of having scoped instances. However there are situations
> where it would not be so clear what the compiler should do eg:
>
> bar :: forall a. G a -> (a, Int)
> bar (Problem x) = (x + x, 1 + 2)
> bar (Ok _) = ((), 0)
1.
As Derek correctly pointed out, this works fine. In the "Problem" case,
"a" is an abstract type that has in instance of Num. The addition for x
is resolved using the instance for "a", and other addition is resolved
using the instance for Int.
I wonder if you're forgetting that overloading is resolved statically?
The type "a" is abstract, and it has a unique instance for Num. The
possibility that "a" might ultimately be instantiated with Int is
irrelevant. So one solution to your problem is to treat the unpacking
of a GADT arm associated with an instance as a using declaration, with
the usual test for overlapping instances
2.
I didn't know that Haskell allows GADTs to be built over kinds other
than Type (aka *). That's nice. What I was suggesting went beyond
that. My suggestion is that the index to a GADT, even when it happens
to be a type, should not be associated with an instance. Under such a
design, this problem would simply go away.
3.
I'm surprised to hear that the GHC internals now support type
abstraction, in the sense of indefinite references. Am I understanding
you correctly? Not so long ago I was told that implementing functors in
GHC would be a non-starter.
-- Karl
More information about the Types-list
mailing list