[109] in Coldmud discussion meeting

Re: Proposed change regarding MI ambiguities

daemon@ATHENA.MIT.EDU (Fri Dec 10 20:30:04 1993 )

Date: Sat, 11 Dec 93 01:23:29 GMT
From: Andrew Wilson <Andrew.Wilson@cm.cf.ac.uk>
To: coldstuff@MIT.EDU


> From ghudson@MIT.EDU Fri Dec 10 23:26:36 1993
> From: ghudson@MIT.EDU
> Date: Fri, 10 Dec 1993 18:22:20 -0500
> To: coldstuff@MIT.EDU
> Subject: Proposed change regarding MI ambiguities
> Content-Length: 1656
> 
> 
> While composing mail to tiny-splatters, it occurred to me that
> detecting ambiguities in the method search and triggering an error
> would be preferrable to my current method in three respects:
> 
> 	* It is simpler.
> 
> 	* If an object has O a non-overridable method named 'foo', all
> 	  descendents of that object are guaranteed to call that
> 	  method when sent a message 'foo', unless an ancestor of O
> 	  defines a non-overridable method 'foo', or unless an
> 	  ~ambiguous error results from sending a 'foo' message to O.
> 
> 	* When you pass a message in a method, the method you call
> 	  depends only on the object which defines the current method,
> 	  not on the current object.  That is, you know which method
> 	  you're passing to.  (There are implementation advantages
> 	  here as well, but that's not very important.)
> 
> What's an ambiguity?  Given an object with an ancestors digraph, and a
> method name, an ambiguity is when the method definitions do not all
> lie on a single path.  Consider the following two inheritance
> diagrams, where objects marked with an asterix define a method 'foo'.
> 
> 	A			A
> 
> 	B			B*
> 
> 	C			C*
> 
>       D*  E*		      D   E
> 
> 	F*			F*
> 
> 	G			G
> 
> The first diagram is ambiguous, because D and E do not lie on the same
> path up the digraph.  The second diagram is not ambiguous, because
> there is a path which contains all of the method definitions.
> 
> Once you've determined the path which contains all of the method
> definitions, the method used is the topmost non-overridable method, if
> there are any, or the bottommost method if there aren't any.
> 
> I'm pretty sure I can detect ambiguities in linear time.
> 
> Does this seem reasonable to people?

Absolutely not.  It is evident that the ambiguities, if any, can be detected
when the method is defined.  Such ambiguities are, after all, merely syntactic.
There really is no reason at all for not creating a @lint, or equivalent
mechanism for flagging any ambiguities and for refusing to construct an
ambiguous lattice.  Force the semantics to be unambiguous and you are saved
the horror of run-time lattice verification.  I'd suggest that you read up
on the implementation of the Eiffel programming language NOW rather than later.
Do it right, or don't bother.

> --GBH


Andy (Net)