c# - 编写可移植的领域特定语言

Question

我想知道部署特定领域语言的好策略，该语言必须在至少 2 种语言(Java、C#)和可能更多(Python，可能还有 Javascript)下运行。

一些背景。我们已经开发并部署了一种当前用 C# 编写的特定于领域的语言。它通过一系列方法调用进行部署，这些方法调用的参数是公共(public)语言原语(字符串、 double 等)、集合(IEnumerable、HashSet 等)或特定领域库中的对象(CMLMolecule、Point3、RealSquareMatrix)。该库经过了很好的测试，对象必须符合稳定部署的 XML 架构，因此更改将是渐进的和可管理的(至少这是希望)。

我们希望这种语言将被广泛的、部分精通计算机的社区所使用，用于在没有中央控制的情况下破解他们自己的解决方案。理想情况下，DSL 将创建一定程度的封装并产生他们需要的基本功能。这些库将管理详细的算法，这些算法种类繁多，但广为人知。 Domain-specific languages vs. library of functions 中的 DSL 要求有很多共同点。 .

我很欣赏有关最佳架构的想法(很明显，一旦部署，我们就无法轻易回溯)。选项至少包括:

• 创建 IDL(例如通过 CORBA)。 W3C 为 XML DOM 做了这个——我讨厌它——而且它似乎有点矫枉过正
• 为每个平台手动创建相似的签名，并尽最大努力使它们保持同步。
• 创建可解析语言(例如 CSS)。
• XML 中的声明式编程(参见 XSLT)。这是我的首选解决方案，因为它可以被搜索、操作等。

性能并不重要。目的明确。

编辑 关于应用程序调用是否构成 DSL 的讨论。我发现了 Martin Fowler 对 DSL 的介绍 ( http://martinfowler.com/dslwip/Intro.html )，他在其中认为简单的方法调用(或链式调用)可以称为 DSL。所以像这样的系列:

point0 = line0.intersectWith(plane);
point1 = line1.intersectWith(plane);
midpoint = point0.midpoint(point1);

可以被认为是DSL

Answer 1

语言和图书馆之间的问题似乎有些歧义。 “内部 DSL”和“外部 DSL”这两个术语很有用，我认为是因为 Martin Fowler。 .

“外部”DSL 可能是一个独立的命令行工具。它被传递了一个源字符串，它以某种方式解析它，并用它做一些事情。语法和语义的工作方式没有真正的限制。它也可以作为主要由类似 eval 的方法组成的库提供；一个常见的例子是将 SQL 查询构建为字符串并在 RDBMS 库中调用 execute 方法；这不是一个非常愉快或方便的使用模式，如果大规模地散布在一个程序中会很糟糕。

“内部”DSL 是一种库，其编写方式利用了宿主(通用)语言的怪癖，给人一种新语言可以嵌入现有语言的印象。在语法丰富的语言(C++、C#)中，这意味着以严重扩展(或忽略)运算符符号的通常含义的方式使用运算符重载。 C++中有很多例子； C# 中也有一些 - Irony parser toolkit以相当受限的方式模拟 BNF，效果很好。

最后，有一个普通的旧库:类、方法、属性，名称都经过精心挑选。

外部 DSL 可以让您完全忽略跨语言集成问题，因为唯一类似库的部分是 eval 方法。但是发明自己的工具链并非易事。人们总是忘记调试、智能感知、语法高亮等的重要性。

如果您想在 C# 和 Java 上做好，内部 DSL 可能是一项毫无意义的努力。问题是，如果你利用了一种宿主语言的怪癖，你不一定能够在另一种语言上重复这个技巧。例如Java 没有运算符重载。

这留下了一个普通的旧图书馆。如果您想跨越 C# 和 Java(至少)，那么您在选择实现语言方面有些困难。你真的想把库写两次吗？一种可能是用 Java 编写库，然后使用 IKVM将其交叉编译为 .NET 程序集。这将保证您在这两个平台上的界面相同。

不利的一面是，API 将以最低公分母特性表示 - 也就是说，Java 特性 :)。没有属性，只有 getX/setX 方法。避开泛型，因为这两个系统在这方面有很大不同。甚至命名方法的标准方式在两者之间也不同(camelCase 与 PascalCase)，因此一组用户会闻到老鼠的味道。