Scalaz 7 - 为什么使用类型别名会导致 Reader 的类型类解析不明确 [英] Scalaz 7 - why using type alias results in ambigous typeclass resolution for Reader

问题描述

测试代码:

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 ..
}

这是否与 Scala 的 高阶统一类型构造函数推理相关 票证?如果是(即使不是)，您能否描述一下在 a 和 b 情况下会发生什么?

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?

您是否有关于何时使用类型 lambda 以及何时使用类型别名的指导方针，以便从长远来看一切正常而不会出现意外错误?

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?

推荐答案

是的，这与 SI-2712 相关.

Yes, this is related to SI-2712.

kleisliIdMonadReader 仅用于指导类型推断；它只是转发到 kleisliMonadReader.通过提供类型别名 IntReader，scalac 不需要这种帮助，可以直接推断 kleisliMonadReader 的类型参数.这导致了歧义.

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

这篇关于Scalaz 7 - 为什么使用类型别名会导致 Reader 的类型类解析不明确的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！