在 DLR 上建立一个小型表达式 DSL 还是将其手动保存在 F# 中?

发布于 2024-08-07 05:48:23 字数 435 浏览 2 评论 0原文

我正在构建一个类似电子表格的应用程序,其中需要将大量小型计算拼接到树结构中。这些计算是用户定义的,我需要一种方法让用户在运行时输入它们。

我当前的方法是在 F# 中编写一个小型“表达式 DSL”,其中我使用 FParsec 解析输入,基于可判别联合构建语法树,然后可以计算表达式。这效果非常好。

不过,我正在考虑考虑将语言建立在 DLR 的基础上。沿着这条路走有什么好处吗(解析输入,使用 Scripting.AST 的东西而不是我自己的东西生成 AST,并让 DLR 处理计算的执行)?

每个计算量可能会很小。计算之间的依赖性将在更高级别上得到处理。

由于 DLR 将为表达式生成 CIL 代码,我是否可以期待更好的性能,或者开销会耗尽这些代码吗?

(至于使用像 IronPython 这样的现有语言,可能会很困难,因为我计划在语言语法中添加大量切片运算符和维度处理内容)

I'm building a spreadsheet-like application, where a lot of small calculations needs to be stitched together in a tree-structure. These calculations are user-defined and I need a way for the user to enter them at runtime.

My current approach is to write a small "expression DSL" in F#, where I parse the input with FParsec, build a syntax tree based on a discriminated union and then can evaluate the expression. This works pretty well.

However, I'm thinking of looking in to basing the language on the DLR instead. Are there any upsides to go down this road (parse the input, generate the AST using the Scripting.AST stuff instead of my own, and let the DLR handle the execution of the calculation)?

Each calculation will probably be pretty small. The dependency between the calculations will be taken care of on a higher level.

Can I expect better performance since the DLR will generate CIL code for the expression or will the overhead eat that up?

(as for using an existing language like IronPython, it will probably be hard since I'm planning to add a lot of slice-and-dice operators and dimensionality-handling stuff to the language syntax)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

冷了相思 2024-08-14 05:48:23

很难从如此宽泛的角度回答一个问题,但以下是我的一些想法。

使用 F# 构建解析器听起来不错。

FSParsec 是一个很棒的库。我有点偏向 FSLex 和 FSYacc。无论哪种方式,F# 中都有专门为解析而设计的库,可以节省您的时间。

使用 DLR 生成代码听起来不错。

DLR 是动态代码生成的绝佳平台。但是,您的应用程序更加具体。如果您仅限于计算值,则应使用 .NET 3.5 中的表达式树 API。该 API 旨在表示任意代码表达式。另一方面,DLR 被设计为运行时或动态语言。我并不是说这是不可能的,只是它不是完成这项工作的正确工具。

不要编译生成的代码。

如果您确实使用 DLR 来表示 AST,则编译和执行的成本可能远远大于简单解释树的成本。如果出现以下情况,请编译代码:A.) 您多次执行相同的函数/方法,或者 B.) 函数/方法非常复杂。

C# + DLR、IronPython、F# 或三者的某种组合都是不错的选择。最终,“正确”的选择是尽可能快地完成工作的选择。

It's difficult to answer a question in such broad terms, but here are some of my thoughts.

Using F# to build the parser sounds good.

FSParsec is a great library. I'm kinda partial towards FSLex and FSYacc. Either way, in F# there are libraries specifically designed for parsing which save you time.

Generating code with the DLR sounds OK.

The DLR is a great platform for dynamic code generation. However, your application is much more specific. If you are limiting yourself to just computing values you should use the Expression Trees APIs from .NET 3.5. This API is designed for representing arbitrary code expressions. The DLR on the other hand is designed as a runtime or dynamic languages. I'm not saying it's impossible, just that it isn't the right tool for the job.

Don't compile your generated code.

If you do go with the DLR to represent your AST, the cost of compiling and executing will likely be far greater than simply interpreting the tree. Do compile the code if: A.) you are executing the same function / method many times or B.) the function / method is very complicated.

C# + DLR, IronPython, F#, or some combination of the three are all sound choices. Ultimately the 'correct' choice is the one that gets the job done in as quick of a time as possible.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文