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”命令添加到包含程序文本的字符串中？嗯，如果动态是 C# 中的关键字，那么 CIL 必须有动态版本，对吧？那么.Net如何知道在CIL上使用CLR还是DLR呢？

6) JVM 的达芬奇项目有什么不同吗？看起来它是 JVM 本身的实际重新实现。这种方法的含义是什么？我猜有巨大的性能提升，但还有什么？ MS没有走这条路的原因是什么？

7) DLR 是否让 Boo 在制作 DSL 时有些过时？

Answer 1

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

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

2. DLR在 CLR 之上添加了对语言实现者的动态支持，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 基本上为聚会带来了 3 样东西：

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

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

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

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