Simon's proposal seems reasonable -- I've been told that this idea is already
used in Miranda and hbc (with a command line option that I don't know) so it
certainly is feasible.
However ... as Satish has pointed out, we need to be very careful about the
interaction with overloading. In particular, Satish was concerned about the
definition of an equality on
data Foo a = A | B (Foo [a])
I don't think this would actually be a problem; we just write:
instance Eq a => Eq (Foo a) where
A == A = True
B x == B y = x==y
_ == _ = False
And the translation would be:
eqFoo :: Eq a => Foo a -> Foo a -> Bool
...
eqFoo d (B x) (B y) = (==) (dEqFoo (dEqList d)) x y
...
where dEqFoo :: Eq a => Eq (Foo a) and dEqList :: Eq a => Eq [a] are
the corresponding dictionary constructor functions (the `explicit' context
in the instance declaration is what makes this possible; if I showed the
definition of dEqFoo, the recursion here would be more obvious).
THAT SAID, the decision to support polymorphic recursion in the presence of
explicit type signatures does have an effect on the choice of implementation
strategies that can be used. For example, I have two implementations of type
class overloading that *cannot* support this extension:
o The Gofer approach to type classes.
o An implementation which eliminates the use of dictionaries altogether
by generating specialized versions of the code for overloaded values.
The reason in both cases is that the number of dictionaries required in a
program using polymorphic recursion and overloading, for example, through
a definition like:
f :: Eq a => a -> Bool
f x = x==x || f [x]
is potentially unbounded, requiring run-time dictionary construction.
The fact that these two implementations can't support the proposed extension
doesn't necessarily mean that the proposal should not be considered or
adopted. But let's make sure we're not going to run into any big problems
before we commit ourselves!
All the best,
Mark
