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

Question

我真的很想知道差异在哪里,更一般地说,找出不能使用HLists的规范用例(或者说,不会比常规列表产生任何好处).

(我知道TupleNScala 中有22个(我相信),而一个只需要一个HList,但这不是我感兴趣的那种概念差异.)

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

动机

我最近在SO上看到了几个人们建议使用HLists的答案(例如,由Shapeless提供),包括对这个问题的删除答案.它引发了这一讨论,从而引发了这个问题.

介绍

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

HLists与Tuples

如果这是真的,即你静态地知道数字和类型 - 问题2:为什么不使用n元组？当然,你可以类型安全地映射和折叠一个HList(你也可以,但不是类型安全地,借助于一个元组productIterator),但由于元素的数量和类型是静态已知的,你可能只是访问元组元素直接执行操作.

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

HLists和用户输入

基于相同的假设,即您需要静态地知道元素的数量和类型 - 问题4:可以在元素依赖于任何类型的用户交互的情况下使用hlists吗？例如,想象用循环内的元素填充hlist; 从某个地方(UI,配置文件,演员交互,网络)读取元素,直到某个条件成立.什么类型的hlist是什么？类似于接口规范getElements:HList [...]应该使用静态未知长度的列表,并允许系统中的组件A从组件B获得这样的任意元素列表.

Answer 1

解决第一到第三个问题:其中一个主要应用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(或类似的东西)来抽象元组参数的arity flatten就不可能有一个单独的实现可以接受这两个非常不同的形状的参数并以类型安全的方式转换它们.

在涉及固定元素的任何地方,抽象over arity的能力可能是有意义的:以及如上所述的元组,包括方法/函数参数列表和案例类.请参阅此处,了解我们如何抽象任意案例类的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会对此有所说明,因为他的评论是关于依赖类型的编程语言 ;-)

Answer 2

需要明确的是,HList实际上只不过是一堆Tuple2顶部略有不同的糖.

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

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

所以你的问题基本上是关于使用嵌套元组和扁平元组之间的区别,但是这两者是同构的,所以最后除了可以使用库函数的方便性以及可以使用哪种符号之外,确实没有区别.

Answer 3

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

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

当然,您可以使用元组完成所有这些操作,但在一般情况下则不行.因此,使用HLists会使您的代码更加干燥.

Answer 4

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

元组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.