Type tree traversals [Re: Modeling multiple inheritance]

[Brandon Michael Moore]

Thanks for the clever code Oleg. I've tried to extend it again to track
the types of methods as well as just the names, giving a functional
dependancy from the class, method, and to result type. I can't get the
overlapping instances to work out, so I'm handing it back to a master,
and the rest of the list.

We really should change GHC rather than keep trying to work around stuff
like this. GHC will be my light reading for winter break.

The core of the classes are here:

--records superclasses and new methods.
class Interface super sub | sub -> super
--This has any new methods/overloadings, as well as superclasses.
instance Interface (Foo Int Bool,(Bar Bool Int,(ClassC,(ClassA,())))) ClassB

--the "worker type class" to search the ancestors for a method.
--"Ancestors Have Method"
class AHM objs (method :: * -> * -> *) args result | objs method args -> result

--the first two instances conflict.
instance AHM (m a r,x) m a r
instance (AHM (x,(y,cs)) m a r) => AHM ((,) x y,cs) m a r
instance (AHM cs m a r) => AHM ((),cs) m a r
instance (Interface items c, AHM (items,cs) m a r) => AHM (c,cs) m a r

The instances  AHM (m a r,x) m a r
and AHM ((,) x y,cs) m a r)
are conflicting.
Again, I'm willing to compute the inheritance once and have a tool write
out instances for each overloading availible at each class, but it's just
so much cooler to do this in the typeclass system.

For anyone who hasn't been following this, the problem is a java
interface. There are several classes, in a DAG. At several points
in the DAG methods are declared, with an argument type and a return
type. I want some statically checked way of resolving a call with the
name, an object, and an argument list to a particular declaration of
the method with the same arguments in one of the ancestors of the
class. Bonus points for a functional dependancy from class+arguments
to result.

The practical upshot is being able to write code no more complicated than
the java you are replacing:
  do frame <- new_JFrame ()
     set_size frame (10,100)
     set_visible frame True
     ...
vs.
  do frame <- new_JFrame ()
     set_size_JFrame_JInt_JInt_JVoid frame (10,100)
     set_visible_JFrame_JBool_JVoid frame True
     ...
and fun things like functions that work on any object with the correct
interface, not just descendants of some particular class (hey, it's
neat for statically-typed OO languages, okay?)

Brandon