HLists 仅仅是一种编写元组的复杂方式吗？

我真正感兴趣的是找出差异在哪里，更一般地说，是确定不能使用 HList 的规范用例(或者更确切地说，与常规列表相比没有任何好处)。

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

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

动机

我最近看到一些关于 SO 的答案，其中有人建议使用 HList (例如，由 没有形状提供) ，包括一个已删除的 这个问题答案。它产生了 这个讨论，从而引发了这个问题。

介绍

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

HLists 与 Tuple

如果这是真的，例如，您静态地知道数字和类型-问题2:，为什么不使用 n 元组？当然，你可以类型安全地映射和折叠一个 HList (你也可以，但是 没有类型安全地，在 productIterator的帮助下做一个元组) ，但是因为元素的数量和类型是静态知道的，所以你可以直接访问元素的元素并执行操作。

另一方面，如果映射到 hlist 上的函数 f非常通用，它可以接受所有元素-问题3:，为什么不通过 productIterator.map使用它呢？好的，一个有趣的区别可能来自于方法重载: 如果我们有几个重载的 f，那么 hlist 提供的更强的类型信息(与 productIterator 相反)可以允许编译器选择一个更具体的 f。但是，我不确定这在 Scala 中是否真的可行，因为方法和函数是不一样的。

HLists 和用户输入

建立在同样的假设之上，也就是说，你需要静态地知道元素的数量和类型-问题4:可以在元素依赖于任何类型的用户交互的情况下使用 hlist 吗？例如，假设在一个循环中用元素填充一个 hlist; 从某个地方(UI、配置文件、参与者交互、网络)读取元素，直到满足某个条件。名单的类型是什么？类似于接口规范 getElements: HList [ ... ] ，它应该处理静态未知长度的列表，并允许系统中的组件 A 从组件 B 获取任意元素的列表。

18939 次浏览
小开

有很多事情你不能(很好地)使用元组:

  • 编写一个通用的 prepend/append 函数
  • 写一个反向函数
  • 写一个 concat 函数
  • ...

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

小开
最佳答案

解决一到三个问题: HLists的主要应用程序之一是抽象超越简单性。Arity 通常在任何给定的抽象使用站点上是静态的，但是在不同的站点上有所不同。拿着这个，来自无形的 例子,

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的特性，就不可能有一个单独的实现来接受这两个非常不同形状的参数并以类型安全的方式转换它们。

无论在哪里，只要涉及到固定的实体，就可能对超越实体的抽象能力感兴趣: 还有元组，如上所述，包括方法/函数参数列表和 case 类。请参阅 给你，了解我们如何抽象任意大小写类的特性，以几乎自动地获得类型类实例,

// 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的函数通常不那么有趣(至少，除非它们在内部输入 cast，否则就不那么有趣)。Shapless 提供了一种多态函数值的形式，它允许编译器按照您怀疑的方式选择特定于类型的情况。比如说,

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

在其他情况下，我们可能不关心给定列表的实际长度，除了它与其他列表的长度相同。同样，这是无形支持的东西，既可以是完全静态的，也可以像上面那样在混合的静态/动态上下文中支持。有关扩展示例，请参见 给你。

正如您所观察到的，所有这些机制都需要静态类型信息可用，至少是有条件地可用，这似乎排除了这些技术在完全由外部提供的非类型数据驱动的动态环境中可用的可能性。但是随着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")

考虑到他的 关于依赖类型编程语言的 Sage 注释，我相信 @ 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))

所以你的问题本质上是关于使用嵌套元组和使用扁平元组之间的区别，但是这两者是同构的，所以最终除了使用库函数和使用符号的方便之外，真的没有区别。

小开

我可以用超级简单的语言来解释:

元组与列表命名并不重要。HLists 可以命名为 HTuple。不同之处在于，在 Scala + Haskell 中，可以使用 tuple (使用 Scala 语法)完成这项工作:

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

要获取任何类型的正好两个元素的输入元组，请附加第三个元素，然后返回一个正好包含三个元素的完整类型元组。但是，虽然这是完全泛型的类型，但是它必须显式地指定输入/输出长度。

Haskell 样式的 HList 允许您做的是使这个泛型超过长度，这样您就可以追加到任意长度的 tuple/list 并返回一个完全静态类型的 tuple/list。这个优点也适用于同类型集合，在这种集合中，您可以将一个 int 附加到正好为 n 的列表中，并返回一个静态类型为正好(n + 1) int 的列表，而无需显式指定 n。


提交答案