如果有任何语言设计者（或者只是知道的人），我对为解释型语言创建标准库背后的方法感到好奇。具体来说，似乎是最好的方法？在解释语言中定义标准函数/方法，或以编写解释器的编译语言执行这些调用的处理？解释型语言 - 利用解释器之后的编译语言
让我思考这个问题的是SO关于Python中类似于stripslashes（）的函数的问题。我的第一个想法是“为什么不定义你自己，只是在需要时调用它”，但它提出了一个问题：对于这样一个函数，让解释的语言处理这种开销还是更好一些？编写一个扩展，并利用解释器背后的编译语言？
“解释”和“编译”语言之间的界限现在真的很模糊。例如，Python在看到源代码时所做的第一件事就是将其编译成字节码表示形式，这与Java在编译类文件时的做法基本相同。这是* .pyc文件包含的内容。然后，python运行时会执行字节码而不会引用原始源代码。传统上，纯粹的解释语言会在执行程序时连续引用源代码。
在构建语言时，建立可以实现更高级别功能的坚实基础是一种很好的方法。如果你有一个稳定，快速的字符串处理系统，那么语言设计者可以（也应该）在基本运行时之外实现诸如stripslashes（）之类的东西。这是因为至少几个原因：
仅仅因为像Python这样的语言编译为字节码并执行它并不意味着它很慢。没有理由说为什么有人不能为Python编写一个Just-In-Time（JIT）编译器，就像Java和.NET已经做的那样，以进一步提高性能。事实上，IronPython直接将Python编译为.NET字节码，然后使用.NET系统（包括JIT）运行。
要直接回答你的问题，语言设计者唯一需要在运行时使用语言来实现一个函数的时候（比如Python中的C语言）就是最大化该函数的性能。这就是为什么诸如正则表达式解析器之类的模块是用C语言而不是本地Python编写的。另一方面，像getopt.py这样的模块在纯Python中实现，因为它可以在那里完成，并且使用相应的C库没有任何好处。
传统上认为“解释”到像JVM或CLR这样的平台上的重新实现语言的趋势也在增加，然后允许轻松访问“本地”代码以实现互操作性。因此，从Jython和JRuby，您可以轻松访问Java代码，并且可以从IronPython和IronRuby轻松访问.NET代码。
在这样的情况下，“利用解释器之后的编译语言”的能力可以被描述为新实现的主要动力。
只要你在编译的代码库中使用一个可移植的API，例如C++中的ANSI C standard library或STL，那么利用这些函数就不会让你重新发明轮子，并且可能会提供更小，更快的解释器。 Lua采取这种方法，与其他许多人相比，它绝对是小而快的。
请参阅www.lua.org的'论文'部分。
特别The Implementation of Lua 5.0
的Lua限定在底层（ANSI C）的代码的所有的标准功能。我相信这主要是出于性能原因。最近，即'string。*'函数在纯Lua中得到了替代实现，这对于Lua在.NET或Java运行时（无法使用C代码）之上运行的子项目可能是至关重要的。
而不是“利用”编译语言，为什么不“利用”它或“利用它”呢？我们不要增加英文语言关键字的数量，除非我们必须:) – MarkJ 2009-01-28 12:57:15