"Нет такой вещи, как" скомпилированный язык "или" интерпретируемый язык ". Независимо от того, хочет ли разработчик языка писать компилятор, интерпретатор или что-то среднее между деталями реализации и не имеет ничего общего с языком."
Является ли приведенное выше утверждение истинным?
Да, это верно в строжайшей интерпретации. Вы можете найти С++-интерпретатор и Javascript-компилятор, например. Тем не менее, вы обнаружите, что некоторые типы языков (например, статически типизированные) хорошо подходят для компиляции собственного кода. Другие языки (например, динамически типизированные) обычно реализуются с использованием компиляции байт-кода в сочетании с средой выполнения виртуальной машины.
Сорт. Как правило, оба интерпретатора и компиляторы сначала должны разбирать исходный код и превращать его в представление, называемое AST (абстрактное дерево syntaxt). Затем компилятор превращает AST в исполняемый код (через различные преобразования), в то время как интерпретатор может просто "интерпретировать" AST, а иногда компилировать и выполнять его (компиляция точно в момент времени).
Утверждение верно, поскольку это не имеет никакого отношения к языку: теоретически вы можете написать интерпретатор и компилятор для любого языка. Какой из них действительно зависит от прецедента, сценария и среды.
Преимущество компилятора состоит в том, что ему нужно выполнять только одно задание, независимо от того, как часто вы выполняете программу. Интерпретатору необходимо каждый раз анализировать источник (или делать некоторое кеширование), поэтому у вас есть накладные расходы для каждого исполнения, которое может занять больше времени, чем фактическое время выполнения окончательной программы. С другой стороны, интерпретатор более гибкий (он может принимать в сумме текущую среду и, следовательно, делать оптимизации, которые компилятор не разрешает делать). Но различия здесь не останавливаются, это всего лишь два очевидных момента.
Языковой дизайн связан с грамматикой для входной части более высокого уровня и кода выхода более низкого уровня, который выполняется на целевой.
Там есть абстрактное синтаксическое дерево между ними.
Традиционно, если вы записываете код вывода более низкого уровня для выполнения на определенной аппаратной платформе и ее конкретном наборе команд, вывод "компилируется".
Если кто-то решает написать интерпретатор для работы в качестве цели, выходной код представляет собой набор команд или байтовый код, который ожидает интерпретатор. Дополнительный уровень косвенности означает, что интерпретируемый код может работать на любой аппаратной платформе, которая имеет реализацию интерпретатора.
Таким образом, утверждение корректно, если мы назовем "языковой дизайн" грамматикой и лексер/парсером.
Это не совсем правильно, если мы говорим о генераторе кода.
Возможно испускать определенный язык, как интерпретируемый, так и скомпилированный просто путем вызова разных генераторов кода для перехода в AST.
Итак, возможно, что различие размыто. Но я думаю, что он все еще там.
Вышеуказанное утверждение верно.
Опять же, можно утверждать, что это недостаточно верно в реальном мире. Если все существующие реализации языка полагаются на компиляцию, язык можно законно называть компилируемым языком.
Истина только в том смысле, что в конечном итоге как скомпилированные, так и интерпретируемые языки должны генерировать машинный код. Это влияет на язык, поскольку традиционно определенные парадигмы легче в одном над другим. Например, в общем случае блокировки или блоки проще реализовать на языках с несколькими языками, чем скомпилированные языки. Это верно, так как фактически нет разницы между временем компиляции и временем выполнения в интерпретируемых языках. Таким образом, динамические диапазоны TENDS легче реализовать на интерпретируемых языках.
Данная реализация языка будет либо "чистым" компилятором (выход которого выполняется процессором как код), "чистым" интерпретатором (каждый оператор рассматривается впервые, в форме исходного источника, как он выполняется, и ничего об интерпретации не кэшируется), или гибрид между ними. Очень легко отличить "чистые" случаи от гибридов, но некоторые гибриды "ближе" к компиляции, чем другие; линии между "скомпилированным" гибридом и "интерпретированным" могут быть довольно нечеткими.
Я не думаю, что какой-либо язык в значительной степени используется, кроме языка ассемблера (для которого термин "ассемблер" обычно используется в предпочтении "компилятор" ), который не может быть реализован, по крайней мере, практически в гибридной интерпретатор (исполнение "чистого" интерпретатора может быть ужасным с любыми, но самыми тривиальными циклами). Однако существуют некоторые языки, которые позволяют генерировать динамическое кодирование способами, которые не поддаются компиляции.
Кстати, когда я говорю "форма исходного источника", я не всегда имею в виду текстовый формат. У моего первого программируемого калькулятора было 99 программных шагов, каждый из которых мог быть сконфигурирован с нажатием клавиши или одной из нескольких специальных инструкций последовательности. Программа никогда не существовала бы в форме, удобной для восприятия человеком, как таковой, а скорее как последовательность номеров ключей. Тем не менее, я бы описал это как чисто интерпретируемый "язык", поскольку каждый программный шаг оценивался полностью независимо.
Вся работа компилятора/интерпретатора зависит от ваших намерений для вашей программы. Скомпилированная программа - это программа, которая превращается в машинный код. Интерпретатор используется для чтения языка-посредника и запуска его на машине. Например, при компиляции Java он превращается в Java Bytecode и считывается и запускается интерпретатором (что также объясняет недостаток скорости по сравнению с С++).
Я действительно не думаю, что ваше утверждение об этом не имеет никакого отношения к этому языку. Одна из главных особенностей Java заключается в том, что она должна быть запущена на разных архитектурах. Если бы он был скомпилирован, это было бы невозможно.
Стоит отметить, что для (некоторых?) языков, включающих оператор типа "eval" (особенно если невозможно определить до тех пор, пока не будет определено, является ли данный блок кодом или данными), даже самая чисто скомпилированная версия данная программа должна быть частично интерпретирована. Для таких языков невозможно полностью их компилировать (скомпилированный код должен содержать интерпретатор для языка).
В качестве примера рассмотрим следующий код:
set s [eval {sum $a $b $c}]
Для вышеуказанного кода Tcl невозможно определить, будет ли блок (внутри {}) кодом или нет.