Интерпретируемые языки - использование скомпилированного языка, стоящего за интерпретатором
https://stackoverflow.com/questions/13586
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Если там есть какие-нибудь разработчики языков (или просто знающие люди), мне было бы любопытно узнать о методологии создания стандартных библиотек для интерпретируемых языков.В частности, какой подход кажется наилучшим?Определение стандартных функций / методов на интерпретируемом языке или выполнение обработки этих вызовов на скомпилированном языке, на котором написан интерпретатор?
Что заставило меня задуматься об этом, так это вопрос SO о функции, подобной stripslashes() в Python.Моей первой мыслью было "почему бы не определить свой собственный и просто вызвать его, когда вам это нужно", но это вызвало вопрос:предпочтительно ли для такой функции позволить интерпретируемому языку обрабатывать эти накладные расходы, или было бы лучше написать расширение и использовать скомпилированный язык за интерпретатором?
Решение
Грань между "интерпретируемыми" и "скомпилированными" языками в наши дни действительно размыта.Например, первое, что делает Python, когда видит исходный код, - это компилирует его в представление байт-кода, по сути, то же самое, что делает Java при компиляции файлов классов.Это то, что содержат файлы *.pyc.Затем среда выполнения python выполняет байт-код без ссылки на исходный код.Традиционно чисто интерпретируемый язык постоянно ссылался бы на исходный код при выполнении программы.
При создании языка хорошим подходом является создание прочной основы, на которой вы можете реализовать функции более высокого уровня.Если у вас надежная и быстрая система обработки строк, то разработчик языка может (и должен) реализовать что-то вроде stripslashes() вне базовой среды выполнения.Это делается по крайней мере по нескольким причинам:
- Разработчик языка может показать, что язык достаточно гибкий, чтобы справиться с такого рода задачами.
- Разработчик языка фактически пишет реальный код на этом языке, который имеет тесты и, следовательно, показывает, что основа прочна.
- Другим людям легче читать, заимствовать и даже изменять функции более высокого уровня без необходимости создавать или даже понимать ядро языка.
Просто потому, что такой язык, как Python, компилируется в байт-код и выполняется, это не значит, что он медленный.Нет причин, по которым кто-то не мог бы написать JIT-компилятор точно в срок для Python, аналогичный тому, что уже делают Java и .NET, для дальнейшего повышения производительности.Фактически, IronPython компилирует Python непосредственно в байт-код .NET, который затем запускается с использованием системы .NET, включая JIT.
Чтобы ответить на ваш вопрос напрямую, единственный раз, когда разработчик языка реализует функцию на языке, стоящем за средой выполнения (например.C в случае Python) заключалось бы в максимизации производительности этой функции.Вот почему такие модули, как анализатор регулярных выражений, написаны на C, а не на родном Python.С другой стороны, модуль, подобный getopt.py, реализован на чистом Python, потому что все это можно сделать там, и нет никакой пользы в использовании соответствующей библиотеки C.
Другие советы
Также наблюдается растущая тенденция переопределения языков, которые традиционно считаются "интерпретируемыми", на платформе, подобной JVM или CLR, а затем обеспечения легкого доступа к "собственному" коду для обеспечения совместимости.Таким образом, из Jython и JRuby вы можете легко получить доступ к Java-коду, а из IronPython и IronRuby вы можете легко получить доступ к .NET-коду.
В подобных случаях способность "использовать скомпилированный язык за интерпретатором" можно было бы описать как основной мотиватор для новой реализации.
Смотрите раздел "Документы" по адресу www.lua.org.
Особенно Реализация Lua 5.0
Lua определяет все стандартные функции в базовом коде (ANSI C).Я полагаю, что это в основном из соображений производительности.Недавно, т.е.функции 'string.*' получили альтернативную реализацию в чистом Lua, что может оказаться жизненно важным для подпроектов, где Lua выполняется поверх .NET или Java runtime (где C-код не может быть использован).
Пока вы используете переносимый API для скомпилированной базы кода, такой как Стандартная библиотека ANSI C или STL в C ++ использование преимуществ этих функций удержало бы вас от изобретения колеса и, вероятно, обеспечило бы меньший по размеру и более быстрый интерпретатор. Lua использует этот подход, и он определенно маленький и быстрый по сравнению со многими другими.
