> Correct. And in that case you would naturally make your
> type parameters covariant. But for function arguments it
> really goes the other way round. How would you find a
> language where immutable collections such as Scala's lists
> are contravariant? I.e you could assign a List[Object] to
> a List[String] but not the other way round? You would find
> that a crazy idea, right? Yet for function parameters
> contravariance exactly as natural and correct as
> covariance is natural and correct for immutable
> collections. Making function parameters covariant is just
> as crazy as making immutable collections contravariant.

I see that. But I'm still not convinced it's worth the extra complications. That it's 'wrong' doesn't invalidate the fact that, in practice, it works just fine for a lot of people.

My real problem with generics is not that it's difficult to understand covariance and contravariance. It's that it's hard to imagine how these declarations will affect what you can do with your APIs later.

Here's an example of this that I ran into with Java: I had an observer interface defined for component types. I then declared that the component type were generic in terms of the observer type. That is, they could have a specialized observers. This worked well for a while because all the observers were created with full knowledge of the generic type of the component. But then I ran into a situation where I wanted to add an observer to all components based on the basic observer interface. I was stuck. I couldn't do that because the generic type of the component was not known. What I wanted was for the method to be covariant and in the case that the observer was not the generic type, allow it to receive the basic notifications. This is what I ended up doing but I had to add a new method. I could not use the generic one. So while you think this is 'crazy' this is actually perfectly fine for my needs. Even in the case where I wouldn't be able to handle the mismatch, a runtime error would be fine.

and further from the same paper of Bertrand's:

"The earlier discussions, and everyday examples, suggest that “the world is
covariant”. In particular allowing covariant results but disallowing covariant
arguments mean that we can’t associate setter procedures (such as sail or engender)
with queries, or write object comparison functions such as is_equal with proper type
signatures. Regrettably in light of its mathematical elegance, this scheme (contravariance) seems to
have little practical applicability."

> yes, it's easy to make up a scenario where parameter
> covariance leads to runtime holes. whether it is a major
> problem in practice is another question.
>
Yes, I think its the same question with respect to covariance of arrays in Java. It is type unsound, but relatively rare that people get ArrayStoreExceptions in practice. They do get them occasionally, though.

> > contravariance is of essentially no practical use.
>
> I'd agree with bertrand here. I've found contravariance
> of input parameters to be useless. covariance is
> statically unsound, and therefore the java position of
> invariance seems sensible in a record type model.
> (Obviously contravariance of return types is a different
> t story)
>
I turned out to need contravariance in ScalaTest matchers design, but it is really also an example of function parameters being contravariant, because in ScalaTest a matcher is a function. Users don't really need to worry about it, or understand why it is contravariant. They just know that things they try that they think should work turn out to work as expected. If you're interested, I put some info on it in this page (search for variance):

http://www.artima.com/scalatest/doc-0.9.5/org/scalatest/matchers/Matcher.html

> > In computing science as in other disciplines, it is
> after
> > all much easier to device drastically simple theories
> if
> > we neglect to make them agree with reality.
>
> we just spend so much time trying to form the perfect type
> system that I wonder if it would be better to accept
> occasional holes for simplicity and clarity. It's the old
> 80/20 rule. To me Bertrand's crazy example sort of makes
> sense. You have a boy skier and a girl skier and they
> can't share a room. However, if you just tell someone you
> have 2 skiers and to put them in a room together, and you
> do it, someone's going to get in trouble ;-)
>
I'd put the question slightly differently. Thinking about how to form the perfect type system is what academics are paid to do, and that's a worthy endeavor. Martin has come up with a pretty nice type system in Scala. The question I'd ask is whether the benefit offered by the type system is worth the cost of learning, understanding, and dealing with that type system. Also, what are the real benefits, and what are the real costs in practice?

> fair enough. i find it simpler then to understand from a
> modeling perspective. for instance, if you have a Java
> class animal:
>
> class Animal { void eat(Food f) {}}
>
> and you want to subclass it to make Bear, you'd ideally
> want:
>
> class Bear extends Animal { void eat (Honey h) {} }
>
> where eat is overridden and Honey is a subclass of Food.
> To me this makes modeling sense, even though we can then
> n ask the question as to what happens if we feed a bear
> weetabix...
>
That's funny. In Programming in Scala we use this example, and show that covariant method parameters would lead to the abhorrent notion that you could feed fish to cows!

> yes, you do it the same sort of way in Beta with virtual
> patterns. In Beta you still have type holes because the
> Boy and Girl would still be subclasses of Skier.
>
> So, in your scala example, does it mean that Boy and Girl
> are no longer subclasses of skier? if they are, what
> happens if you call Skier::share() on a boy as a Skier and
> pass in a girl as a Skier?
>
Oops. I wondered why I got the wrong compiler error. My example was full of bugs. I forgot to make Boy and Girl extend Skier, and forgot to put an explicit type on s. Here's what I meant:

abstract class Skier {
  type SuitableRoommate <: Skier
  def share(other: SuitableRoommate)
}

class Boy extends Skier {
  type SuitableRoommate = Boy
  override def share(other: Boy) {}
}

class Girl extends Skier {
  type SuitableRoommate = Girl
  override def share(other: Girl) {}
}

scala> :load skier.scala
Loading skier.scala...
defined class Skier
defined class Boy
defined class Girl

scala> val s: Skier = new Boy
s: Skier = Boy@101afe

scala> val g = new Girl
g: Girl = Girl@cf63bb

scala> s.share(g)
<console>:10: error: type mismatch;
 found   : Girl
 required: s.SuitableRoommate
       s.share(g)
               ^

> So, the idea of putting the share() function in the base
> class must be so that Boy and Girl can be treated
> polymorphically from the perspective of the share() method
> at some point, surely? otherwise, why wouldn't you just
> omit it from the Skier base and just place share(Girl) on
> the Girl class and vice versa?
>
Yes, that's the point. Share is still in there on the base class.

> And if Boy and Girl are no longer substitutable for Skier,
> then haven't we lost something major?
>
> Alternatively, i'm not understanding how Scala handles
> this.
>
Scala has something called path-dependent types, which means the actual type depends on the path you take to get to it. It highlights that objects actually do have members that are types. The type error is that they got a Girl where an s.SuitableRoommate was needed. The Scala compiler somehow keeps track that the object referenced by s, its type member is a Boy. So when you try to pass a Girl in there, you get the type error.

> > What I think Meyer means when talking about reality is
> > that you want to actually model that two kinds of
> Skiers
> > are Boys and Girls, and that Skiers can share rooms,
> but
> > only Boys can share with other Boys, and Girls with
> other
> > Girls.
>
> The way I read it, he says what he means by that in the
> text you have quoted: "contravariance is of essentially no
> practical use."
>
Yes, I'm sure he meant that too. Remember this was 1997. What contravariance doesn't help you do is keep Girls and Boys in separate rooms. That was the practical benefit he saw in allowing covariant method parameters. What contravariance does do is exactly express the nature of overridden method parameters. It makes the types sound, which has some practical benefit I'd say. As Martin pointed out, once you have functions being passed around, it is handy that function parameter types are contravariant. Meyer may not have had that use case in mind back then.

But my main point with the skier post is that there are alternative ways to get at the benefit Meyer seemed to be after when he compromised and made the parameter types covariant even though their true nature was contravariant. It's also about as simple conceptually.

> > I assume Map takes 2, List 1, and Func a return type
> plus 0 to many parameter types.
>
> That is correct - each one uses a custom syntax. For
> example Fan's List parametrization looks like the Java
> array syntax. Because generics are used with only
> built-in types, it allows Fan to easily maintain the
> parametrization at runtime for reflection. For example
> given a list of Str, the type signature would be Str[],
> and you could reflect this type from the list at runtime.
> That becomes important for meta-programming and
> d serialization.
>
Is List mutable or immutable? Sorry I can't seem to find something like a FanDoc on the website. Is there a URL of something like the Java API JavaDoc? The reason I ask is that this looks like the syntax for Java's arrays. So I'm curious if it is implemented using Arrays underneath, and if not, how do I use Java arrays in Fan? (Like if I have to pass an array to a pre-existing Java method.)

> > First, are these type parameters on Map, List, and Func
> treated as nonvariant, covariant, contravariant? Or some
> combination? I see no mention of variance in their
> documentation.
>
> Technically they are covariant similar to Java arrays
> (although from the setter method perspective that allows
> contravariance). But it is sort of moot issue in Fan.
> Fan is mostly statically typed, however the compiler only
> y flags type errors which are guaranteed to be never be
> correct - for example passing a Str where an Int is
> expected. However any type check which could pass at
> runtime will generate a synthetic cast to keep the JVM/CLR
> happy. For example passing a Num where an Int is expected
> doesn't require an explicit cast.
>
Can you give an example of a "type check which could pass at runtime that generates a synthetic cast?

> It seems sort of crazy, but it turns out to be a great
> compromise. Almost all type errors still end up getting
> caught at compile time, we get Java-like performance, yet
> it avoids all the nasty syntax that clutters up Java code.
> So Fan's philosophy has been to use the type system as a
> a useful tool whenever it makes sense, but break out of it
> whenever it gets into the way.
>
> > Also, what do people usually do when they want to make
> some other collection besides List or Map? Do they cast,
> or perhaps use the -> to invoke mehods dynamically on
> objects pulled out of collections?
>
> I actually have seen it done very much - most all the code
> I've seen just uses the built-in types. But you would
> basically design it to work with Obj just like the
> pre-generics Java collections. The difference is you
> don't actually do the casting (it gets done for you).
> Although I use -> for duck typing things myself too.
>
Ah, you do a kind of cast inference on the Obj type. I see that now in the docs. That's interesting.

> There's a big difference between a physical law that has
> been confirmed innumerable times and the recommendations
> of computer scientists to programmers.
>
You mean, logic is a recommendation by computer scientists to programmers?

> "It's disgusting"? That's a bit over the top, don't you
> think?
>
Frankly I have to side with James there. These discussions of academic vs practical are silly and annoying (and particularly funny in the context of Scala, since people seem to just disregard who's behind the language and what their practical credentials are).

We are doing ourselves a disservice as a field with these allusions. Engineering is defined as the application of science to a technical problem. If we feel it's cool to disregard or doubt science in computing we put ourselves on the same level as simple technicians, and we should not complain if we will in the future be paid on this level.