.net DLR、Boo和JVM

我刚刚开始尝试了解更多关于.NETVM基础的知识，但马上就被一些东西甩了。我知道有一种叫做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是否有一些秘密的微软酱汁，使它比我们在.Net上做的任何事情都要好

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

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

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

---

7） DLR是否使Boo在制造DSL时有些过时？

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

Boo的动态性与（Iron）Python不同。它主要是一种静态类型语言，具有强大的类型推断和python语法。这一点，再加上可选的duck类型，给它一种非常动态的感觉，但它肯定不同于Python。Boo比Python更类似于C#4（语法除外）

DLR在CLR之上增加了对语言实现程序的动态支持，CLR更倾向于静态类型语言（如VB.NET、C#、F#）

不是真的。它将变得太类似于IronPython。Boo的一个特点就是它是静态类型的

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

对此不予评论，因为我没有太多的IronPython实践经验

我不知道达芬奇项目，不能对此发表评论

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

---

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

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

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

IronPython完全构建在DLR之上，所以它的编译模型实际上是编译为表达式树。DLR内层（w/.NET4.0提供）用于编译这些表达式树，我们使用作为外层的一部分的解释器来解释这些表达式树。然后，在解释的版本变得热门之后，我们可以懒洋洋地编译表达式树。该编译包括调用站点的生成，我们使用这些站点动态调度各种操作（获取、设置成员、调用对象等），我们再次使用DLR——在本例中是调用站点机制。IronPython为这些操作使用了标准DLR绑定器和定制绑定器的组合，定制绑定器执行IronPython特定的操作（流经代码上下文，支持*args和**args调用等），然后返回到标准DLR