解决问题一到三： 的主要应用之一HLists是抽象超过数量。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就不可能有一个可以接受这两种非常不同形状的参数并以类型安全的方式转换它们的单一实现。
在涉及固定数量的任何地方都可能对抽象数量的能力感兴趣：以及元组，如上所述，包括方法/函数参数列表和案例类。有关我们如何抽象任意案例类的数量以几乎自动获得类型类实例的示例，请参见此处，
// 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这是一个使用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())
在其他情况下，我们可能不关心给定列表的实际长度，除了它与其他列表的长度相同。同样，这是无形支持的东西，无论是完全静态的，还是在上面的混合静态/动态环境中。有关扩展示例，请参见此处。
正如您所观察到的，所有这些机制确实需要静态类型信息，至少有条件地可用，这似乎将这些技术排除在完全由外部提供的无类型数据驱动的完全动态环境中。但是随着在 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对依赖类型编程语言的睿智评论，我确信他对此有话要说；-)