From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA26519 for caml-redistribution; Tue, 19 Jan 1999 17:55:19 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA17787 for ; Mon, 18 Jan 1999 22:18:42 +0100 (MET) Received: from miss.wu-wien.ac.at (miss.wu-wien.ac.at [137.208.107.17]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id WAA13636; Mon, 18 Jan 1999 22:18:40 +0100 (MET) Received: (from mottl@localhost) by miss.wu-wien.ac.at (8.9.0/8.9.0) id WAA09639; Mon, 18 Jan 1999 22:18:40 +0100 (MET) From: Markus Mottl Message-Id: <199901182118.WAA09639@miss.wu-wien.ac.at> Subject: Re: subtyping and inheritance To: Jerome.Vouillon@inria.fr (Jerome Vouillon) Date: Mon, 18 Jan 1999 22:18:40 +0100 (MET) Cc: caml-list@inria.fr (OCAML) In-Reply-To: <19990118205542.06048@pauillac.inria.fr> from "Jerome Vouillon" at Jan 18, 99 08:55:42 pm X-Mailer: ELM [version 2.4 PL21] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: weis Hello, > So, you want to be able to select a method depending on two > objets. This is not directly possible, but you can encode it using two > successive method calls: > > class type symbol_t = object > method x : int > end and terminal_t = object > inherit symbol_t > method y : int > end;; > class symbol x = object (self : 'a) > method x = x > > method compare (other : symbol) = > other#compare_with_symbol (self :> symbol_t) > method compare_with_symbol other = self#x = other#x > method compare_with_terminal (other : terminal_t) = false > end;; > class terminal x y = object (self) > inherit symbol x > method y = y > > method compare (other : symbol) = > other#compare_with_terminal (self :> terminal_t) > method compare_with_symbol other = false > method compare_with_terminal other = > (self#x = other#x) && (self#y = other#y) > end;; To solve this problem I've done something similar (defined an extra comparison method for symbols in class symbol) - I don't know of any better means. But as is obvious: this workaround unfortunately does not really exhibit the virtues of code reuse... Even worse (taking your example): if I add another kind of symbol (say, a nonterminal symbol), I would have to write a comparison method for each kind of symbol already in the class hierarchie. But not enough: I would have to change all of the older classes to recognize the new one! This all, although many of the comparison functions are (syntactically) the same and would only have to be instantiated with another type in the new class. > > But "terminal" *has* a method "y"!!! The problem is that "compare" has > > been instantiated in "symbol" with "symbol" as type parameter to "ord". > > Thus, the method "compare" has type "symbol -> bool". The compiler still > > believes that "compare" should have this type, but wrongly takes the > > type information provided in the declaration of "compare" in "terminal", > > which declares "compare" to be of type "terminal -> bool". This results > > in the incorrect error message that "terminal" has no method "y". > > Here is an explanation of this error message. Just before typing the > method "compare" in class "terminal", we know that its type must be > "symbol -> bool". However, we don't know anything about the type > "terminal" yet (this type will have to be a suitable instance of the > type of self, but this can only be checked once the whole class body > is typed). Then, the type constraint "(other : terminal)" tells the > compiler that the type "terminal" must be the same as the type of the > argument of the method, that is "symbol". This will not be possible, > but the compiler does not know it yet. Then, the type checking fails > because "other", of type "symbol" has no method "y". > > I will try to provide a better error message. Seems that my explanation was not totally wrong (I have not seen the code yet). I didn't know that the compiler would have to know the whole body of the class before it can emit the correct message. I (wrongly) believed that the compiler incrementally extends the interface while interpreting the type information of the methods. Hm, probably a stupid idea... I am not sure, but I can imagine it's a bit tricky to delay the message. The compiler knows that something is wrong, but might need exactly the (inconsistent) type information from the incorrect part to interpret the rest of the methods in the class definition. It would have to ignore the resulting incorrectness of those methods without "forgetting" the true source of the error. [snip second error message] > Here is how you should understand this error message. The method > "compare" in an object of class "terminal" has type "terminal -> > bool". Therefore, it can make use of the method "terminal_order" of > its argument. Thus, as the type "symbol" has no method > "terminal_order", the method "compare" cannot be given the type > "symbol -> bool". Hence, finally, the type "terminal" is not a subtype > of type "symbol", and the coercion is not possible. Ah! That's the way the compiler concludes! When I first encountered this message, I always wondered what was wrong about method "terminal_order" - I didn't look to deeply into the rest of the output... It should take me some time to see that it's method "compare" that causes the trouble - by invoking methods that do not exist in "symbol" but are required there - yet I didn't come to this last conclusion. If the compiler emits a huge bunch of class interfaces in error messages the human user can often be overcharged with interpreting this amount of information... ;-) Best regards, Markus -- Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl