I'm implementing a language that has dynamic types, multiple inheritance with ordered superclasses, and multimethods. I'm writing a whole-program compiler. The class structure and available methods are fixed at compile time, and I'm trying to figure out the best way to generate dispatchers (generic functions) for the methods. This is independent of any question of PIC caching: this is the fallback code that has to work for all cases.
I've decided to make each language class a Java class, all extending Object. Since classes don't have methods, it's trivial to duplicate the fields of superclasses in each subclass. Each class is associated with a marker interface, and at the Java level it implements the marker interfaces associated with its direct superclasses, if any. The multimethods are implemented as static methods of a random class, and at the Java level all arguments are of type Object; only the compiler knows what type they originally had. The class precedence list is constructed in the same way as Python's and Dylan's (see http://192.220.96.201/dylan/linearization-oopsla96.html): concatenate the list for each superclass and then remove all but the last instance of any duplicates; if there's a contradiction, we bomb. Again, the class precedence list has no programmer-visible run-time representation. The question is, what's the best way to write such a dispatcher? We can limit ourselves to methods of one argument WLG, because it's a rule of the language that unless the declared types of the first arguments of two or more candidate multimethods are equal, we don't even look at the declared types of later arguments. My first conclusion is that there can be no fixed order of methods to try. Suppose that there exist classes A, B, AB (with a class precedence list of A, B) and BA (with a class precedence list of B, A). Then an instance of AB must use the method for AB, then the method for A if super() is called, and then the method for B if super() is called again; but an instance of BA must use the method for BA, then the method for B, then the method for A. (No class can be a subclass of both AB and BA, as it would have a contradictory class precedence list.) So a topological sort of methods, once for all, is not possible. I simply don't see anything better than computing all method orderings in advance and then having a big "if (arg instanceof SomeClass) then whatever(...); else ..." chain for each known class that invokes the correct method and passes on a list of the other methods to be invoked if super() is called. Anyone have a better idea? -- GMail doesn't have rotating .sigs, but you can see mine at http://www.ccil.org/~cowan/signatures --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
