Re: Two problems

[Kevin Hammond <kh@cs.glasgow.ac.uk>]

From: Kevin Hammond <kh@cs.glasgow.ac.uk>
Date: Tue, 29 Jan 91 13:04:41 GMT
To: augustss, simonpj@cs.glasgow.ac.uk
Subject: Re: Two problems
Cc: blott@cs.glasgow.ac.uk, haskell@cs.glasgow.ac.uk
Sender: haskell-request@cs.glasgow.ac.uk

> | 1. It's not allowed to make an instance declaration in a module
> | that does not contain the type and/or class declaration of the
> | involved type and class.  Why is this so?  Why can't I define
> | how pairs should be multiplied locally in a module?
> | This restriction forces me to write
> | 	type TPair a b = Pair a b
> | 	instance (Num a) => Num (Pair a a) where
> | 		(Pair a b) * (Pair c d) = Pair (a*c+a*d+b*c) (a*c+b*d)
> | 	psnd (Pair x y) = y
> | 	fib n = psnd ((Pair 1 0)^n)
> | 
> | This problem was anticipated (and the restriction has in fact been
> | removed in Haskell B).
> 
> There is a good reason for this: if the same type can have different 
> instances in different parts of the program, one loses principal types.
> Steve Blott and Phil Wadler worked out the details of this, I think.
> 
> For example, suppose you defined multiplication on pairs in one
> module in one way, and in another in another, and then imported both
> modules into a third.  How do pairs multiply now?  Or are these instances
> purely local to a module (seems a pity)?  If so, how can instances 
> ever get exported?
>  
> It is not impossible that some design could retain principal types
> while allowing local instances, but we thought things had got complicated
> enough already!

If you include the definition module for an instance in the instance
declaration, you can avoid undecidability problems with exported
instances.  However, the imports rules then become *extremely* complex,
both to implement and to use.  Sooner you than me, Lennart...

Kevin