scala - HLists 只不过是一种复杂的元组编写方式吗？

Question

我真的很想找出差异在哪里，更一般地说，是找出不能使用 HLists 的规范用例(或者更确切地说，不会比常规列表产生任何好处)。
(我知道 Scala 中有 22 个(我相信)TupleN，而一个只需要一个 HList，但这不是我感兴趣的那种概念差异。)
我在下面的文字中标记了几个问题。实际上可能没有必要回答它们，它们更多是为了指出我不清楚的事情，并引导讨论朝着某些方向发展。
动机
我最近在 SO 上看到了几个答案，人们建议使用 HLists(例如，由 Shapeless 提供)，包括对 this question 的已删除答案.它引起了this discussion ，这反过来又引发了这个问题。
介绍
在我看来，只有当您静态地知道元素的数量及其精确类型时，hlist 才有用。这个数字实际上并不重要，但您似乎不太可能需要生成一个包含不同但静态精确已知类型的元素的列表，但您并不静态知道它们的数字。 问题一:你甚至可以写一个这样的例子吗，例如，在一个循环中？我的直觉是，拥有一个静态精确的 hlist 和一个静态未知数量的任意元素(相对于给定的类层次结构是任意的)是不兼容的。
HLists 与元组
如果这是真的，即您静态地知道数字和类型 - 问题二:为什么不只使用 n 元组？当然，您可以类型安全地映射和折叠 HList(您也可以，但 不是 类型安全地，在 productIterator 的帮助下对元组进行操作)，但由于元素的数量和类型是静态的知道您可能只是直接访问元组元素并执行操作。
另一方面，如果函数 f您在 hlist 上映射是如此通用，以至于它接受所有元素 - 问题3:为什么不通过 productIterator.map 使用它?好的，一个有趣的区别可能来自方法重载:如果我们有几个重载 f的，具有由 hlist 提供的更强类型信息(与 productIterator 相比)可以允许编译器选择更具体的 f .但是，我不确定这是否真的适用于 Scala，因为方法和函数并不相同。
HLists 和用户输入
基于相同的假设，即您需要静态知道元素的数量和类型 - 问题4:可以在元素依赖于任何类型的用户交互的情况下使用 hlist 吗？例如，想象用循环内的元素填充 hlist；从某处(UI、配置文件、actor 交互、网络)读取元素，直到满足特定条件。 hlist 的类型是什么？与接口(interface)规范 getElements: HList[...] 类似，它应该与静态未知长度的列表一起使用，并且允许系统中的组件 A 从组件 B 获取这样的任意元素列表。

Answer 1

解决问题一到三:HLists 的主要应用之一是抽象的。 Arity 通常在抽象的任何给定使用站点是静态已知的，但因站点而异。拿这个，来自 shapeless 的 examples ,

def flatten[T <: Product, L <: HList](t : T)
  (implicit hl : HListerAux[T, L], flatten : Flatten[L]) : flatten.Out =
    flatten(hl(t))

val t1 = (1, ((2, 3), 4))
val f1 = flatten(t1)     // Inferred type is Int :: Int :: Int :: Int :: HNil
val l1 = f1.toList       // Inferred type is List[Int]

val t2 = (23, ((true, 2.0, "foo"), "bar"), (13, false))
val f2 = flatten(t2)
val t2b = f2.tupled
// Inferred type of t2b is (Int, Boolean, Double, String, String, Int, Boolean)

不使用 HLists (或等效的东西)抽象出 flatten 的元组参数的数量不可能有一个单一的实现可以接受这两种非常不同形状的参数并以类型安全的方式转换它们。

在涉及固定数量的任何地方都可能对抽象数量的能力感兴趣:以及元组，如上所述，包括方法/函数参数列表和案例类。见 here有关我们如何抽象任意案例类以几乎自动获得类型类实例的示例，

// A pair of arbitrary case classes
case class Foo(i : Int, s : String)
case class Bar(b : Boolean, s : String, d : Double)

// Publish their `HListIso`'s
implicit def fooIso = Iso.hlist(Foo.apply _, Foo.unapply _)
implicit def barIso = Iso.hlist(Bar.apply _, Bar.unapply _)

// And now they're monoids ...

implicitly[Monoid[Foo]]
val f = Foo(13, "foo") |+| Foo(23, "bar")
assert(f == Foo(36, "foobar"))

implicitly[Monoid[Bar]]
val b = Bar(true, "foo", 1.0) |+| Bar(false, "bar", 3.0)
assert(b == Bar(true, "foobar", 4.0))

这里没有运行时迭代，但是有重复，使用 HLists (或等效结构)可以消除。当然，如果您对重复样板的容忍度很高，您可以通过为您关心的每个形状编写多个实现来获得相同的结果。

在问题三中，您问“...如果您在 hlist 上映射的函数 f 是如此通用以至于它接受所有元素...为什么不通过 productIterator.map 使用它？”。如果您在 HList 上映射的函数确实是 Any => T 的形式然后映射到 productIterator会很好地为您服务。但是 Any => T 形式的函数通常不是那么有趣(至少，除非它们在内部进行类型转换，否则它们不会)。 shapeless 提供了一种形式的多态函数值，它允许编译器以您怀疑的方式选择特定于类型的情况。例如，

// size is a function from values of arbitrary type to a 'size' which is
// defined via type specific cases
object size extends Poly1 {
  implicit def default[T] = at[T](t => 1)
  implicit def caseString = at[String](_.length)
  implicit def caseList[T] = at[List[T]](_.length)
}

scala> val l = 23 :: "foo" :: List('a', 'b') :: true :: HNil
l: Int :: String :: List[Char] :: Boolean :: HNil =
  23 :: foo :: List(a, b) :: true :: HNil

scala> (l map size).toList
res1: List[Int] = List(1, 3, 2, 1)

关于你的问题四，关于用户输入，有两种情况需要考虑。第一种情况是我们可以动态建立一个上下文，以保证获得已知的静态条件。在这些场景中，完全可以应用无形技术，但显然附带条件是，如果在运行时没有获得静态条件，那么我们必须遵循替代路径。不出所料，这意味着对动态条件敏感的方法必须产生可选的结果。这是一个使用 HList 的示例年代，

trait Fruit
case class Apple() extends Fruit
case class Pear() extends Fruit

type FFFF = Fruit :: Fruit :: Fruit :: Fruit :: HNil
type APAP = Apple :: Pear :: Apple :: Pear :: HNil

val a : Apple = Apple()
val p : Pear = Pear()

val l = List(a, p, a, p) // Inferred type is List[Fruit]

l的类型不捕获列表的长度或其元素的精确类型。然而，如果我们期望它有一个特定的形式(即，如果它应该符合一些已知的、固定的模式)，那么我们可以尝试建立这个事实并采取相应的行动，

scala> import Traversables._
import Traversables._

scala> val apap = l.toHList[Apple :: Pear :: Apple :: Pear :: HNil]
res0: Option[Apple :: Pear :: Apple :: Pear :: HNil] =
  Some(Apple() :: Pear() :: Apple() :: Pear() :: HNil)

scala> apap.map(_.tail.head)
res1: Option[Pear] = Some(Pear())

在其他情况下，我们可能不关心给定列表的实际长度，除了它与其他列表的长度相同。同样，这是无形支持的东西，无论是完全静态的，还是在上面的混合静态/动态环境中。见 here一个扩展的例子。

正如您所观察到的，所有这些机制确实需要静态类型信息，至少有条件地可用，这似乎将这些技术排除在完全由外部提供的无类型数据驱动的完全动态环境中。但是随着在 2.10 中作为 Scala 反射的一个组件支持运行时编译的出现，即使这不再是一个不可逾越的障碍……我们可以使用运行时编译来提供 lightweight staging 的形式并在运行时执行我们的静态类型以响应动态数据:摘自下面的前面...点击链接获取完整示例，

val t1 : (Any, Any) = (23, "foo") // Specific element types erased
val t2 : (Any, Any) = (true, 2.0) // Specific element types erased

// Type class instances selected on static type at runtime!
val c1 = stagedConsumeTuple(t1) // Uses intString instance
assert(c1 == "23foo")

val c2 = stagedConsumeTuple(t2) // Uses booleanDouble instance
assert(c2 == "+2.0")

我确定 @PLT_Borat鉴于他的 sage comments about dependently typed programming languages，对此我有话要说。 ;-)