【问题标题】:When are dependent types needed in Shapeless?Shapeless 什么时候需要依赖类型?
【发布时间】:2018-12-10 09:07:30
【问题描述】:

据我了解,依赖类型允许您不指定输出类型:

例如,如果你有一个类型类:

trait Last[In] {
  type Out
}

然后你可以在不指定输出类型的情况下召唤一个实例:

implicitly(Last[String :: Int :: HNil]) // output type calculated as Int

并且辅助模式允许您再次指定输出类型:

implicitly(Last.Aux[String :: Int :: HNil, Int])

为了对输出类型 (to work around a Scala limitation on dependent types) 做一些有用的事情,您需要在隐式参数列表中使用它。

但是,如果您总是需要指定(或分配类型参数)输出类型,为什么还要首先使用依赖类型(然后是 Aux)?

我尝试从 Shapeless 的 src 复制 Last 类型类,将 type Out 替换为特征中的附加类型参数并删除 Aux。它仍然有效。

我真正需要它们的情况是什么?

【问题讨论】:

标签: scala shapeless dependent-type


【解决方案1】:

我知道Sum[A, B]Sum[A, B] { type Out = C } 不同,或者 Sum.Aux[A, B, C]。我在问为什么我需要输入 Out 而不是 只是Sum[A, B, C]

区别在于部分应用。对于trait MyTrait { type A; type B; type C },您可以指定一些类型而不指定其他类型(期望编译器推断它们)。但是对于trait MyTrait[A, B, C],您只能指定所有这些或不指定其中任何一个。 对于Sum[A, B] { type Out },您更愿意指定AB 而不是指定Out(期望编译器根据作用域中存在的隐式推断其值)。同样对于trait Last[In] { type Out },您更愿意指定In,而不是指定Out(期望编译器推断其值)。 所以类型参数更像输入,类型成员更像输出。

https://www.youtube.com/watch?v=R8GksuRw3VI

Abstract types versus type parameters 和相关问题


但究竟什么时候,我更愿意指定In 而不是指定Out

让我们考虑以下示例。这是一个用于添加自然数的类型类:

sealed trait Nat
case object Zero extends Nat
type Zero = Zero.type
case class Succ[N <: Nat](n: N) extends Nat

type One = Succ[Zero]
type Two = Succ[One]
type Three = Succ[Two]
type Four = Succ[Three]
type Five = Succ[Four]

val one: One = Succ(Zero)
val two: Two = Succ(one)
val three: Three = Succ(two)
val four: Four = Succ(three)
val five: Five = Succ(four)

trait Add[N <: Nat, M <: Nat] {
  type Out <: Nat
  def apply(n: N, m: M): Out
}

object Add {
  type Aux[N <: Nat, M <: Nat, Out0 <: Nat] = Add[N, M] { type Out = Out0 }
  def instance[N <: Nat, M <: Nat, Out0 <: Nat](f: (N, M) => Out0): Aux[N, M, Out0] = new Add[N, M] {
    override type Out = Out0
    override def apply(n: N, m: M): Out = f(n, m)
  }

  implicit def zeroAdd[M <: Nat]: Aux[Zero, M, M] = instance((_, m) => m)
  implicit def succAdd[N <: Nat, M <: Nat, N_addM <: Nat](implicit add: Aux[N, M, N_addM]): Aux[Succ[N], M, Succ[N_addM]] =
    instance((succN, m) => Succ(add(succN.n, m)))
}

这个类型类在类型级别上都起作用

implicitly[Add.Aux[Two, Three, Five]]

和价值水平

println(implicitly[Add[Two, Three]].apply(two, three))//Succ(Succ(Succ(Succ(Succ(Zero)))))
assert(implicitly[Add[Two, Three]].apply(two, three) == five)//ok

现在让我们用类型参数而不是类型成员重写它:

trait Add[N <: Nat, M <: Nat, Out <: Nat] {
  def apply(n: N, m: M): Out
}

object Add {
  implicit def zeroAdd[M <: Nat]: Add[Zero, M, M] = (_, m) => m
  implicit def succAdd[N <: Nat, M <: Nat, N_addM <: Nat](implicit add: Add[N, M, N_addM]): Add[Succ[N], M, Succ[N_addM]] =
    (succN, m) => Succ(add(succN.n, m))
}

在类型级别上它的工作方式类似

implicitly[Add[Two, Three, Five]]

但是现在在值级别上,您必须指定类型 Five,而在前一种情况下,它是由编译器推断的。

println(implicitly[Add[Two, Three, Five]].apply(two, three))//Succ(Succ(Succ(Succ(Succ(Zero)))))
assert(implicitly[Add[Two, Three, Five]].apply(two, three) == five)//ok

所以区别在于部分应用。


但是如果你像往常一样添加+ 语法糖 实用的(shapeless 也适用于所有事情),依赖类型 好像没关系

语法并不总是有帮助。例如,让我们考虑一个类型类,它接受一个类型(但不接受此类型的值)并生成此类型的类型和值:

trait MyTrait {
  type T
}

object Object1 extends MyTrait
object Object2 extends MyTrait

trait TypeClass[In] {
  type Out
  def apply(): Out
}

object TypeClass {
  type Aux[In, Out0] = TypeClass[In] { type Out = Out0 }
  def instance[In, Out0](x: Out0): Aux[In, Out0] = new TypeClass[In] {
    override type Out = Out0
    override def apply(): Out = x
  }

  def apply[In](implicit tc: TypeClass[In]): Aux[In, tc.Out] = tc

  implicit val makeInstance1: Aux[Object1.T, Int] = instance(1)
  implicit val makeInstance2: Aux[Object2.T, String] = instance("a")
}

println(TypeClass[Object1.T].apply())//1
println(TypeClass[Object2.T].apply())//a

但是如果我们将Out 设置为类型参数,那么在调用时我们将不得不指定Out,并且无法定义扩展方法并从元素类型推断类型参数In,因为没有类型Object1.TObject2.T

【讨论】:

  • 但究竟什么时候,我更愿意指定In 而不是指定Out?如果你检查我的问题的开头,我就会明白你在说什么。困扰我的是,每次我想对Out 做一些有用的事情时,我都会通过Aux 获得对它的引用,然后我没有 更喜欢“不指定它”。例如:def doSomething[A,B, Result](implicit sum: Sum.Aux[A,B,Result], somethingDone: MakeUseOfIt[Result]) = ???
  • 公平点,我高兴了一分钟。但是,如果您像往常一样添加+ 语法糖以使其实用(shapeless 也适用于所有事情),依赖类型似乎并不重要:``` 隐式类 AddOps[A <: nat nat: a def c b add: add other>one + two 仍然在值级别上工作,我不需要知道C,编译器会为我找到它。
  • 是的,我不能打破你的最后一个例子。您链接的视频也有帮助:“类型参数与成员是做同样事情的替代方法,有些事情用一种或另一种更容易完成”。谢谢 Dmytro。
猜你喜欢
  • 1970-01-01
  • 2017-12-15
  • 2015-01-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-11-03
  • 2019-03-01
  • 2012-09-16
相关资源
最近更新 更多