F#设计模式

Question

可以说我正在为F#中的领域特定语言构建解析器。

我定义了一个区分的联合来表示表达式:

    type Expression = 
        | Equality of Expression*Expression
        | NonEquality of Expression*Expression
        | Or of Expression*Expression
        | And of Expression*Expression
        | If of Expression*Expression
        | IfElse of Expression*Expression*Expression
        | Bool of bool
        | Variable of string
        | StringLiteral of string

现在，我建立了一个 Expression类型的AST，并希望为其生成代码。
我有一个函数可以对表达式进行类型推断和类型检查。

它的定义像

    let rec InferType expr = 
        match expr with
        | Equality(e1,e2) -> CheckTypes (InferType e1) (InferType e2)
        | Or(e1,e2) -> CheckTypes (InferType e1) (InferType e2)
        | And(e1,e2) -> CheckTypes (InferType e1) (InferType e2)
        ...

我还有另一个函数来生成遵循类似模式的代码:取一个表达式，为联合中的每个项目编写模式匹配语句。

我的问题是:这是在F#中惯用的方式吗？

在我看来，如果工会的每个成员都在本地定义自己的 InferType和 GenerateCode，那会更干净。

如果使用的是C#，我将使用 Expression和 InferType的虚拟方法定义一些称为 GenerateCode的抽象基类，然后在每个子类中覆盖它们。

还有其他方法吗？

Answer 1

It seems to me that it would be cleaner if each member of the union defined its own InferType and GenerateCode locally with it.

我相信您的意思是“更熟悉”，而不是“更清洁”。

真的，让代码生成器实现分布在10个不同的类中是您的理想选择吗？

您要按“类型”还是“按操作”对事物进行分组之间绝对存在根本的矛盾。普通的OO方式是“按类型”，而FP(功能编程)方式是“按操作”。

对于编译器/解释器(或OO中的大多数事物都严重依赖于Visitor模式)，我认为“按操作”是更自然的分组。 If和 And和 Or的代码生成器可能有一些共同点。各个节点的类型检查器将具有相似性；如果您制作 pretty-print ，则可能会有所有节点 pretty-print 实现通用的格式化例程。相比之下， IfElse的打印，类型检查和代码生成实际上彼此之间没有多大关系，那么为什么要将它们归类到 IfElse类中呢？

(回答您的问题:是的，这是惯用的。还有另一种方法-是的，您可以像在C#中那样进行操作。我想您会发现您对C#的方式不满意，并且代码也将以这种方式大2-3倍，没有任何好处。)