F#设计模式 [英] F# design pattern

问题描述

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

Lets say I'm building a parser for a domain-specific language in F#.

我已经定义了一个表示表达式的有区别的联合:

I've defined a discriminated union to represent expressions:

    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，并希望为其生成代码. 我有一个函数可以对表达式进行类型推断和类型检查.

Now, I've built up an AST of type Expression and want to generate code for it. I have one function which does type inference and type checking on an expression.

它的定义就像

    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)
        ...

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

And I have another function to generate code which follows a similar pattern: Take an expression, write pattern-matching statements for each item in the union.

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

My question is: Is this the idiomatic way to do it in F#?

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

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

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

If I were using C#, I would define some abstract base class called Expression with virtual methods for InferType and GenerateCode and then override them in each subclass.

还有其他方法吗?

推荐答案

在我看来，这将是 如果工会的每个成员都更清洁 定义了自己的InferType， GenerateCode在本地使用.

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

我相信您的意思是更熟悉"，而不是更清洁".

I believe you mean "more familiar", not "cleaner".

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

Really, is your ideal to have you code generator implementation spread out across 10 different classes?

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

There is definitely a fundamental tension between whether you want to group things "by type" or "by operation". The usual OO way is "by type" whereas the FP (functional programming) way is "by operation".

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

In the case of a compiler/interpreter (or most things that in OO rely heavily on the Visitor pattern), I think "by operation" is the more natural grouping. The code generator for If and And and Or may have a bit in common; the typecheckers of the various nodes will similarly have commonalities; if you make a pretty-printer, there will likely be formatting routines common to all the node-pretty-printing implementations. In contrast, printing, typechecking, and codegenning an IfElse really don't have much to do with one another at all, so why would you want to group those in an IfElse class?

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

(To answer your questions: yes, this is idiomatic. Is there another way - yes, you can do it just like you would in C#. I think you'll find you're much less happy with the C# way, and that the code will also be 2-3x larger that way, with no benefit.)

这篇关于F#设计模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！