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

我真的很想找出差异所在，并且更一般地说，是找出无法使用HLists的规范用例（或者，与常规列表相比不会产生任何好处）。

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

我在下面的文字中标记了几个问题。可能实际上没有必要回答这些问题，它们更多的是指出我不清楚的事情，并在某些方向上指导讨论。

动机

我最近在SO上看到了几个答案，人们建议使用HLists（例如，由Shapeless提供），包括对此问题的删除答案。这引起了讨论，从而引发了这个问题。

介绍

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

HList与元组

如果是这样，即您静态地知道数字和类型- 问题2：为什么不只使用n元组呢？当然，您可以安全地在HList上进行类型映射和折叠（也可以但不能进行安全地在HList上进行类型化productIterator），但是由于元素的数量和类型是静态已知的，因此您可以访问元组元素直接执行操作。

另一方面，如果f您在hlist上映射的函数是如此通用，以至于它接受所有元素- 问题3：为什么不通过productIterator.map？好的，方法重载可能是一个有趣的区别：如果我们有几个重载f的方法，则由hlist提供的更强的类型信息（与productIterator相比）可以使编译器选择更具体的f。但是，由于方法和函数不同，我不确定在Scala中是否真的可以使用。

H列表和用户输入

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

解决一到三个问题：主要应用之一HLists是对Arity的抽象。通常在抽象的任何给定使用位置都静态地知道Arity，但是每个站点之间都不同。从shapeless的示例中得出这一点，

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不可能有一个单一的实现来接受这两种截然不同的形状的参数并以类型安全的方式对其进行转换。

涉及固定arary的任何地方都可能对基于arity的抽象能力感兴趣：以及如上所述的元组，其中包括方法/函数参数列表和案例类。请参阅此处的示例，了解我们如何抽象任意案例类的多样性以几乎自动获取类型类实例，

// 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上映射的函数是否是如此通用以至于它可以接受所有元素……为什么不通过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)

关于您的关于用户输入的问题四，有两种情况需要考虑。第一种情况是我们可以动态建立上下文，以确保获得已知的静态条件。在这种情况下，完全可以应用无形技术，但是很明显，附带条件是，如果在运行时未获得静态条件，则我们必须遵循替代方法。毫不奇怪，这意味着对动态条件敏感的方法必须产生可选的结果。这是一个使用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())

在其他情况下，我们可能并不关心给定列表的实际长度，除了它与某些其他列表的长度相同外。同样，这是无形的支持，既可以完全静态地支持，也可以在上述静态/动态混合环境中支持。有关扩展示例，请参见此处。

正如您所观察到的，确实所有这些机制都要求至少有条件地提供静态类型信息，并且似乎将这些技术排除在完全由外部提供的非类型化数据完全驱动的完全动态环境中不可用。但是随着支持运行时编译作为2.10中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_Borat对此有话要说，考虑到他对依赖类型的编程语言的明智评论；-)

需要明确的是，一个HList本质上不过是一堆Tuple2顶部略有不同的糖而已。

def hcons[A,B](head : A, tail : B) = (a,b)
def hnil = Unit

hcons("foo", hcons(3, hnil)) : (String, (Int, Unit))

因此，您的问题本质上是关于使用嵌套元组与平面元组之间的区别，但是两者是同构的，因此最后，除了可以使用库函数和可以使用哪种表示法的便利性之外，实际上没有任何区别。

元组有很多事情你做不到的：

• 编写通用的前置/追加功能
• 写一个反向函数
• 写一个concat函数
• ...

当然，您可以使用元组来完成所有这些操作，但一般情况下则不能。因此，使用HLists使您的代码更加干燥。

我可以用超级简单的语言解释一下：

元组与列表的命名并不重要。HList可以命名为HTuples。区别在于，在Scala + Haskell中，您可以使用元组来执行此操作（使用Scala语法）：

def append2[A,B,C](in: (A,B), v: C) : (A,B,C) = (in._1, in._2, v)

以获取正好是任何类型的两个元素的输入元组，追加第三个元素，并返回正好具有三个元素的全类型元组。但是，尽管这在类型上是完全通用的，但它必须显式指定输入/输出长度。

Haskell样式的HList允许您做的就是在长度上使此泛型成为通用，因此您可以追加到任何长度的元组/列表，然后获取完全静态类型化的元组/列表。此好处也适用于同类型的集合，您可以在其中将int附加到正好为n个int的列表中，并获取静态类型为具有正（n + 1）个int的列表，而无需显式指定n。