解释语言 - 利用解释器背后的编译语言

Question

如果有任何语言设计师（或者只是知情人士），我很好奇为解释语言创建标准库背后的方法。具体来说，什么似乎是最好的方法？用解释语言定义标准函数/方法，或者用编写解释器的编译语言处理那些调用？

让我思考的是关于striplashes（）的SO问题 - 就像Python中的函数一样。我的第一个想法是“为什么不定义自己的，只需在需要时调用它”，但它提出了一个问题：对于这样的函数来说，让解释的语言处理这种开销是不是更好，或者它会更好编写扩展并利用解释器后面的编译语言？

Answer 1

“解释”和“编译”语言之间的界限现在非常模糊。例如，Python在看到源代码时所做的第一件事是将其编译成字节码表示，基本上与编译类文件时Java所做的相同。这是* .pyc文件包含的内容。然后，python运行时执行字节码而不引用原始源。传统上，纯粹解释的语言在执行程序时会不断引用源代码。

构建语言时，建立一个可以实现更高级别功能的坚实基础是一种很好的方法。如果你有一个可靠，快速的字符串处理系统，那么语言设计者可以（并且应该）在基本运行时之外实现像stripslashes（）这样的东西。这样做至少有几个原因：

• 语言设计师可以证明该语言足够灵活，可以处理这类任务。
• 语言设计师实际上用语言编写实际代码，该语言有测试，因此表明基础是可靠的。
• 其他人可以更轻松地阅读，借阅甚至更改更高级别的功能，而无需构建甚至不了解语言核心。

仅仅因为像Python这样的语言编译为字节码并执行并不意味着它很慢。没有理由为什么有人不能为Python编写一个Just-In-Time（JIT）编译器，以及Java和.NET已经做的事情，以进一步提高性能。事实上，IronPython直接将Python编译为.NET字节码，然后使用包含JIT的.NET系统运行。

要直接回答您的问题，语言设计人员在运行时背后的语言中实现函数的唯一时间（例如，在Python的情况下为C）将最大化该函数的性能。这就是正则表达式解析器等模块是用C语言而不是本机Python编写的原因。另一方面，像getopt.py这样的模块是用纯Python实现的，因为它可以在那里完成，并且使用相应的C库没有任何好处。

Answer 2

重新实现传统上被认为“解释”到JVM或CLR等平台上的语言的趋势也在增加，然后允许轻松访问“本机”代码以实现互操作性。因此，从Jython和JRuby，您可以轻松访问Java代码，从IronPython和IronRuby，您可以轻松访问.NET代码。

在这些情况下，“利用解释器背后的编译语言”的能力可以被描述为新实施的主要动力。

Answer 3

请参阅www.lua.org上的“论文”部分。

特别是The Implementation of Lua 5.0

Lua定义了底层（ANSI C）代码中的所有标准函数。我认为这主要是出于性能原因。最近，即'string。*'函数在纯Lua中得到了另一种实现，这可能对于Lua运行在.NET或Java运行时（无法使用C代码）上的子项目至关重要。

Answer 4

只要您使用可编程代码库的可移植API（如C ++中的ANSI C standard library或STL），那么利用这些功能可以避免重新发明轮子，并可能提供更小，更快的解释器。 Lua采用这种方法，与其他许多方法相比，它确实小而快。