我刚刚开始尝试了解有关.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自定义运行时？或者，DLR是否有一些秘密的MS酱，它比我们在.Net上做的任何东西都好？
4）DLR真的是运行时还是只是一组库？ （究竟什么是运行时？我甚至可能需要学习更多编译器理论才能理解这个问题的答案，或者它是否甚至是一个意味着什么的问题。忽略这个问题。或者不要。）
5）IronPython编译如何工作？它是否编译为CIL的新动态版本，还是仅将“ironpython.exe”命令添加到包含程序文本的字符串中？嗯，如果动态是C＃中的关键字，那么必须有CIL的动态版本，对吧？那么.Net如何知道是否在CIL上使用CLR或DLR？
6）JVM的DaVinci项目是否有所不同？看起来它是JVM本身的实际重新实现。这种方法有什么含义？我猜测有很大的性能提升，但其他什么呢？ MS没有采取这条道路的原因吗？
7）DLR是否使Boo在制作DSL方面有些过时了？
答案 0 :(得分：4)
这里有很多问题！我不确定我能否回答所有，但我会尽我所能：
Boo不像（Iron）Python那样具有动态性。它主要是一种静态类型语言，具有强类型推断和pythonic语法。这与其可选的鸭子打字相结合，给人一种非常动感的感觉，但它肯定与Python不同。 Boo与C＃4比Python更相似（语法除外）。
DLR在 CLR之上添加了对语言实现者的动态支持，这更适合于静态类型语言（例如VB.NET，C＃，F＃）
< / LI>不是真的恕我直言。它会变得与IronPython太相似了。准确地说，Boo的一个特点就是它是静态类型的。
运行时是库，支持该语言中的一些基本结构。 VB.NET，C＃，F＃，Boo，它们都有运行时库。您通常不会看到VB.NET或C＃运行时，因为它们带有.NET框架。 Eric Lippert对此有一个很好的答案，但我找不到它。
无法对此发表评论，没有太多关于IronPython的实践经验。
不了解达芬奇项目，无法对此发表评论。
没有。据我所知，Boo的宏和可扩展编译器对于.NET语言来说是非常独特的（Nemerle具有类似的宏功能）。我不能说Boo DSL是否比IronPython DSL更强大或更弱。我可以肯定地说，Boo DSL的实现与Python DSL的实现完全不同
答案 1 :(得分：4)
DLR基本上为聚会带来了三件事：
元对象协议是唯一绝对需要共享的部分 - 您可以自己创建的所有其他内容。
IronPython完全建立在DLR之上 - 因此它的编译模型实际上是编译到表达式树。使用.NET 4.0发布的DLR内层用于编译这些表达式树，我们使用解释器作为外层的一部分来解释这些表达式树。然后我们可以在解释版本变热之后懒洋洋地编译表达式树。该编译包括我们用于动态调度各种操作（获取，设置成员，调用对象等等）的调用站点的生成，并且我们再次使用DLR - 在这种情况下它是调用站点机制。 IronPython使用两种标准DLR绑定器组合进行这些操作，以及定制绑定器，这些绑定器执行IronPython特定操作（流经代码上下文，支持* args和** args调用等...），然后返回到标准DLR绑定器互操作。
Davinci项目将向JVM添加“方法句柄”，CLR已经以委托的形式提供了这些句柄。它还将添加一个新的“invokedynamic”操作码，CLR没有并且没有获得DLR工作。相反，DLR只使用现有的原语（委托，具体的泛型）和库来定义互操作协议。两者都添加了呼叫站点的概念，两者之间可能非常相似。