Интерпретируемые языки-использование скомпилированного языка за интерпретатором

В наши дни граница между "interpreted" и "compiled" языками очень размыта. Например, первое, что делает Python, когда он видит исходный код, - это компилирует его в представление байт-кода, по существу то же самое, что делает Java при компиляции файлов классов. Вот что такое *.файлы pyc содержат. Затем среда выполнения python выполняет байт-код без ссылки на исходный источник. Традиционно чисто интерпретируемый язык будет постоянно ссылаться на исходный код при выполнении программы.

При построении языка, это хороший подход, чтобы построить прочную основу, на которой вы можете реализовать функции более высокого уровня. Если у вас есть надежная, быстрая система обработки строк, то языковой дизайнер может (и должен) реализовать что-то вроде stripslashes() вне базовой среды выполнения. Это делается по крайней мере по нескольким причинам:

• Конструктор языков может показать, что язык достаточно гибок, чтобы справиться с такой задачей.
• Языковой конструктор фактически пишет реальный код на языке, который имеет тесты и поэтому показывает, что фундамент является прочным.
• Другие люди могут более легко читать, заимствовать и даже изменять функцию более высокого уровня, не имея возможности построить или даже понять ядро языка.

Просто потому, что язык, подобный Python, компилируется в байт-код и выполняет его, это не значит, что он медленный. Нет никакой причины, по которой кто-то не мог бы написать компилятор Just-In-Time (JIT) для Python, подобно тому, что уже делают Java и .NET, чтобы еще больше увеличить производительность. Фактически, IronPython компилирует Python непосредственно в байт-код .NET, который затем запускается с использованием системы .NET, включая JIT.

Чтобы ответить на ваш вопрос напрямую, единственный раз, когда языковой дизайнер будет реализовывать функцию на языке, находящемся за средой выполнения (например. C в случае Python) будет заключаться в максимальном выполнении этой функции. Именно поэтому такие модули, как анализатор регулярных выражений, пишутся на языке C, а не на языке native Python. С другой стороны, такой модуль, как getopt.py, реализован в чистом Python, потому что все это можно сделать там, и нет никакой пользы в использовании соответствующей библиотеки C.

Существует также растущая тенденция к реимплементации языков, которые традиционно считаются "interpreted", на платформу, подобную JVM или CLR , а затем обеспечивают легкий доступ к коду "native" для обеспечения совместимости. Таким образом, из Jython и JRuby вы можете легко получить доступ к коду Java, а из IronPython и IronRuby вы можете легко получить доступ к коду .NET.

В подобных случаях способность к "leverage the compiled language behind the interpreter" может быть описана как основной мотиватор для новой реализации.

Смотрите раздел 'Papers' на странице www.lua.org .

Особенности реализации Lua 5.0

Lua определяет все стандартные функции в базовом коде (ANSI C). Я считаю, что это в основном из соображений производительности. В последнее время, т. е. строку.* 'функции получили альтернативную реализацию в чистом Lua, что может оказаться жизненно важным для подпроектов, где Lua выполняется поверх .NET или Java среды выполнения (где код C не может быть использован).

Пока вы используете портативный API для скомпилированной кодовой базы, такой как стандартная библиотека ANSI C или STL в C++, то использование этих функций удержит вас от изобретения колеса и, вероятно, обеспечит меньший и более быстрый интерпретатор. Lua использует этот подход, и он определенно мал и быстр по сравнению со многими другими.