Lambda the Ultimate

inactiveTopic Type-safe Covariance in Eiffel
started 6/3/2003; 12:12:54 PM - last post 6/5/2003; 11:20:18 AM
Kory Markevich - Type-safe Covariance in Eiffel  blueArrow
6/3/2003; 12:12:54 PM (reads: 1018, responses: 4)
http://www.inf.ethz.ch/~meyer/ongoing/covariance/recast.pdf

The typing implications of Eiffel's support for covariant redefinition of function arguments has always left me a little uneasy. The linked paper claims to provide language rules that guarantee type safety in the presence of such redefinitions.

After reading the paper I am still skeptical; it seems like Meyer and company are going to extremes trying to justify the presence of a language feature of limited utility, and the rules presented come off as being a bunch of band-aids. It's dismissal of contravariance, overloading, and F-bounded polymorphism all left me scratching my head.

In my opinion the feature was simply a mistake and should just be removed, but I have not yet encountered a need for it nor any other language that includes it. Does anyone else know of any such needs or languages?

andrew cooke - Re: Type-safe Covariance in Eiffel  blueArrow
6/3/2003; 4:04:52 PM (reads: 1028, responses: 0)
Does anyone else know of any such needs or languages?

i think this just appeared in the latest (pre-)release of java (see a thread just a few days ago). it's optional, for parameterised classes, and only allows safe use (either reading or writing, depending on whether it's co or contra-variant, and you can work out which is which ;o).

(ok, it's not exactly the same, since eiffel uses it for all arguments, but it handles the collections case which was always, iirc, eiffel's justification).

Brent Fulgham - Re: Type-safe Covariance in Eiffel  blueArrow
6/3/2003; 4:27:08 PM (reads: 1017, responses: 0)
Interested reader should also check out Robby Findler's paper on a similar topic (arguing that Meyer's approach is flawed) from the PLT Publications site.

OOPSLA 2001 Findler, Felleisen. Contract Soundness for Object-Oriented Languages

FSE 2001 Findler, Latendresse, Felleisen. Behavioral Contracts and Behavioral Subtyping

Neel Krishnaswami - Re: Type-safe Covariance in Eiffel  blueArrow
6/5/2003; 7:19:08 AM (reads: 992, responses: 0)
I share Kory's head-scratching. As far as I can tell, Gieuseppe Castagna decisively solved this problem a decade ago. Meyer refers to his work in this article, but didn't seem to see the full implications, which are that you want to permit covariant specialization on the arguments you can dispatch on, and contravariant specialization on the ones you can't.

The golden rules he suggests are:

1. Do not use covariance for arrow subtyping.

2. Use covariance to override the parameters that drive the selection of the method.

3. When overriding a binary (or n-ary) method, specify its behavior not only for the actual class but also for its ancestors.

Covariance And Contravariance: Conflict Without A Cause

Kory Markevich - Re: Type-safe Covariance in Eiffel  blueArrow
6/5/2003; 11:20:18 AM (reads: 977, responses: 0)
Their dismissal of Castagna's work had me the most confused initially, but I think I've figured it out. To realize the benefits of Castagna's approach, a language would need to support both method overloading and multiple dispatch. As far as I know no Eiffel dialect has ever supported multiple dispatch. But more importantly, Meyer himself specifically proscribes method overloading (Overloading vs. Object Technology).

It would seem though that Castagna's requirement for method overloading only deals with related types, that is a collection of types with subtype relationships. Meyer's focus is more general in nature, and his examples seem to take exception with identically named methods accepting totally unrelated type arguments. It's not clear to me whether Castagna's requirements actually break the model that Meyer is trying to use.