Programming in Scala”

Chapter notes 14
like this will result in a compile error like "covariant type A occurs in contravariant position".
Scala must enforce that no such contradictions exist, or we could circumvent the type-checker and
easily write programs that gave a type error at runtime, in the form of a ClassCastException.
The more complicated signature fixes the contradiction by not mentioning A in any of the function
arguments:
def orElse[B >: A](o: Option[B]): Option[B]
Covariant and contravariant positions
A type is in covariant position (positive) if it is in the result type of a function, or more generally is
the type of a value that is produced.
A type is in contravariant position (negative) if it’s in the argument type of a function, or more
generally is the type of a value that is consumed.
For example, in def foo(a: A): B, the type A is in contravariant position and B is in covariant
position, all things being equal.
We can extend this reasoning to higher-order functions. In def foo(f: A => B): C, the type A => B
appears in negative (contravariant) position. This means the variance of the types A and B is flipped.
The type A appears in a negative position of a type in negative position. So just like the negation of
a negative is a positive, this means A is actually in covariant position. And since B is in the covariant
position of a type in contravariant position, it’s the negation of a positive, so B is in contravariant
position overall.
We can always count the position of a polymorphic type this way. Result types are positive, and
argument types are negative. The arguments to arguments are positive, arguments to arguments to
arguments are negative, and so on.
Notes on chapter 5: Strictness and laziness
Non-strictness vs laziness
The Haskell website⁵⁸ has a good explanation of the difference between non-strictness and laziness.
In short, “non-strict” just means “not strict”. There are many possible evaluation strategies⁵⁹ one
could employ when evaluating a program, and strict evaluation⁶⁰ is one of them. Non-strict
evaluation⁶¹ is a class of evaluation strategies, and lazy evaluation⁶² is one non-strict strategy (also
known as “call-by-need”).
⁵⁸http://www.haskell.org/haskellwiki/Lazy_vs._non-strict
⁵⁹http://en.wikipedia.org/wiki/Evaluation_strategy
⁶⁰http://en.wikipedia.org/wiki/Strict_evaluation
⁶¹http://en.wikipedia.org/wiki/Non-strict_evaluation#Non-strict_evaluation
⁶²http://en.wikipedia.org/wiki/Lazy_evaluation