🚀 go-pugleaf

In article <pallas.670008199@red-dwarf>, pallas@eng.sun.com (Joseph Pallas) writes:
|> 
|> >    In a way, the problem exists because today's type systems are based
|> >    on what you *could* do to the list in someProc, not on what you actually
|> >    do.  
|> 
|> Indeed.  If I could provide more information about someProc, such as
|> the fact that it never attempts to modify its parameter (did I hear
|> someone cough "const"?), then even a simple type checker would be
|> happy to approve this operation.  Urs is correct that subtyping is NOT
|> the right way to express this relationship.  Subtyping is too strict a
|> conformance relation.

The problem is (unfortunately) harder than "const": if you have a generic
type (say List), e.g.:

type List[T] = 
	......
	procedure f(arg: T);

then the above problem pops up, even if f doesn't change the List (e.g.
"const arg: T" wouldn't change the problem a bit).  The problem is 
contravariance: for a List[SubT], f's signature is "procedure taking a SubT",
i.e. a more restricted type than T, violating contravariance.

Before any Eiffel fans say "Gotcha!" :-), let me go on to say that 
contravariance isn't really the *problem*, just a (correct) formulation of it:
if List[SubT] were a subtype of List[T], some variable v: List[T] could
contain either a List[T] or a List[SubT].  However, the statement
"v.f(t)" (with t:T) would be unsafe: if t holds a T, and v a List[SubT],
we're passing only a T to f, not a SubT as expected (declared).

So, again, the problem isn't contravariance, but how you apply it.

-Urs

------------------------------------------------------------------------------
Urs Hoelzle                 			       hoelzle@cs.stanford.EDU
Center for Integrated Systems, CIS 42, Stanford University, Stanford, CA 94305