[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