我真的很想知道差异在哪里,更一般地说,找出不能使用HLists的规范用例(或者说,不会比常规列表产生任何好处) .
(我知道Scala中有22个(我相信) TupleN
,而一个只需要一个HList,但这不是我感兴趣的那种概念差异 . )
我在下面的文中标出了几个问题 . 实际上可能没有必要回答它们,它们更倾向于指出我不清楚的事情,并指导某些方向的讨论 .
动机
我最近在SO上看到了几个人们建议使用HLists的答案(例如,由Shapeless提供),包括this question的删除答案 . 它引起了this discussion,这反过来引发了这个问题 .
简介
在我看来,只有当您静态地知道元素的数量及其精确类型时,才会使用hlists . 这个数字实际上并不重要,但是你似乎不太可能需要生成一个包含不同但静态精确已知类型的元素的列表,但是你不能静态地知道它们的数量 . Question 1: 你甚至可以写一个这样的例子,例如,在循环中吗?我的直觉是,具有静态未知数量的任意元素(相对于给定类层次结构的任意元素)的静态精确hlist是不兼容的 .
HLists vs. Tuples
如果这是真的,即你静态地知道数字和类型 - Question 2: 为什么不只是使用n元组?当然,你可以安全地映射和折叠一个HList(你也可以,但 not 类型安全,在 productIterator
的帮助下完成一个元组),但由于元素的数量和类型是静态已知的,你可能只是访问元组元素直接执行操作 .
另一方面,如果您在hlist上映射的函数 f
是如此通用以至于它接受所有元素 - Question 3: 为什么不通过 productIterator.map
使用它?好的,一个有趣的区别可能来自方法重载:如果我们有几个重载的 f
,拥有hlist提供的更强的类型信息(与productIterator相反)可以允许编译器选择更具体的 f
. 但是,我不确定这在Scala中是否真的有用,因为方法和函数不一样 .
HLists和用户输入
基于相同的假设,即您需要静态地知道元素的数量和类型 - Question 4: 可以在元素依赖于任何类型的用户交互的情况下使用吗?例如,想象用循环内的元素填充hlist;从某个地方(UI,配置文件,演员交互,网络)读取元素,直到某个条件成立 . 什么类型的hlist是什么?类似于接口规范getElements:HList [...]应该使用静态未知长度的列表,并允许系统中的组件A从组件B获取这样的任意元素列表 .
4 回答
有很多东西你不能用元组做(好):
写一个通用的前置/后置函数
写一个反向函数
写一个concat函数
......
当然,您可以使用元组完成所有这些操作,但在一般情况下则不行 . 因此,使用HLists会使您的代码更加干燥 .
解决第一到第三个问题:
HLists
的一个主要应用是抽象而不是arity . Arity通常在抽象的任何给定使用站点上是静态已知的,但是因站点而异 . 从无形的examples拿下这个,不使用
HLists
(或类似的东西)来抽象flatten
的元组参数的arity,就不可能有一个单独的实现可以接受这两种截然不同的形状的参数并以类型安全的方式转换它们 .在涉及固定元素的任何地方,抽象arity的能力可能是有意义的:以及如上所述的元组,包括方法/函数参数列表和案例类 . 有关如何抽象任意案例类的arity以几乎自动获取类型类实例的示例,请参见here .
这里没有运行时迭代,但是存在重复,使用
HLists
(或等效结构)可以消除 . 当然,如果您对重复样板的容忍度很高,则可以通过为您关注的每个形状编写多个实现来获得相同的结果 .问题三,你问"... if the function f you map over an hlist is so generic that it accepts all elements ... why not use it via productIterator.map?" . 如果您在HList上映射的函数的格式为
Any => T
,则productIterator
上的映射将非常适合您 . 但是Any => T
形式的函数不是't typically that interesting (at least, they aren' t,除非它们在内部进行类型转换) . shapeless提供了一种多态函数值,允许编译器以您可疑的方式选择特定于类型的案例 . 例如,关于您的问题四,关于用户输入,有两种情况需要考虑 . 第一种情况是我们可以动态地 Build 一个保证已知静态条件的上下文获得 . 在这些场景中,完全可以应用无形技术,但很明显,条件是如果静态条件在运行时没有获得,那么我们必须遵循另一条路径 . 不出所料,这意味着对动态条件敏感的方法必须产生可选结果 . 这是一个使用
HList
的例子,l
的类型不捕获列表的长度或其元素的精确类型 . 但是,如果我们期望它具有特定形式(即,如果它应该符合某些已知的固定模式),那么我们可以尝试 Build 该事实并相应地采取行动,在其他情况下,我们可能不关心给定列表的实际长度,除了它与其他列表的长度相同 . 同样,这是完全静态的无形支持,也是如上所述的混合静态/动态上下文 . 有关扩展示例,请参见here .
诚然,正如您所观察到的那样,所有这些机制都需要静态类型信息,至少是有条件的,这似乎排除了这些技术可以在完全动态的环境中使用,完全由外部提供的无类型数据驱动 . 但随着运行时编译作为2.10中Scala反射的一个组件的支持的出现,即使这不再是一个不可克服的障碍......我们可以使用运行时编译来提供lightweight staging的形式,并在运行时执行我们的静态类型对动态数据的响应:摘自前面的内容...按照完整示例的链接,
鉴于他的sage comments about dependently typed programming languages ;-),我肯定@PLT_Borat会对此有所说明 .
为了清楚起见,HList基本上只是一堆
Tuple2
,顶部略有不同的糖 .所以你的问题主要是关于使用嵌套元组和扁平元组之间的区别,但两者是同构的,所以最后除了可以使用库函数的方便性和可以使用哪种符号之外没有区别 .
我可以用超简单的语言解释一下:
元组vs列表命名并不重要 . HLists可以命名为HTuples . 不同之处在于,在Scala Haskell中,您可以使用元组(使用Scala语法)执行此操作:
获取任何类型的两个元素的输入元组,附加第三个元素,并返回一个完全类型的元组,其中包含三个元素 . 但是虽然这对于类型是完全通用的,但它必须明确指定输入/输出长度 .
HList允许你做的Haskell样式是使这个泛型超长,所以你可以附加到任何长度的元组/列表并获得一个完全静态类型的元组/列表 . 此优点也适用于同类型集合,其中您可以将int附加到精确n个int的列表中,并返回一个静态类型的列表,以便在没有明确指定n的情况下具有精确(n 1)个int .