Code to test with:
import scalaz.{Reader, Applicative}
class ReaderInstanceTest {
type IntReader[A] = Reader[Int, A]
val a = Applicative[({type l[A] = Reader[Int, A]})#l] // fine
val b = Applicative[IntReader]
// ^ ambigous implicit values
// both method kleisliMonadReader ..
// and method kleisliIdMonadReader ..
}
Is this related to Scala's higher-order unification for type constructor inference ticket? If so (and even if not), could you describe what happens here in the a and b cases?
Do you have guidelines about when to use type lambda and when to use a type alias so that everything works out on the long run without unexpected errors?
Yes, this is related to SI-2712.
kleisliIdMonadReader
exists solely to guide type inference; it just forwards tokleisliMonadReader
. By providing the type aliasIntReader
, scalac doesn't need this assistance, and can infer the type arguments forkleisliMonadReader
directly. This leads to the ambiguity.I've just committed a remedy: we can prioritize these implicits relative to each other, by defining one in a subclass.
https://github.com/scalaz/scalaz/commit/6f9ae5f