f# - "expression problem"可以在 F# 中解决吗？

Question

我一直在看一个有趣的video Haskell中的哪些类型类用于解决所谓的“表达式问题”。大约 15 分钟后，它展示了如何使用类型类来“打开”基于可区分联合的数据类型以进行扩展——可以单独添加额外的鉴别器，而无需修改/重建原始定义。

我知道类型类在 F# 中不可用，但是有没有办法使用其他语言特性来实现这种可扩展性？如果不是，我们离解决 F# 中的表达式问题有多近？

澄清:我假设问题的定义如 previous video 中所述。
系列中——数据类型的可扩展性和对数据类型的操作，具有代码级模块化和单独编译(扩展可以作为单独的模块部署，无需修改或重新编译原始代码)以及静态类型安全的特性。

Answer 1

正如 Jörg 在评论中指出的那样，这取决于您所说的解决方案是什么意思。如果你的意思是解决包括某种形式的类型检查，在某些情况下你没有错过某个函数的实现，那么 F# 不会给你任何优雅的方式(我不确定 Haskell 解决方案是否优雅)。您可以使用 kvb 提到的 SML 解决方案或使用 OO based solutions 之一对其进行编码。 .

实际上，如果我正在开发一个需要解决问题的真实系统，我会选择一个不会给你全面检查但更容易使用的解决方案。

草图将使用 obj作为类型的表示，并使用反射来定位为个别情况提供实现的函数。我可能会使用某些属性标记所有部分以使检查更容易。将应用程序添加到表达式的模块可能如下所示:

[<Extends("Expr")>]  // Specifies that this type should be treated as a case of 'Expr'
type App = App of obj * obj

module AppModule = 
  [<Implements("format")>] // Specifies that this extends function 'format'
  let format (App(e1, e2)) =
    // We don't make recursive calls directly, but instead use `invoke` function
    // and some representation of the function named `formatFunc`. Alternatively
    // you could support 'e1?format' using dynamic invoke.
    sprintfn "(%s %s)" (invoke formatFunc e1) (invoke formatFunc e2)

这不会为您提供任何类型检查，但它为您提供了一个相当优雅的解决方案，该解决方案易于使用且不难实现(使用反射)。检查你没有遗漏一个案例不是在编译时完成的，但你可以很容易地为此编写单元测试。