解释型语言 - 利用解释器背后的编译语言
如果有任何语言设计者（或者只是了解的人），我对为解释性语言创建标准库背后的方法感到好奇。 具体来说，最好的方法是什么？ 用解释性语言定义标准函数/方法，或用编写解释器的编译语言执行这些调用的处理？
让我思考这个问题的是关于Python中类似stripslashes()的函数的SO问题。 我的第一个想法是“为什么不定义自己的函数并在需要时调用它”，但它提出了一个问题：对于这样的函数，让解释语言处理该开销是否更好，或者更好编写扩展并利用解释器背后的编译语言？
If there are any language designers out there (or people simply in the know), I'm curious about the methodology behind creating standard libraries for interpreted languages. Specifically, what seems to be the best approach? Defining standard functions/methods in the interpreted language, or performing the processing of those calls in the compiled language in which the interpreter is written?
What got me to thinking about this was the SO question about a stripslashes()-like function in Python. My first thought was "why not define your own and just call it when you need it", but it raised the question: is it preferable, for such a function, to let the interpreted language handle that overhead, or would it be better to write an extension and leverage the compiled language behind the interpreter?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如今，“解释型”语言和“编译型”语言之间的界限非常模糊。 例如，Python 在看到源代码时所做的第一件事是将其编译为字节码表示形式，本质上与 Java 编译类文件时所做的相同。 这就是 *.pyc 文件包含的内容。 然后，python 运行时执行字节码，而不参考原始源。 传统上，纯解释性语言在执行程序时会连续引用源代码。
在构建语言时，这是建立坚实基础的好方法，在此基础上可以实现更高级别的功能。 如果您有一个可靠、快速的字符串处理系统，那么语言设计者可以（并且应该）在基本运行时之外实现类似 stripslashes() 的东西。 这样做至少有几个原因：
像 Python 这样的语言编译为字节码并执行并不意味着它很慢。 人们没有理由不能按照 Java 和 .NET 已有的做法为 Python 编写即时 (JIT) 编译器，以进一步提高性能。 事实上，IronPython 将 Python 直接编译为 .NET 字节码，然后使用包括 JIT 在内的 .NET 系统运行。
为了直接回答你的问题，语言设计者唯一一次用运行时背后的语言实现一个函数（例如，Python 中的 C）是为了最大化该函数的性能。 这就是为什么正则表达式解析器等模块是用 C 而不是原生 Python 编写的。 另一方面，像 getopt.py 这样的模块是用纯 Python 实现的，因为所有这些都可以在那里完成，并且使用相应的 C 库没有任何好处。
The line between "interpreted" and "compiled" languages is really fuzzy these days. For example, the first thing Python does when it sees source code is compile it into a bytecode representation, essentially the same as what Java does when compiling class files. This is what *.pyc files contain. Then, the python runtime executes the bytecode without referring to the original source. Traditionally, a purely interpreted language would refer to the source code continuously when executing the program.
When building a language, it is a good approach to build a solid foundation on which you can implement the higher level functions. If you've got a solid, fast string handling system, then the language designer can (and should) implement something like stripslashes() outside the base runtime. This is done for at least a few reasons:
Just because a language like Python compiles to bytecode and executes that doesn't mean it is slow. There's no reason why somebody couldn't write a Just-In-Time (JIT) compiler for Python, along the lines of what Java and .NET already do, to further increase the performance. In fact, IronPython compiles Python directly to .NET bytecode, which is then run using the .NET system including the JIT.
To answer your question directly, the only time a language designer would implement a function in the language behind the runtime (eg. C in the case of Python) would be to maximise the performance of that function. This is why modules such as the regular expression parser are written in C rather than native Python. On the other hand, a module like getopt.py is implemented in pure Python because it can all be done there and there's no benefit to using the corresponding C library.
将传统上被视为“解释”的语言重新实现到 JVM 或 CLR 等平台上的趋势也越来越明显，然后允许轻松访问“本机”代码以实现互操作性。 因此，从 Jython 和 JRuby，您可以轻松访问 Java 代码，从 IronPython 和 IronRuby，您可以轻松访问 .NET 代码。
在这样的情况下，“利用解释器背后的编译语言”的能力可以被描述为新实现的主要动机。
There's also an increasing trend of reimplementing languages that are traditionally considered "interpreted" onto a platform like the JVM or CLR -- and then allowing easy access to "native" code for interoperability. So from Jython and JRuby, you can easily access Java code, and from IronPython and IronRuby, you can easily access .NET code.
In cases like these, the ability to "leverage the compiled language behind the interpreter" could be described as the primary motivator for the new implementation.
请参阅 www.lua.org 上的“论文”部分。
特别是Lua 5.0的实现
Lua定义了所有底层 (ANSI C) 代码中的标准函数。 我相信这主要是出于性能原因。 最近，即“string.*”函数在纯 Lua 中得到了替代实现，这对于 Lua 在 .NET 或 Java 运行时（不能使用 C 代码）之上运行的子项目至关重要。
See the 'Papers' section at www.lua.org.
Especially The Implementation of Lua 5.0
Lua defines all standard functions in the underlying (ANSI C) code. I believe this is mostly for performance reasons. Recently, i.e. the 'string.*' functions got an alternative implementation in pure Lua, which may prove vital for subprojects where Lua is run on top of .NET or Java runtime (where C code cannot be used).
只要您使用可移植的 API 来编译代码库，例如 ANSI C 标准库或 C++ 中的 STL，那么利用这些函数将阻止您重新发明轮子，并且可能提供更小、更快的解释器。 Lua 采用了这种方法，与许多其他方法相比，它绝对小而快。
As long as you are using a portable API for the compiled code base like the ANSI C standard library or STL in C++, then taking advantage of those functions would keep you from reinventing the wheel and likely provide a smaller, faster interpreter. Lua takes this approach and it is definitely small and fast as compared to many others.