Re: Dictionaries are sometimes not necessary

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

From: Kevin Hammond <kh@cs.glasgow.ac.uk>
Date: Thu, 28 Feb 91 22:31:55 GMT
To: E.Ireland@massey.ac.nz, haskell@cs.glasgow.ac.uk
Subject: Re:  Dictionaries are sometimes not necessary
Sender: haskell-request@cs.glasgow.ac.uk

> My intended approach for compiling type classes is to build a number of
> distinct closures for f, all sharing the same compiled function.  The number of
> closures will depend on the static structure of the entire Haskell program.
> For example, if a program makes use of the (overloaded) equality function on
> [Int], [[Char]], and [Integer], I would envisage generating three closures for
> the list equality function.

To implement this, you will need to construct the call-graph for an
entire program, and traverse it multiple times (for the different
uses).  This seems quite an expensive proposition.  I suspect this will
be impractical for non-trivial programs, unless you can find a cheap
solution [in which case, let us know, we have some problems in partial
evaluation that could use this].

Also, how do you solve the "dictionary transfer problem", as shown by:

	f :: Integral a => [b] -> a
	f x y = length x + y

Here the closure used for length will depend on the type of y.  That is,
you *must* generate multiple functions here (or use a type-distinguishing
parameter).

This is just a trivial example, it gets harder if you need to traverse
the dictionary hierarchy.  Have I misunderstood something, or is this a
flaw in your scheme?

Kevin