Lisp vs Python-статическая компиляция

Почему Lisp со всеми его динамическими функциями может быть статически скомпилирован, но Python не может (без потери всех своих динамических функций)?

4 ответов


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

тем не менее, исследования показывают, что большинство программ Python, в то время как динамические при статическом анализе, довольно статичны и мономорфны во время выполнения. Это означает, что подходы к компиляции JIT во время выполнения работа намного лучше на программах Python. См.unladen-swallow, PyPy, Psyco для подходов, которые компилируют Python в машинный код. Но также IronPython и Jython, которые используют виртуальные машины, первоначально предназначенные для статических языков для компиляции Python в machinecode.


для чего это стоит, скрипты Python are компилируется в .pyc-файлы при выполнении, см. "скомпилированные" файлы Python.

вы также можете использовать такой инструмент, как py2exe для компиляции программы Python в исполняемый файл.


на самом деле нет ничего, что мешает вам статически компилировать программу Python, просто до сих пор никто не написал такой компилятор (я лично считаю, что среда выполнения Python очень проста по сравнению с CL).

вы можете сказать, что разница заключается в деталях, таких как "сколько времени было потрачено на написание компиляторов и имеет ли язык формальную спецификацию того, как писать".

давайте рассмотрим эти моменты:

  1. Лисп компиляторы развиваются уже более 40 лет, причем работа начинается еще в 70-х годах, если не раньше (я не уверен в своих датах, слишком ленивые слишком точные google). Это создает огромный кусок знаний о том, как писать компилятор. OTOH, Python был номинально разработан как" обучающий язык", и как такие компиляторы не были так важны.
  2. отсутствие спецификации-Python не имеет ни одного источника, указывающего точную семантику языка. Конечно, вы можете указать на PEP документы, но это все равно не меняет того факта, что единственная реальная спецификация является источником основной реализации,CPython. Который, nota bene, является простым компилятором (в байт-код).

Что касается возможности-Python использует довольно простую структуру для работы с символами и т. д., а именно его словари. Вы можете рассматривать их как таблицу символов программы. Вы можете пометить типы данных, чтобы распознать примитивные и получить остальные на основе сохраненных имен и внутренняя структура. остальная часть языка также довольно проста. Единственный бит отсутствует фактическая работа по его реализации и заставить его работать правильно.


Python может быть "скомпилирован", где компиляция рассматривается как перевод с одного полного языка Тьюринга (исходный код) на другой (объектный код). Однако в Lisp объектом является сборка, что теоретически возможно с Python (доказано), но не возможно.

истинная причина менее уплощение. Lisp во многих отношениях революционный язык, который впервые в своих диалектах много функций на языках программирования, к которым мы привыкли сегодня. В шепелявит однако они просто "следовать" логическим основам языка. Язык, который вдохновлен необработанными выразительными способностями lisps, такими как JavaScript, Ruby, Perl и Python, обязательно интерпретируется, потому что получить эти функции на языке с "Алгол-подобным синтаксисом" просто сложно.

Lisp получает эти функции от "homo-iconic" нет существенной разницы между программой lisp и структурой данных lisp. Программы Lisp-это структуры данных, они структурные описания программы в таком s-выражении, если хотите, поэтому скомпилированная программа lisp эффективно "интерпретирует себя" без необходимости лексера и всего этого, программа lisp может рассматриваться как ручной ввод дерева синтаксического анализа. Что требует синтаксиса, с которым многие люди считают контр-интуитивным для работы, поэтому было много попыток перенести необработанную выразительную силу парадигмы на более читаемый синтаксис, что означает, что он неосуществим, но не невозможно, скомпилировать его к сборке.

кроме того, компиляция Python в сборку, возможно, будет медленнее и больше, чем "половина интерпретации" на виртуальной машине, многие функции в python зависят от синтаксического анализа.

выше, хотя написано огромным поклонником lisp, имейте в виду этот конфликт интересов.