HL主义者只不过是一种复杂的写作方式而已?

我真的有兴趣找出差异在哪里,更一般地说,是要确定不能使用HList的规范用例(或者说,不会比常规列表产生任何好处)。

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

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

动机

我最近在SO上看到了一些关于人们build议使用HList(例如, Shapeless提供的)的答案,包括删除了这个问题的答案。 这引起了这个讨论 ,这又引发了这个问题。

介绍

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

HLists与元组

如果这是真的,也就是说,你静静地知道数字和types – 问题2:为什么不使用一个n-元组? 当然,你可以types化地映射和折叠一个HList(你也可以,但不能types化,在productIterator的帮助下通过一个元组来完成),但是因为元素的数量和types是静态的,所以你可能只需要访问元组元素直接执行操作。

另一方面,如果你在hlist上映射的函数是通用的,它接受所有的元素 – 问题3:为什么不通过productIterator.map使用它? 好的,一个有趣的差异可能来自方法重载:如果我们有几个重载的f ,具有由hlist提供的更强types信息(与productIterator相比)可以允许编译器select更具体的f 。 但是,我不确定这是否会在Scala中起作用,因为方法和函数是不一样的。

HLists和用户input

基于相同的假设,即你需要静态地知道元素的数量和types – 问题4:在元素依赖于任何types的用户交互的情况下,能否使用它? 例如,想象用循环内的元素填充一个hlist; 元素是从某处(UI,configuration文件,演员互动,networking)读取,直到某个条件成立。 什么样的Hlist是什么? 类似于接口规范getElements:HList,它应该与静态未知长度的列表一起工作,并且允许系统中的组件A从组件B获得这样的任意元素的列表。

    解决一到三个问题: HLists的主要应用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 (或类似的东西)来抽象元组参数的HLists以使其flatten ,将不可能有一个单独的实现可以接受这两种截然不同的forms的参数,并以types安全的方式进行转换。

    在arity上进行抽象的能力很可能在涉及固定的arvals的地方引起兴趣,以及如上所述的包括方法/函数参数列表和case类的元组。 在这里看到的例子,我们可以几乎自动抽象任意案例类的arity来获取types的实例,

     // 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 (或等效结构)可以消除。 当然,如果你对重复样板的容忍度很高,你可以通过为你关心的每一个形状书写多个实现来得到相同的结果。

    在问题三中,你问“如果函数f映射到一个hlist是通用的,它接受所有的元素…为什么不通过productIterator.map?”。 如果您在HList上映射的函数的确是Any => T的forms,那么通过productIterator进行映射将非常好地为您服务。 但是, Any => Tforms的函数通常不是那么有趣(至less它们不是除非在内部input)。 shapeless提供了一种多态函数值的forms,它允许编译器按照您所怀疑的方式select特定于types的案例。 例如,

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

    关于您的问题四,关于用户input,有两种情况需要考虑。 首先是我们可以dynamic地build立一个保证已知静态条件获得的上下文的情况。 在这种情况下,应用无形技术是完全可能的,但显而易见的是,如果在运行时没有获得静态条件,那么我们必须遵循替代path。 不出所料,这意味着对dynamic条件敏感的方法必须得到可选的结果。 这是一个使用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的types不会捕获列表的长度或其元素的精确types。 但是,如果我们期望它有一个特定的forms(即它是否应该符合一些已知的,固定的模式),那么我们可以试图确定这个事实并采取相应的行动,

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

    在其他情况下,我们可能不关心给定列表的实际长度,除了与其他列表的长度相同。 再次,这是无形的支持,既是完全静态的,也是如上所述的混合静态/dynamic的环境。 在这里看到一个扩展的例子。

    如您所见,所有这些机制都要求至less有条件地提供静态types信息,这似乎排除了这些技术在完全dynamic的环境中可用,完全由外部提供的非types化数据驱动。 但是随着对运行时编译的支持作为2.10中Scalareflection的一个组件的出现,即使这不再是一个不可克服的障碍……我们可以使用运行时编译来提供一种轻量级登台的forms,并且在运行时在响应dynamic数据:从以下的前面摘录…按照完整的例子的链接,

     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会有些话要说,因为他的圣人意见关于依赖types的编程语言 😉

    要清楚的是,一个HList基本上只是一堆Tuple2 ,在顶部稍微有点不同。

     def hcons[A,B](head : A, tail : B) = (a,b) def hnil = Unit hcons("foo", hcons(3, hnil)) : (String, (Int, Unit)) 

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

    有很多事情你不能用元组来做:

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

    你当然可以用元组来做所有的事情,但不是在一般情况下。 所以使用HLists会使您的代码更干。

    我可以用超简单的语言来解释这一点:

    元组vs列表命名不重要。 HLists可以被命名为HTuples。 不同的是,在Scala + Haskell中,你可以用元组(使用Scala语法)做到这一点:

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

    接收任何types的两个元素的input元组,附加第三个元素,并返回一个完全types的元组,正好有三个元素。 但是,虽然这是完全通用的types,它必须明确指定input/输出长度。

    Haskell风格的HList可以让你做这个generics,所以你可以附加到任何长度的元组/列表,并获得一个完全静态types的元组/列表。 这个好处也适用于同types的集合,你可以将一个int附加到一个完全n个整数的列表中,并返回一个静态types的列表,而不需要显式地指定n,就可以精确地具有(n + 1)个整数。