我读过一个地方,更高阶多态性不能在值类型为(如.NET)的类型系统中使用/实现。这是对的吗?为什么?更高阶的多态性+值类型
6
A
回答
6
问题与价值表示。
传统的高阶多态语言已经做出了简化的选择,即所有的值都以统一的方式表示,通常是一个单词,用一些巧妙的标记来表示它是直接整数还是指向具有公共结构的指针用于所有其他值(如数据结构或函数)的表示(某些标记等)。
如果您有这个假设,您可以编译每个多态函数一次,并将其用于所有类型的所有参数:它们具有编译函数假定的表示形式。
现在说你抛出类型与其他表示,例如。在堆栈上连续几个字。你不能再使用你的单一编译函数,因为它会期望一个单词,所以调用约定是不正确的。东西坏了。
这个问题可以通过各种方式,如:
通的价值观对他们表示了一些信息一起(你可以考虑这些信息是一种运行时的“类型”的信息,但实际上你不需要完整的类型信息,只需要一些关于表示的信息);这是什么TILT编译器探索例如
尝试编译你的多态函数的几个专门版本的每一个可能的代表性,再决定(也可根据各种各样的标签,或者一些静态资料)的版本打电话。对于像MLton这样的整个程序优化方案来说这可能是合理的。这或多或少是第一个想法的呼叫者选择(而不是被动选择)版本。
使用类系统限制多态性来区分“单词类型”,“元组类型”。除了“全部类型”的通常多态性外,您将拥有一个相对版本“适用于所有类型的此类...”。这允许程序员静态地推断哪个函数可以接受哪种类型的参数(“ow,这个函数是多态的,所以我必须在这里填入我的值类型”),而不是希望编译器能够正确地获得强制,但是这也是使系统更重:你不能保持一致性的幻觉。
简而言之,组合(某种形式)的多态与丰富的数据表示选择是可能的,但比统一表示形式更困难。
0
不,这是不正确的。您可以通过将参数类型定义为泛型或类型object
(值类型将自动“装箱”到对象中)来实现“高阶多态性”(函数在所有类型上表现均匀)
相关问题
- 1. scala中更高阶多态性的常见做法
- 2. 泛型类型多态性
- 3. Typescript:高阶组件的类型定义
- 4. 表示UML类图中的参数多态性和高阶函数
- 5. C#泛型类型的多态性
- 6. 我可以为 - > b - > *写更高阶的类型吗?
- 7. 高阶Scalacheck属性
- 8. 高阶组件:React.createElement:类型无效
- 9. 宏返回类型和更高阶函数
- 10. 更高阶的reduce()函数
- 11. C++中的多态性,子类型?
- 12. C++中的子类型多态性
- 13. 参数值(不是类型)的多态性?
- 14. 返回值的scala多态类型
- 15. Scala抽象类型和多态性
- 16. Haskell多态性和类型实例
- 17. 多态性而iheriting泛型类
- 18. 多态性GTEST类型参数
- 19. C++多态性和类型铸造
- 20. Objective-C超类型多态性
- 21. 什么类型的问题有助于“更高主因多态性”更好地解决?
- 22. C模拟值类型多态性夏普
- 23. React&Typescript:具有高阶控制和通用类型的交集类型
- 24. 静态类型的性能
- 25. 高阶函数的计算复杂性?
- 26. 类型安全高阶React组件和无状态功能组件
- 27. F#多态类型
- 28. 在约束存在限定的高阶类型映射
- 29. 理解类型的高阶函数在斯卡拉
- 30. 通用高阶函数的不兼容流类型
对于解决方案#2,具有多态递归的值类型存在问题,因为您可能需要编译无限多个版本的代码。有可能检测到这种情况? – Jules 2012-07-25 11:17:56
实际上,由于递归调用的原因,您不会希望为堆栈填充大小无限的值类型。我的直觉是,在大小上加上静态限制(以及上面的装箱)或强制类型递归通过至少一个指针在大多数情况下都比在你的语言中添加完整的JIT来解决这个问题更合理。 – gasche 2012-07-28 15:07:59