From: Markus Mottl <mottl@miss.wu-wien.ac.at>
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)
In-Reply-To: <19990118205542.06048@pauillac.inria.fr> from "Jerome Vouillon" at Jan 18, 99 08:55:42 pm
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
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:18 MET