如果有任何語言設計者（或者只是知道的人），我對爲解釋型語言創建標準庫背後的方法感到好奇。具體來說，似乎是最好的方法？在解釋語言中定義標準函數/方法，或以編寫解釋器的編譯語言執行這些調用的處理？解釋型語言 - 利用解釋器之後的編譯語言
讓我思考這個問題的是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