2

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?

paradigmatic
  • 40,153
  • 18
  • 88
  • 147
ron
  • 9,262
  • 4
  • 40
  • 73
  • Thanks for reporting, I need to rearrange the implicits in `KleisliInstances` to get scalac to pick one, rather than report the ambiguity error. (I had thought that all the bases were covered by this test: https://github.com/scalaz/scalaz/blob/scalaz-seven/tests/src/test/scala/scalaz/KleisliTest.scala#L38) – retronym Aug 11 '12 at 08:40

1 Answers1

4

Yes, this is related to SI-2712.

kleisliIdMonadReader exists solely to guide type inference; it just forwards to kleisliMonadReader. By providing the type alias IntReader, scalac doesn't need this assistance, and can infer the type arguments for kleisliMonadReader 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

retronym
  • 54,768
  • 12
  • 155
  • 168