高阶多态性 + 值类型答案

【问题标题】：Higher order polymorphism + value types高阶多态性 + 值类型
【发布时间】：2011-04-05 19:40:11
【问题描述】：

我在某处读到高阶多态性不能在具有值类型的类型系统中使用/实现（如 .NET）。对吗？为什么？

【问题讨论】：

【解决方案1】：

问题在于值表示。

传统的高阶多态性语言做出了简化的选择，即所有值都以统一的方式表示，通常是一个单词，并带有一些巧妙的标记来指示它是立即整数还是指向具有通用表示的结构的指针（一些标记等）用于所有其他值，例如数据结构或函数。

如果你有这个假设，你可以编译每个多态函数一次，并在所有类型的所有参数上使用它：它们具有编译函数所假设的表示。

现在说你抛出具有其他表示的类型，例如。堆栈上的几个连续单词。你不能再使用你的单个编译函数，因为它需要一个单词，所以调用约定是不正确的。东西坏了。

这可以通过多种方式解决，例如：

与值一起传递有关其表示的一些信息（您可以将此信息视为一种运行时“类型”信息，但实际上您不需要完整的类型信息，只需一些关于表示）;这就是 TILT 编译器探索的例子
尝试为每个可能的表示编译多态函数的几个专门版本，然后决定（也基于各种标记或一些静态可用信息）调用哪个版本。这对于诸如 MLton 的全程序优化方案是合理的。这或多或少是第一个想法的调用者选择（而不是被调用者选择）版本。
使用种类系统来限制多态性以区分“单字类型”、“元组类型”。而不是通常的多态性“对于 all 类型”，您将有一个相对化的版本“对于所有此类类型......”。这允许程序员静态地推断哪个函数可以接受哪种类型的参数（“哦，这个函数是多态的，所以我必须在这里装箱我的值类型”）而不是希望编译器能够正确地得到强制，但这也是使类型系统更重：你不会保留统一的错觉。

简而言之，结合（某种形式的）多态性与丰富的数据表示选择是可能的，但比统一表示的情况要困难得多。

【讨论】：

具有多态递归的值类型对于解决方案 #2 来说是有问题的，因为您可能需要编译无限多个版本的代码。有可能检测到这种情况吗？
实际上，由于递归调用，您不希望在堆栈中填充无限大小的值类型。我的直觉是，在大多数情况下，对大小设置静态限制（以及上面的装箱）或强制类型递归通过至少一个指针都是更合理的解决方案，而不是在你的语言中添加完整的 JIT 来处理这个问题。跨度>

【解决方案2】：

不，这是不正确的。您可以通过将参数类型定义为泛型或 object 类型（值类型将自动“装箱”到对象中）来实现“高阶多态性”（在所有类型上行为一致的函数）

【讨论】：