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

我真的很想找出差异所在，更一般地说，是为了识别不能使用 HList 的规范用例（或者更确切地说，与常规列表相比不会产生任何好处）。

（我知道有 22 个（我相信）TupleN在 Scala 中，而只需要一个 HList，但这不是我感兴趣的概念差异。）

我在下面的文字中标记了几个问题。其实可能没有必要回答，更多的是指出我不清楚的地方，并引导讨论到一定的方向。

动机

我最近看到了一些关于 SO 的答案，人们建议使用 HLists （例如，由无形的 https://github.com/milessabin/shapeless），包括删除的答案这个问题 https://stackoverflow.com/questions/11815908/valid-type-casting-of-both-covariant-and-contravariant-class-at-runtime-in-scala。它引发了这次讨论 https://chat.stackoverflow.com/rooms/14938/discussion-between-mhs-and-edmondo1984，这又引发了这个问题。

Intro

在我看来，只有当您静态地知道元素的数量及其精确类型时，hlist 才有用。该数量实际上并不重要，但您似乎不太可能需要生成一个包含不同但静态精确已知类型的元素的列表，但您并不静态地知道它们的数量。问题一：你甚至可以写一个这样的例子，例如，在循环中吗？我的直觉是，拥有一个静态精确的 hlist 和静态未知数量的任意元素（相对于给定的类层次结构任意）是不兼容的。

HList 与元组

如果这是真的，即您静态地知道数字和类型 -问题2：为什么不直接使用 n 元组呢？当然，您可以安全地映射和折叠 HList（您也可以，但是not类型安全地，在以下命令的帮助下修改元组productIterator），但由于元素的数量和类型是静态已知的，您可能可以直接访问元组元素并执行操作。

另一方面，如果函数f您映射的 hlist 非常通用，它接受所有元素 -问题3：为什么不通过使用它productIterator.map？好吧，一个有趣的区别可能来自方法重载：如果我们有几个重载f的，拥有 hlist 提供的更强大的类型信息（与 ProductIterator 相比）可以允许编译器选择更具体的f。然而，我不确定这在 Scala 中是否真的有效，因为方法和函数不一样。

HList 和用户输入

基于相同的假设，即您需要静态地了解元素的数量和类型 -问题4：hlists 可以用在元素依赖于任何类型的用户交互的情况下吗？例如，想象一下用循环内的元素填充 hlist；从某个地方（UI、配置文件、参与者交互、网络）读取元素，直到满足某个条件。 hlist 的类型是什么？与接口规范 getElements: HList[...] 类似，它应该与静态未知长度的列表一起使用，并且允许系统中的组件 A 从组件 B 获取这样的任意元素列表。

解决问题一到三：主要应用之一HLists对数量进行抽象。数量通常在抽象的任何给定使用站点上都是静态已知的，但因站点而异。拿这个，来自无形的examples https://github.com/milessabin/shapeless/blob/master/examples/src/main/scala/shapeless/examples/flatten.scala#L70,

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 https://github.com/milessabin/shapeless/blob/master/examples/src/main/scala/shapeless/examples/monoids.scala例如，我们如何抽象任意案例类的数量以几乎自动获取类型类实例，

// 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)

关于您的问题四，关于用户输入，有两种情况需要考虑。第一种情况是我们可以动态地建立一个上下文来保证获得已知的静态条件。在这些类型的场景中，完全有可能应用无形技术，但显然前提是如果静态条件doesn't在运行时获取然后我们必须遵循替代路径。毫不奇怪，这意味着对动态条件敏感的方法必须产生可选的结果。这是一个使用的示例HLists,

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())

在其他情况下，我们可能不关心给定列表的实际长度，除了它与其他列表的长度相同之外。同样，这是 Shapeless 支持的东西，既可以完全静态地支持，也可以在如上所述的混合静态/动态上下文中支持。看here https://github.com/milessabin/shapeless/blob/master/examples/src/main/scala/shapeless/examples/sized.scala一个扩展的例子。

正如您所观察到的，所有这些机制确实都需要静态类型信息可用，至少有条件地可用，并且这似乎排除了这些技术在完全动态环境中的使用，完全由外部提供的非类型化数据驱动。但随着 2.10 中支持运行时编译作为 Scala 反射的一个组件，即使这也不再是一个不可克服的障碍……我们可以使用运行时编译来提供一种形式轻量级舞台 https://github.com/milessabin/shapeless/blob/master/examples/src/main/scala/shapeless/examples/staging.scala并在运行时执行静态类型以响应动态数据：摘录自下面的内容...请点击链接查看完整示例，

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_波拉特 https://twitter.com/PLT_Borat鉴于他的关于依赖类型编程语言的圣人评论 https://twitter.com/PLT_Borat/status/163966991877685249 ;-)