我真的很想知道差异在哪里，更一般地说，找出不能使用HLists的规范用例（或者说，不会比常规列表产生任何好处）。
（我知道Scala中有22个（我相信）TupleN，而一个只需要一个HList，但这并不是我感兴趣的概念差异。）
我在下面的文字中标出了几个问题。实际上可能没有必要回答它们，它们更倾向于指出我不清楚的事情，并指导某些方向的讨论。
我最近在SO上看到了几个人们建议使用HLists的答案（例如，Shapeless提供的），包括删除的this question答案。它产生this discussion，这反过来引发了这个问题。
在我看来，只有当您静态地知道元素的数量及其精确类型时，才会使用hlists。这个数字实际上并不重要，但是你似乎不太可能需要生成一个包含不同但静态精确已知类型的元素的列表，但是你并不静态地知道它们的数量。 问题1：您是否可以编写这样的示例，例如，在循环中？我的直觉是，拥有一个静态精确的hlist，其中包含一个静态未知数量的任意元素（相对于给定的类层次结构的任意元素），这是不兼容的。
如果这是真的，即您静态地知道数字和类型 - 问题2：为什么不使用n元组？当然，你可以安全地映射和折叠一个HList（你也可以，但不类型安全，在productIterator的帮助下完成一个元组），但是因为它的数量和类型元素是静态知道的，您可以直接访问元组元素并执行操作。
另一方面，如果您在hlist上映射的函数f如此通用，以至于它接受所有元素 - 问题3：为什么不通过productIterator.map使用它？好的，一个有趣的区别可能来自方法重载：如果我们有几个重载的f，那么拥有hlist提供的更强的类型信息（与productIterator相反）可能允许编译器选择更具体的{ {1}}。但是，我不确定这是否真的可以在Scala中使用，因为方法和函数不一样。
基于相同的假设，即您需要静态地知道元素的数量和类型 - 问题4：可以在元素依赖于任何类型的用户交互的情况下使用hlists ？例如，想象用循环内的元素填充hlist;从某个地方（UI，配置文件，演员交互，网络）读取元素，直到某个条件成立。什么类型的hlist是什么？类似于接口规范getElements：HList [...]应该使用静态未知长度的列表，并允许系统中的组件A从组件B获得这样的任意元素列表。
答案 0 :(得分：138)
解决第一到第三个问题：HLists的一个主要应用是抽象而不是arity。 Arity通常在抽象的任何给定使用站点静态地知道，但是因站点而异。从无形的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的元组参数的arity，就不可能有一个单独的实现可以接受这两种截然不同的形状和以类型安全的方式转换它们。
在涉及固定元素的任何地方，抽象arity的能力可能是有意义的：以及如上所述的元组，包括方法/函数参数列表和案例类。有关如何抽象任意案例类的arity以几乎自动获取类型类实例的示例，请参阅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))
这里没有运行时迭代，但有 duplication ，使用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)
关于您的问题四，关于用户输入，有两种情况需要考虑。第一种情况是我们可以动态建立一个保证已知静态条件的上下文。在这些场景中，完全可以应用无形技术，但很明显，条件是如果静态条件不在运行时获得，那么我们必须遵循另一条路径。不出所料，这意味着对动态条件敏感的方法必须产生可选结果。以下是使用HList s，
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; - ）
答案 1 :(得分：17)
为了清楚起见，一个HList基本上只是一堆Tuple2，顶部的糖略有不同。
def hcons[A,B](head : A, tail : B) = (a,b)
def hnil = Unit
hcons("foo", hcons(3, hnil)) : (String, (Int, Unit))
所以你的问题基本上是关于使用嵌套元组和扁平元组之间的区别，但是这两个是同构的，所以最后除了可以使用库函数的方便性和可以使用哪种符号之外没有任何区别。 / p>
答案 2 :(得分：9)
你可以用元组做很多事情（
）当然，您可以使用元组完成所有这些操作，但在一般情况下则不行。因此，使用HLists会使您的代码更加干燥。
答案 3 :(得分：6)
我可以用超简单的语言解释这个：
元组vs列表命名并不重要。 HLists可以命名为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的情况下具有精确的（n + 1）个int。