难道是“表达问题”？可以用 F# 解决吗？

Question

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

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

澄清：我假设问题的定义如 上一个视频 系列中——数据类型的可扩展性以及对数据类型的操作，具有代码级模块化和单独编译（扩展可以部署为单独的模块，无需修改或重新编译原始代码）以及静态类型安全的特点。

Answer 1

正如 Jörg 在评论中指出的那样，这取决于您所说的“解决”的含义。如果您的意思是解决，包括某种形式的类型检查，确保您在某些情况下不会缺少某些函数的实现，那么 F# 不会给您任何优雅方式（我不确定 Haskell 解决方案是否优雅）。您可以使用 kvb 提到的 SML 解决方案对其进行编码，或者使用 基于面向对象的解决方案。

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

一个草图是使用 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)

这不会为您提供任何类型检查，但它为您提供了一个相当优雅的解决方案，该解决方案易于使用且实现起来并不困难（使用反射）。检查是否缺少案例并不是在编译时完成的，但您可以轻松地为此编写单元测试。

Answer 2

请参阅 此处 Vesa Karvonen 的评论，了解一种 SML 解决方案（尽管很麻烦），可以轻松转换为 F#。

Answer 3

我知道 F# 中不提供类型类，但是有没有办法使用其他语言功能来实现这种可扩展性？

我不相信，不。

如果没有，我们距离解决 F# 中的表达式问题还有多远？

表达式问题是允许用户使用新函数和新类型来扩充库代码，而无需重新编译库。在 F# 中，联合类型可以轻松添加新函数（但不可​​能向现有联合类型添加新联合案例），而类类型可以轻松派生新类类型（但不可能向现有类层次结构添加新方法） 。这是实践中所需的两种形式的可扩展性。在不牺牲静态类型安全性的情况下同时向两个方向扩展的能力只是一种学术好奇心，IME。

顺便说一句，我所见过的提供这种可扩展性的最优雅的方法是牺牲类型安全性并使用所谓的“基于规则的编程”。 Mathematica 就是这么做的。例如，计算整数、变量或加法表达式的符号导数的函数可以在 Mathematica 中编写，如下所示：

D[_Integer, _] := 0
D[x_Symbol, x_] := 1
D[_Symbol, _] := 0
D[f_ + g_, x_] := D[f, x] + D[g, x]

我们可以像这样改进对乘法的支持：

D[f_ g_, x_] := f D[g, x] + g D[f, x]

并且我们可以添加一个新函数来计算表达式像这样：

E[n_Integer] := n
E[f_ + g_] = E[f] + E[g]

对我来说，这比用 OCaml、Haskell 和 Scala 等语言编写的任何解决方案都要优雅得多，但当然，它不是类型安全的。