DLR、Boo 和 JVM

Question

我刚刚开始尝试了解有关 .Net VM 基础的更多信息，但立即就被某些事情迷惑了。我知道有一个叫做 DLR 的新东西，它允许 C# 中的所有动态内容和 IronX 语言的运行。但现在我正在阅读有关这种名为 Boo 的语言，显然早在 DLR 存在之前它就已经具有动态功能。所以，

1）这怎么可能？

2) DLR 在方程式中添加了什么？

3) 像 Boo 这样的语言通过在 DLR 中重新实现自身会获得什么好处吗？

从我在这里和那里收集到的信息来看，DLR 似乎来自 IronPython，当时他们提取了 .Net 中 DL 支持所需的所有内容，并将其置于可重用的形式。所以我猜测 DLR 没什么特别的，只是一些帮助 Microsoft.Scripting.dll 中的动态对象的库，但如果你有时间的话，你可以自己编写代码，这我猜 Boo 身上发生了什么事？然后对于 2 和 3，我想 DLR 的通用性和可重用性将允许任何未来的 DLR 改进自动继承，但如果您已经做出了您的计划，则没有迫切的“需要”重新实施使用 DLR自己的自定义运行时？或者 DLR 是否有一些秘密的 MS 技术，使其比我们在 .Net 上所做的任何事情都更好？

4) DLR 真的是一个运行时还是只是一组库？（到底什么是运行时？我可能需要学习更多编译器理论，然后才能理解这个问题的答案，或者它是否是一个有意义的问题。忽略这个问题。或者不要。）

5) IronPython 编译是如何工作的？它会编译为新的动态版本的 CIL，还是只是在包含程序文本的字符串前面添加“ironpython.exe”命令？嗯，如果dynamic是C#中的关键字，那么一定有一个动态版本的CIL，对吧？那么.Net如何知道在CIL上使用CLR还是DLR呢？

6) JVM 的 DaVinci 项目有什么不同吗？看起来它是 JVM 本身的实际重新实现。这种方法有什么影响？我猜性能会有巨大的提升，但还有其他什么吗？MS有什么理由不走这条路？

7) DLR 是否会让 Boo 在制作 DSL 方面变得有些过时了？

Answer 1

这里有很多问题！我不确定我能否回答所有问题，但我会尽力回答：

1. Boo 与 (Iron)Python 不同，它是动态的。它主要是一种静态类型语言，具有强类型推断和 Python 语法。这一点，加上它可选的鸭子类型，给了它一种非常动态的感觉，但它肯定与 Python 不同。与 Python 相比，Boo 与 C# 4 更相似（语法除外）。

2. DLR在 CLR 之上添加了对语言实现者的动态支持，这更适合静态类型语言（例如 VB.NET、C# 、F#）

3. 恕我直言，不是真的。它会变得与 IronPython 太相似。Boo 的特点之一就是它是静态类型的。

4. 运行时是支持语言中一些基本结构的库。VB.NET、C#、F#、Boo，它们都有运行时库。您通常不会看到 VB.NET 或 C# 运行时，因为它们随 .NET 框架一起提供。Eric Lippert 对此有一个很好的答案，但我找不到。

5. 对此无法发表评论，没有太多 IronPython 的实践经验。

6. 不了解达芬奇项目，无法对此发表评论。

7. 不。据我所知，Boo 的宏和可扩展编译器对于 .NET 语言来说是非常独特的（Nemerle具有类似的宏功能）。我真的不能说 Boo DSL 是否比 IronPython DSL 更强大或更弱。我可以肯定地说，Boo DSL 的实现与 Python DSL 的实现有很大不同。

Answer 2

DLR 基本上为聚会带来了三件事：

• 一组扩展的表达式树（首先通过 LINQ 引入），可以编译完整的程序。这些提供了比直接生成 IL 更简单的生成代码的方法 - 它消除了许多能够生成无效 IL 的情况，并将更多情况转变为易于调试的运行时异常。
• 内置的调用站点缓存机制，因此您无需创建自己的缓存机制（对于动态语言的良好性能非常有用）。这包括多级缓存和老化未使用的项目等。
• 一种元对象协议，允许动态语言在运行时相互通信，并协商调用语言的正确结果（例如，当成员不存在时，在 JavaScript 中返回未定义，或者在 Python 中抛出 AttributeError，无论动态语言是什么语言）对象被写入）。

元对象协议是唯一绝对需要共享的部分 - 您可以自己创建其他所有内容。

IronPython 完全构建在 DLR 之上 - 因此它的编译模型实际上是编译为表达式树。.NET 4.0 附带的 DLR 内层用于编译这些表达式树，我们使用解释器（外层的一部分）来解释这些表达式树。然后，我们可以在解释版本变热后延迟编译表达式树。该编译包括调用站点的生成，我们使用它来动态调度各种操作（获取、设置成员、调用对象等...），并且我们再次使用 DLR - 在本例中它是调用站点机制。IronPython 将标准 DLR 绑定器与执行 IronPython 特定操作（流经代码上下文、支持 *args 和 **args 调用等）的自定义绑定器结合使用来执行这些操作，然后返回到标准 DLR 绑定器以执行这些操作互操作。

Davinci 项目将向 JVM 添加 CLR 已经以委托形式存在的“方法句柄”。它还将添加一个新的“invokedynamic”操作码，CLR 没有该操作码，并且 DLR 工作也无法获得该操作码。相反，DLR 仅使用现有原语（委托、具体化泛型）以及用于定义互操作协议的库。两者都添加了调用站点的概念，并且两者之间可能非常相似。