Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucsd!ucsbcsl!eiffel!marc
From: marc@eiffel.UUCP (Jean-Marc Nerson)
Newsgroups: comp.lang.eiffel
Subject: Re: "like Current" and static type checking
Summary: Type checking in Eiffel
Message-ID: <163@eiffel.UUCP>
Date: 19 Jun 89 17:52:09 GMT
References: <909@clyde.Concordia.CA>
Organization: Interactive Software Engineering, Santa Barbara CA
Lines: 74


In <909@clyde.Concordia.CA>, Anne Bennet lists a small Eiffel example
and concludes:

>> ........................ (Example skipped) .........
>> ............................................................
>> CONCLUSION: The call "a1.binary_op(a2)" was incorrectly type-checked by
				 the compiler ..... 
>> ..............................................................
>>	.... In other words, it IS possible to type-check the above example,
>>but a conservative type-checker must disallow a call to a routine with a
>>"like Current" parameter whenever it is possible that the receiver may be
>>subject to polymorphism including sibling classes.  If the receiver's
>>dynamic type could be any of several classes in a direct line of inheritance
>>(i.e. no siblings), the call will be correct only if the parameter has as
>>its static type the "youngest" of the polymorphs.  Under these restrictions,
>>it might be wise to do away with anchored parameters altogether; anchored
>>result types and local variables are still ok.
>> ............................................................


Now, let's define the following classes:
------------------------------------------------------
class A
feature
	x: A;

	f (u: A) is
		do
			x := u
		end
end -- class A

class B export f
inherit
	A redefine x 
feature
	x: B
	-- !!!!!!  the statement `x := u' of f is now not valid in B
	-- !!!!!!  if the dynamic type of u is A or a (sub)sibling of B.
end -- class B
------------------------------------------------------

The type checking problem highlighted in class B, occurs whenever there is
a change of reference:
	- In assignments
	- In routine argument passing
	- In Accept operations (Release 2.2)

This is not specifically due to declarations by association (``like''), but simply
because of the ability to redefine with subtyping explicitly or implicitly. 

	o Explicit type redefinition involves the use of a 
	redefine subclause at inheritance time and leads 
	to a change of the redefined feature's signature 
	under conformance rules

	o Implicit type redefinition happens:
     - for a deferred routine implemented with a change of its signature
	  under conformance rules
     - for a type defined ``like anchor'' with ``anchor'' redefined explicitly
       or implicitly because ``anchor'' was ``Current''
     - for a type defined with generic parameter(s) instantiated
       at inheritance time.


As Anne Bennet mentioned at the end of her message, 
Eiffel 3.0 will do a transitive closure type check in accordance 
with the separate compilation mechanism. This will remove all such cases. 
A detailed paper by B. Meyer is forthcoming.

------------------------
Jean-Marc Nerson
marc@eiffel.com