DLR、Boo 和 JVM
我刚刚开始尝试了解有关 .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 方面变得有些过时了？
I'm just starting to try to learn more about the .Net VM underpinnings, and am immediately thrown off by something. I know there's this new thing called the DLR that allows for all the dynamic stuff in C# and the running of the IronX languages. But now I'm reading about this language called Boo, and apparently it has had dynamic capabilities since long before the DLR existed. So,
1) How is this even possible?
2) What does the DLR add to the equation?
3) Would a language like Boo stand to gain anything by re-implementing itself in terms of the DLR?
From what I've kind of gathered here and there, it looks like the DLR came out of IronPython, when they factored out everything that was necessary for DL support in .Net, and put it in reusable form. So what I'm guessing is that DLR is nothing special, just some libraries that help with dynamic objects in Microsoft.Scripting.dll, but nothing that you couldn't just go out and code up by yourself if you had the time, which I guess is what happened for Boo? And then for 2 and 3, I guess the commonality and reusability of the DLR would allow any future DLR improvements to be grandfathered in automatically, but that there's no urgent "need" to re-implement using the DLR if you've already made your own custom runtime? Or does the DLR have some secret MS sauce that makes it better than anything we could do on top of .Net?
4) Is the DLR really a runtime or just a set of libraries? (What exactly is a runtime anyway? I probably need to learn more compiler theory before I can even understand an answer to this question, or whether it's even a question that means anything. Ignore this question. Or don't.)
5) How does IronPython compilation work? Does it compile down to a new dynamic version of the CIL, or does it just prepend a "ironpython.exe" command to a string with the program's text in it? Hmm, well if dynamic is a keyword in C#, then there must be a dynamic version of the CIL, right? So how does .Net know whether to use the CLR or the DLR on the CIL?
6) Is the DaVinci project for the JVM different? It looks like it's an actual re-implementation of the JVM itself. What are the implications of this approach? I'm guessing there's huge performance gains, but anything else? Any reason MS didn't take this road?
7) Does the DLR make Boo somewhat obsolete for making DSLs?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这里有很多问题！我不确定我能否回答所有问题，但我会尽我所能：
Boo 与 (Iron)Python 不同，它不是动态的。它主要是一种静态类型语言，具有强类型推断和 Python 语法。这一点，再加上可选的鸭子类型，给了它一种非常动态的感觉，但它肯定与 Python 不同。与 Python 相比，Boo 与 C# 4 更相似（语法除外）。
DLR 在 CLR 之上添加了对语言实现者的动态支持，CLR 更适合静态类型语言（例如 VB.NET、C#、F#）
恕我直言，并非如此。它会变得与 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 的实现截然不同。
Lots of questions here! I'm not sure I can answer all of them, but I'll do as much as I can:
Boo is not dynamic in the same sense that (Iron)Python is. It's mostly a statically typed language with strong type inference and pythonic syntax. This, coupled with its optional duck typing, give it a very dynamic feel, but it's certainly not the same as Python. Boo is more similar (except for syntax) to C# 4 than Python.
DLR adds dynamic support for language implementors on top of the CLR, which is more geared towards statically typed languages (such as VB.NET, C# ,F#)
Not really IMHO. It would become too similar to IronPython. Precisely one of the characteristics of Boo is that it's statically typed.
Runtimes are libraries which support some basic constructs in the language. VB.NET, C#, F#, Boo, they all have runtime libraries. You usually never see VB.NET or C# runtimes because they come with the .NET framework. There was a great answer on SO about this from Eric Lippert but I can't find it.
Can't comment on this, don't have much hands-on experience with IronPython.
Don't know about the DaVinci project, can't comment on this.
No. As far as I know Boo's macros and extensible compiler are quite unique for a .NET language (Nemerle has similar macro capabilities). I can't really say if Boo DSLs can be more or less powerful than IronPython DSLs. What I can say for sure is that the implementation of Boo DSLs is wildly different from the implentation of Python DSLs.
DLR 基本上带来了 3 样东西：
元对象协议是唯一绝对需要共享的部分 - 您可以自己创建其他所有内容。
IronPython 完全构建在 DLR 之上 - 因此它的编译模型实际上是编译为表达式树。 .NET 4.0 附带的 DLR 内层用于编译这些表达式树，我们使用解释器（外层的一部分）来解释这些表达式树。然后，我们可以在解释版本变热后延迟编译表达式树。该编译包括调用站点的生成，我们使用它来动态调度各种操作（获取、设置成员、调用对象等...），并且我们再次使用 DLR - 在本例中它是调用站点机制。 IronPython 将标准 DLR 绑定器与执行 IronPython 特定操作（流经代码上下文、支持 *args 和 **args 调用等）的自定义绑定器结合使用来执行这些操作，然后回退到标准 DLR 绑定器互操作。
Davinci 项目将向 JVM 添加 CLR 已经以委托形式存在的“方法句柄”。它还将添加一个新的“invokedynamic”操作码，CLR 没有该操作码，并且 DLR 工作也无法获得该操作码。相反，DLR 仅使用现有原语（委托、具体化泛型）以及用于定义互操作协议的库。两者都添加了调用站点的概念，并且两者之间可能非常相似。
The DLR basically brings 3 things to the party:
The meta object protocol is the only piece that absolutely needs to be shared - everything else you could create on your own.
IronPython builds fully on top of the DLR - so it's compilation model is actually to compile to expression trees. The DLR inner layer which shipped w/ .NET 4.0 is used to compile those expression trees and we use the interpreter which is a piece of the outer layer to interpret those expression trees. We can then lazily compile the expression trees after the interpreted versions have become hot. That compilation includes the production of call sites which we use for dynamic dispatch of various operations (getting, setting members, calling objects, etc...) and again we use the DLR - in this case it's call site mechanism. IronPython uses a combination of both standard DLR binders for these operations along with custom binders which do IronPython specific actions (flow through code context, supporting *args and **args calls, etc...) which then fall back to standard DLR binders for interop.
The Davinci project will add "method handles" to the JVM which the CLR has already had in the form of delegates. It will also add a new "invokedynamic" opcode which the CLR doesn't have and didn't gain w/ the DLR work. Instead the DLR just uses the existing primitives (delegates, reified generics) plus libraries for defining the interop protocol. Both add the concept of call sites and those may be fairly similar between the two.