ML函数器可以用.NET (C#/F#)完全编码吗？

Question

ML函数器可以用.NET接口和泛型来实际表达吗？有没有一个高级的ML函数式的用例可以挑战这样的编码？

答案摘要

一般来说，答案是否定的。ML模块提供了不直接映射到.NET概念的功能(例如通过签名[1]共享规范)。

但是，对于某些用例，ML习惯用法是可以翻译的。这些情况不仅包括基本的Set函数器[2]，还包括单体的函数式编码[3]，甚至还包括Haskell的更高级用途，如最终无标记解释器[4，5]。

实际的编码需要折衷，比如半安全的向下转换。你的里程数将会很谨慎。

博客和代码：

1. blog.matthewdoig.com
2. higherlogics.blogspot.com
3. monad functor in F#

Answer 1

ML模块的关键特性之一是共享规范。在.NET中没有能够模仿它们的机制--所需的机制差别太大了。

您可以尝试通过将共享类型转换为参数来实现这一点，但这不能忠实地模拟定义签名的能力，然后再对其应用共享，可能会有多种不同的方式。

在我看来，.NET将从具有这种机制的东西中受益--它将更接近于真正支持现代语言的多样性。希望包括模块系统的更多最新进展，如MixML中的那些，在我看来，这是模块系统的未来。http://www.mpi-sws.org/~rossberg/mixml/

Answer 2

HigherLogics是我的博客，我花了很多时间调查这个问题。限制实际上是类型构造函数上的抽象，也就是“泛型之上的泛型”。似乎模仿ML模块和函数器的最好方法至少需要一个(半安全的)强制转换。

它基本上归结为定义一个抽象类型，以及一个与操作该类型的模块签名相对应的接口。抽象类型和接口共享一个类型参数B，我称之为“品牌”；品牌通常只是实现模块接口的子类型。该品牌确保传入的类型是模块所期望的正确的子类型。

// signature
abstract class Exp<T, B> where B : ISymantics<B> { }
interface ISymantics<B> where B : ISymantics<B>
{
  Exp<int, B> Int(int i);
  Exp<int, B> Add(Exp<int, B> left, Exp<int, B> right);
}
// implementation
sealed class InterpreterExp<T> : Exp<T, Interpreter>
{
  internal T value;
}
sealed class Interpreter : ISymantics<Interpreter>
{
  Exp<int, Interpreter> Int(int i) { return new InterpreterExp<int> { value = i }; }
  Exp<int, Interpreter> Add(Exp<int, Interpreter> left, Exp<int, Interpreter> right)
  {
    var l = left as InterpreterExp<int>; //semi-safe cast
    var r = right as InterpreterExp<int>;//semi-safe cast
    return new InterpreterExp<int> { value = l.value + r.value; }; }
  }
}

正如您所看到的，强制转换基本上是安全的，因为类型系统确保表达式类型的品牌与解释器的品牌相匹配。搞砸的唯一方法是客户端创建自己的Exp类并指定解释器品牌。有一种更安全的编码也避免了这个问题，但它对于普通编程来说太笨拙了。

我后来从奥列格的一篇用MetaOCaml写的论文中选择了used this encoding and translated the examples，来使用C#和Linq。解释器可以透明地运行使用这种嵌入式语言编写的程序，服务器端在ASP.NET中运行，客户端作为JavaScript运行。

这种对解释器的抽象是奥列格最终的无标记编码的一个特性。博客文章中提供了他论文的链接。

接口在.NET中是一流的，因为我们使用接口来编码模块签名，所以模块和模块签名在这种编码中也是一流的。因此，函数器直接使用接口来代替模块签名，即。它们将接受ISymantics的一个实例，并将任何调用委托给它。

Answer 3

我对ML函数器还不够了解，无法真正回答你的问题。但我要说的是，在一元编程中，我总是发现.Net的一个限制因素是无法从“所有M”的意义上抽象“M”。一些带有M的类型表达式(例如，其中M是一个类型构造函数(接受一个或多个泛型参数的类型))。因此，如果这是您有时需要/使用函数式的东西，那么我非常确信在.Net上没有好的方法来表达它。