pypy - 使用 JIT 编写解释器的 RPython 之外的选项？

Question

我对 PyPy 项目非常感兴趣，但对于下面列出的第一个(但鲜为人知的)目的:

一套为解释型语言实现解释器的工具

使用此工具链的 Python 实现

在以下博文中， http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html , 和 http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html有关于如何使用 RPython 实现 Brainfork 解释器并添加 JIT 的详细教程。

然而，我在其他地方读到 RPython 使用起来可能很麻烦——为动态类型创建的语法突然限制为推断的静态类型导致难以理解的编译错误。

所以我的问题是，有没有其他项目可以让你像上面的教程一样编写一个脑筋急转弯的解释器/JIT？或者 PyPy 是简洁地这样做的唯一选择？

(旁白):如果存在，那么 RPython 的一般意义是什么？是否只是为了表明可以使 Python 子集类型安全，并在该子集中实现 Python？在现有的解释器创建工具中执行“PyPy”是否更有意义？

Answer 1

However I've read elsewhere that RPython can be troublesome to work with--syntax created for dynamic typing suddenly restricted to inferred static typing leads to hard-to-understand compile errors.

它与语法无关(Python 语法与打字唯一相关的是它没有类型注释的地方，并且可以 - 并且在 3.0 中已经改变了)，更多关于:

好的错误消息非常困难，随着编译器其余部分的变化，它们的代码几乎不可避免地会发生变化。因此，当您编写由少数专家(通常是编写翻译器的人)而不是普通大众编写的高度复杂的代码编译代码时，需要付出很多努力，并且是首先要切入的角落之一。翻译器的操作与通常的编译器完全不同的事实也无济于事。

一切都被推断出来的事实意味着对类型的唯一洞察(对于你作为读者)来自理解和心理应用翻译者推断类型的过程。这与通常的编译器技术完全不同，而且并非微不足道。

So my question is, are there any other projects that would allow you to write a brainfudge interpreter/JIT like in the tutorial above? Or is PyPy the only option for doing so as succinctly?

我不知道有任何其他项目试图从解释器创建 JIT 编译器。当 PyPy 的人这样做时，我非常有信心这个想法是新的，所以像这样的其他东西(如果存在)比 RPython 更成熟的可能性很小。
有许多项目可以帮助各个方面。还有一些可以一起解决这些方面的许多或“所有”问题，例如 Parrot。但 AFAIK 没有一个像 PyPy 那样引人注目的成功案例。

Parrot 是一个用于动态语言的 VM，具有多个后端(我刚刚了解到，自 v1.7 以来没有 JIT，但该架构允许透明地重新引入一个)，并且显然为语言实现者开发了一套丰富的工具。 CLR 和 JVM 为静态面向对象语言提供了类似的服务，尽管我不知道像 Parrot 那样复杂的工具。

但是，它不是您编写解释器，而是定义 am IR(实际上是几个)，您的工作是将语言编译为该 IR(并根据 VM 可以理解的术语定义内置功能)。在这方面，它不同于 RPython 编写解释器的方法。此外，与其他 VM 一样，如果您的语言的某些方面严重映射到 IR，您会感到困惑。需要与 VM 的服务完全不同的东西吗？玩得开心模拟它(并遭受糟糕的表现)。需要特定于语言的优化(这对任意 IR 无效，并且无法提前完成)？告别这些性能改进。
除了玩具语言之外，我不知道 Parrot 上有完整的语言实现。而且由于他们不经常吹嘘性能，我担心他们目前在这方面很弱。

LLVM(其他人提到)以及许多其他代码生成器/后端只是其中的一种。您必须编写一个成熟的静态编译器，将您的语言降低到机器代码的抽象级别，而不是解释器。这可能是可行的，但肯定是完全不同的。

If one exists, what's the point of RPython in general?

“编写 JIT 编译器很难，让我们去买解释器吧。”好吧，它可能开始于“我们想用 Python 来做 Python，但它太慢了，我们不想从头开始制作一种编程语言”。但是现在，RPython 本身就是一种非常有趣的编程语言，因为它是世界上第一个以 JIT 编译器为一流(不是真正意义上的一流函数，但足够接近)语言构造的编程语言.

Would it have made more sense just to do "PyPy" in an existing interpreter-creation tool?

只是为了成为元数据，做研究并展示它的效果，我喜欢当前的方法。在 JIT 生成器工作之前，您可以在任何具有静态编译、C-ish 性能潜力和宏(或添加他们所谓的“翻译方面”的其他方式)的语言中使用相同的内容——尽管这些很少见.但是，为整个 Python 语言编写一个性能良好(JIT 与否)的编译器一再证明对于人类来说太难了。我会说编写一个解释器没有任何意义，然后努力在单独的 JIT 编译器代码库中再次正确使用它，并且仍然优化任何东西。