Чем отличается компилятор от интерпретатора?

Там, кстати, каша полная.

Да нет, вроде не каша. Там в двух статьях вполне чёткое определение интерпретатора и компилятора. А также написано, что и то, и другое - разновидность транслятора.

эти трансляторы отличаются друг от друга с точки зрения метавычислений тем, что суперкомпиляция интерпретатора — это компилятор (соответстенно, остаточная программа это компилятор, исходная до суперкомпиляции и прогонки остова графа исполнения — интерпретатор).

переход от интерпретатора в компилятор это метасистемный переход к системе «компилятор тулкит + его метаязыки». результат символьного выполнения этой метасистемы — откомпилированная программа, на других языках (всё более низкого уровня), эквивалентая интерпретируемой.

см. Рефал В. Турчина или «алгебру R-вычислений» В. М. Глушков (программа как алгебра, компилируемая в железо — среди его публикаций есть такое).

см. где-то здесь или здесь

у В. М. Глушкова (или в его научной школе) было про генерацию конечных автоматов (и в итоге, аппаратных схем) из алгебры, представляющей программу (это про R-исчисление). сейчас часть про автоматы это примерно SWITCH-технология, а про алгебру программы — как раз метавычисления и суперкомпиляция.

идея с машиной «Мiр» была в том, чтобы генерировать железо из алгебры, вычисленной из программы путём символьных преобразований этой алгебры и эквивалентных преобразований.

такой «аппаратный компилятор», вплоть до синтеза нужных аппаратных схем, целевой компилятор в железо.

Видимо получается, что количество элементов в любом бесконечном счетном множестве одинаковы?

Да. Точнее мы никак не может показать, что оно неодинаково. Гугли парадокс Скулема.

В нестандартной интерпретации вполне себе ок все с бесконечностями.

Ещё раз, для тех, кто в танке: ты знаешь такую профессию «переводчик»? Ну вот компилятор/интерпретатор и есть «переводчик».

Для необразованных ебланов вроде тебя объясню совсем на палцьах, как в детском садике. Есть профессия - «переводчик». Это такой товарищ, который берет текст на одной языке (например английский) и переводит его на другой язык (например на русский).

Так вот транслятор - это переводчик. Компилятор - это транслятор (то есть переводчик). Он переводи текст с ЯП на машкод.

А есть такая профессия - «исполнитель». Это товарищ, который берет текст на некотором языке (на английском) и исполняет этот текст. При этом он его не переводит. Он вообще никаких других языков не знает (кроме английского) и по-этому перевести не может - в принципе. Потому и не переводит. Так вот интерпретатор - это исполнитель. Он не переводчик. И не транслятор, соответственно.

По-ходу, это ты еблан. Никакого исполнения нет, это удобная сказочка для тех, кто не в состоянии понять, что кроме трансляции ничего нет. Твое «исполнение» - это процесс трансляции. Надо же для недоумков что-то говорить, чтоб они хоть что-то могли написать.

Да-да, даже небо, даже аллах - все суть «исполнение».

Числа — это тоже абстракция

числа это конечно абстракция, но любое число можно сопоставить с предметами IRL. Например два яблока соответствуют абстракции 2. А вот абстракции ∞ НЕ соответствует никакое количество яблок.

Тогда определи барьеры абстракции. Озвучь общее правило, что и когда можно, а что и когда нельзя. И это должен быть не просто высер Васи Пупкина, а обоснованное правило, следующее из...

бесконечности разные бывают. Обычно определяют ∞+n=∞ (здесь n принадлежит ℝ), и некоторые другие равенства. ∞-∞ остаётся неопределённым. В матане можно ещё возводить в целую степень. Так получаются бесконечности разных порядков(и бесконечно малые, если степень <0). ∞⁰ остаётся неопределённой (или это любое конечное число, например 1).

А я недостаточно глуп, чтобы слепо доверять учебникам.

абстракция ∞ — один из полезных алгоритмов. И находит применение в разных областях. Например я успешно вычисляю время работы алгоритмов с помощью O-большого, а оно имеет смысл лишь в бесконечности. Но часто ошибка достаточно мала, и O-большое очень хорошо описывает работу реальных алгоритмов. Много практических применений бесконечности открыл ещё Архимед Over9000 лет назад. Какой смысл с этим спорить?

Я влез на твоём неверном утверждении.

вместо того, что-бы жаловаться на своё днище, просто уточнил-бы, что так только на бесконечных подмножествах(хотя это и так всем здесь очевидно).

А вот абстракции ∞ НЕ соответствует никакое количество яблок.

Ну почему, бесконечное количество яблок вполне соответствует.

бесконечное количество яблок вполне соответствует.

такого количества не бывает.

такого количества не бывает

С чего ты взял? Возможно, их не бывает одномоментно, но если взять все яблоки которые уже рождены и все те, которые родятся, то, при условии, что мир бесконечен, их будет бесконечное количество. Ну хрен с ними с яблоками. А количество атомов во вселенной, по-твоему, тоже конечно? Или даже звезд? Галактик?

А количество атомов во вселенной, по-твоему, тоже конечно?

да.

С какого хрена? Пруф будет?

но любое число можно сопоставить с предметами IRL

Ты опускаешь тот момент, что сопоставить должен кто-то, твое сопоставление субъективно, например, кто-то может сопоставить 10-ти яблокам слово «10 яблок», а кто-то «куча яблок». И любое яблоко можно разделить на произвольное количество частей, в том числе бесконечное. Поэтому, твои «числа» субъективны, они имеют отношение к реальности не больше и не меньше чем любая другая абстракция, в том числе бесконечность. Они ничем не отличаются, это просто имена твоих представлений о частях или элементах реальности. И они не «отображаются» в объективной реальности, а просто отражают твое представление о мире, полученном через чувственный опыт. Это фантом человеческого сознания, пусть даже коллективный.

Там в двух статьях вполне чёткое определение интерпретатора и компилятора.

Ну да:

«Большинство компиляторов переводит программу с некоторого высокоуровневого языка программирования в машинный код, который может быть непосредственно выполнен процессором»

Львиная доля современных реализаций языков, включая Java не подходит по это определение

«Результат компиляции — исполнимый модуль — обладает максимальной возможной производительностью, однако привязан к определённой операционной системе и процессору (и не будет работать на других)»

Опять fail.

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

В общем, как говорил, каша.

Никакого исполнения нет, это удобная сказочка для тех, кто не в состоянии понять, что кроме трансляции ничего нет.

Хаскелл головного мозга? «Мы не изменяем Мир, а транслируем его старое состояние в новое»?

В общем, как говорил, каша.

Там изначально каша. В зависимости от источника определения.

Вот, например, CLipper умеет создавать .exe файлы. Но при этом в файле присутствует полностью исходный код (так как язык динамический). Можно ли создание такого исполняемого файла (там реально запуск интепретатора с предопределёнными данными) назвать компиляцией?

Если нет, то можно ли назвать компиляцией шитый код Форта. Каждой команде Форта в соответствие ставится адрес в бинарнике и выполняется подстановка один-к-одному.

Можно ли назвать компиляцией то, что делает SBCL: читает команду, транслирует в машинный код, тут же выполняет до трансляции следующей команды?

И наоборот: преобразование кода на Java в JVM является компиляцией, а преобразование в байткод на clisp, а процесс выполнения в Питоне? Я к тому, что Java считается компилируемой (в JVM), а Питон интерпретируемым (http://ru.wikipedia.org/wiki/Python)

Хаскелл головного мозга? «Мы не изменяем Мир, а транслируем его старое состояние в новое»?

Строго наоборот. Нет никаких состояний, есть только процесс перезаписи. Я бы сказал, абсолютный нондетерменизм. Хаскель, наоборот запарен на глобальном состоянии.

Хаскель, наоборот запарен на глобальном состоянии.

Это где такое? Апологеты на ЛОРе наоборот говорят, что состояний у объектов нет, есть только функции. В качестве примера было «мы не красим холодильник в зелёный цвет, а определяем функцию, которая для холодильника возвращает такой же, но зелёный».

Нет никаких состояний, есть только процесс перезаписи. Я бы сказал, абсолютный нондетерменизм.

То есть процесс перезаписи никак не зависит от состояния на момент начала перезаписи (потому как состояния нет). Сильно!

из C в ассемблер

То есть я одним enum-ом и функцией в несколько строк целый компилятор всего си в ассемблер написал?

На самом деле это интерпретатор языка Cmd, он ни во что его не транслирует, а просто выполняет — интерпретация выполняется на таком уровне, что CPU может быть где-то очень далеко. В более сложном и реальном случае соответствия между элементами интерпретируемого языка и ассемблером тем более нет.

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

Это ты нафантазировал. Допустим, есть машинный код интерпретатора, если взять произвольную программу интерпретатора, то никакого машинного кода ей не соответствует, это просто один из его входов — его выполнению будет соответствовать такой-то control flow интерпретатора (который в машинном коде интерпретатора не локализирован даже); соответствие может дать именно компилятор — совсем другая вещь (ты так рассказываешь, будто интерпретаторы вдруг превратились в компиляторы, тогда как связи нет, ну и изначально были (алгебраические) компиляторы — FORTRAN например, а LISP был исключением... наверное :)).

70х годах прошлого века

вместо деления на 3 умножать на 0x5555

mov ax,3; div

gcc -S any_shit.c; cat any.shit.s

Ты в своём репертуаре :)

То есть процесс перезаписи никак не зависит от состояния на момент начала перезаписи

Он зависит с одной точки зрения и не зависитт с другой. Например, если ты рассуждаешь о красоте звездного неба, какое тебе дело до того, что на момент конца твоих рассуждений ты наблюдаешь уже нге то небо, про которое начал рассуждать, ибо там все движется и изменяется каждую секунду. Программист должен уметь абстрагироваться от изменений, когда нужно, и думать об изменениях в других случаях. Специальных средств языка для этого не нужно. Срать, что что-то там меняется. Дрочить на иммутабельность в данном контексте - значит не понимать сути программирования. Но хаскель-дрочерство на иммутабельность помогают эффективно компилировать код, поэтому хаскель-дрочеры тоже нужны.

ℕ ⊊ ℤ, |ℕ| = |ℤ| = ℵ₀.

Или ты про «счётные» вместо «счётно-бесконечные»?

есть только функции

В хашкеле ф-ции — это замыкания, они эквивалентны объектам в классовом ООП. Что они там себе мнят — это их проблемы.

Или ты про «счётные» вместо «счётно-бесконечные»?

Счетные — это всегда (только лишь) бесконечные.

Вот, например, CLipper умеет создавать .exe файлы. Но при этом в файле присутствует полностью исходный код (так как язык динамический). Можно ли создание такого исполняемого файла (там реально запуск интепретатора с предопределёнными данными) назвать компиляцией?

Если при исполнении происходит парсинг именно исходного кода — то однозначно интерпретация. То, что исходный код с транслятором пакуется в исполняемый файл тут к делу не относится.

Если нет, то можно ли назвать компиляцией шитый код Форта.

Вариант с шитым кодом — это компиляция исходного кода + интерпретация периода исполнения. То же самое, что сегодня делается в львиной доле языков мейнстрима от Java до PHP.

Можно ли назвать компиляцией то, что делает SBCL: читает команду, транслирует в машинный код, тут же выполняет до трансляции следующей команды?

Я не знаю этого механизма. Вот 20+ лет назад использовали формальный признак, который позволяет легко избежать всех этих непоняток — если происходит трансляция перед исполнением всего кода и потом исполнение результата, то это компиляция. Если трансляция происходит по мере парсинга — то интерпретация. Пробный камень для понимания — циклы. У компилятора, поскольку трансляция происходит перед запуском, трансляция тела цикла происходит один раз. У интерпретатора трансляция происходит на каждой итерации.

И наоборот: преобразование кода на Java в JVM является компиляцией

Да.

а преобразование в байткод на clisp

? Не распарсил.

а процесс выполнения в Питоне?

В Питоне используется та же история, что в Java — компиляция исходника в байткод и интерпретация байткода при исполнении (в варианте без JIT, с JIT, соответственно, промежуточная вторая компиляция байткода в машинный)

Я к тому, что Java считается компилируемой (в JVM), а Питон интерпретируемым

Если кто-то Питон считает интерпретируемым, он ошибается. Как я написал, это компиляция в байткод + интепретация/компиляция байткода (в зависимости от реализации) при исполнении.

Те, кто писал про Python-интерпретатор видели ли файлы *.pyc? :)

Если кто-то Питон считает интерпретируемым, он ошибается.

А есть ли сейчас мейнстримные интерпретируемые ЯП (shell - не в счет), кроме тикля?

http://www.amazon.com/Concepts-Techniques-Models-Computer-Programming/dp/0262...

An alternative to the translation approach is the interpreter approach.

http://www.amazon.com/Programming-Language-Pragmatics-Third-Edition/dp/012374...

The compiler translates the high-level source program into an equivalent target program (typically in machine language) and then goes away.

An alternative style of implementation for high-level languages is known as interpretation.

Unlike a compiler, an interpreter stays around for the execution of the application. In fact, the interpreter is the locus of control during that execution. In effect, the interpreter implements a virtual machine whose “machine language” is the high-level programming language. The interpreter reads statements in that language more or less one at a time, executing them as it goes along.

We generally say that a language is “interpreted” when the initial translator is simple.

Most interpreted languages employ an initial translator (a preprocessor) that removes comments and white space, and groups characters together into tokens, such as keywords, identifiers, numbers, and symbols. The translator may also expand abbreviations in the style of a macro assembler. Finally, it may identify higher-level syntactic structures, such as loops and subroutines. The goal is to produce an intermediate form that mirrors the structure of the source but can be interpreted more efficiently.

In some very early implementations of Basic, the manual actually suggested removing comments from a program in order to improve its performance. These implementations were pure interpreters; they would reread (and then ignore) the comments every time they executed a given part of the program. They had no initial translator.

http://www.amazon.com/Design-Concepts-Programming-Languages-Franklyn/dp/02622...

Issues of semantics and pragmatics are important for reasoning about properties of programming languages and about particular programs in these languages. We will also discuss them in the context of two fundamental strategies for programming language implementation: interpretation and translation. In the interpretation approach, a program written in a source language S is directly executed by an S-interpreter, which is a program written in an implementation language. In the translation approach, an S program is translated to a program in the target language T , which can be executed by a T -interpreter. The translation itself is performed by a translator program written in an implementation language. A translator is also called a compiler, especially when it translates from a high-level language to a low-level one.

Счетные — это всегда (только лишь) бесконечные.

Нет (следует читать как — можно встретить литературу в которой A счётно iff |A| <= aleph_0).

В качестве примера было «мы не красим холодильник в зелёный цвет, а определяем функцию, которая для холодильника возвращает такой же, но зелёный».

ИМХО, это эквивалентно присваиванию, при условии, что мы будем обращаться к «зеленому холодильнику» только через эту ф-цию. Семантически эквивалентно, я имею в виду. Это, видимо то, что называется монадами у них?

Я про утверждение

A ⊂ ℕ => |A| = |ℕ|

Или ты про «счётные» вместо «счётно-бесконечные»?

«Счётные» это не несчётные, как английское countable?

Счетные, дубинушка, это те бесконечные, чьи элеменеты можно пронумеровать натуральными числамию

«Счётные» это не несчётные, как английское countable?

Да, я с английским вариантом перепутал (там используется как счётное и как не несчётное).

Я про утверждение

Тогда непонятно — его же никто не утверждал? Если «счётные» (про них же говорили) = «изоморфные NNO».

Countable Set - A set which is either finite or denumerable.

Совсем анонимы дурные пошли, уже с чужими определениями спорить собираются.

Никто.

Если английский термин переводимый калькой не соответствует смыслу определения, нахрена ты его сюда суешь?

Ну там ветка началась с натуральных (счётных) и подмножества чётных (тоже счётных). Ему достаточно было сказать во множественном числе, я не думаю, что он считает финитные и счётные множества равномощными :)

Хорошь дурочку валять, всем ясно, что ты попутал счетные множества с конечными, лапуся. Обтекай.

Если кто-то Питон считает интерпретируемым, он ошибается.

Все как было 20 лет назад так и осталось.

Определения:

Человек он же человек разумный он же homo sapiens... Тип: Хордовые. Класс: Млекопитающие. Отряд: Приматы. Семейство: Гоминиды. Род: Люди. Вид: Человек разумный.

Машина - совокупность из некой операционной системы выполняющейся в неком процессоре и на неком железе в вакууме...

В мире есть исключительно интерпретатор или компилятор всё остальное дерьмо от лукавого следовательно дружно идет в сраку и далее не рассматривается ибо оно несущественно а почему именно читай дальше.

«Исходный код» программы - то что мы имеем на входе интерпретатора/компилятора. Как правило исходный код человекочитаемый формат записи в отличие от так называемой «бинарной формы». Т.е. человеку его читать и понимать гораздо проще чем машине.

«Бинарная форма» программы - собранная из исходного кода компилятором форма представления программы в операционной системе. Трудно читаемая человеком однако прекрасно читаемая операционной системой/процессором/машиной...

«Полезная работа» программы - все совершаемые действия программы в «машине» ради которых она собственно и создана.

Интерпретатор - транслирует исходный код в набор команд машины представляя результат своей работы в виде необходимой полезной работы. На входе исходный код. На выходе имеем необходимую полезную работу.

Компилятор - транслирует исходный код в набор команд машины представляя результатом своей работы бинарную форму представления исходного кода. На входе исходный код. На выходе бинарная форма представления исходного кода которая при своем запуске совершает необходимую полезную работу.

И теперь исходя из определений...

Если программа представлена в виде человекочитаемого текста и для совершения полезной работы постоянно пользуется услугами интерпретатора то это одна история.

А если программа из человекочитаемого исходного кода преобразована при помощи компилятора в бинарную форму которая в свою очередь и совершает полезную работу то это уже совсем другая история.

И вот дальше уже несущественно есть ли там байткод/JIT/или еще какое дерьмо или их нет вовсе... Просто плевать потому что либо мы имеем некую сущность которая будучи единожды превращенная в бинарную форму сама по себе умеет совершать необходимую полезную работу либо мы имеем сущность которая для совершения полезной работы постоянно нуждается в интерпретаторе и без него она беспомощна.

сама по себе умеет совершать необходимую полезную работу

сама по себе умеет

Нет. Эта сущность беспомощна без процессора, который проинтерпретирует машинный код.

Интерпретатор — это программа, которая ведёт себя как другая программа.

Компилятор — это частный случай транслятора: транслятор в (существенно) более низкоуровневный язык.

Интерпретатор - транслирует исходный код в набор команд машины представляя результат своей работы в виде необходимой полезной работы. На входе исходный код. На выходе имеем необходимую полезную работу.

Компилятор - транслирует исходный код в набор команд машины представляя результатом своей работы бинарную форму представления исходного кода. На входе исходный код. На выходе бинарная форма представления исходного кода которая при своем запуске совершает необходимую полезную работу.

Определения не совсем правильные.

Интерпретатор — это исполнитель. Как правило, интепретатором называют исполнителя, реализованного программно, чтобы отличать от аппаратных исполнителей.
Но, например, система команд x86 в современных CPU тоже реализуется программно. Поэтому, с теоретических позиций, CPU по отношению к этой системе команд - интепретатор. Хоть на практике мы его так и не называем.

Компилятор — переводчик с языка одного исполнителя на язык другого исполнителя.

Вообще весь этот тред не имеет никакого смысла, потому что интерпретатор и компилятор — это всего лишь РОЛЬ по отношению к чему-либо. А не жесткий ярлык, который пытаются навесить некоторые.

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

По отношению к сорцу в файлике, /usr/bin/python, безусловно, - интерпретатор. Это его РОЛЬ. Мы запускаем /usr/bin/python, чтобы получить результаты вычисления входной программы, а не чтобы получить её перевод в машкод или еще какой-нибудь язык.

В то же время, если мы рассмотрим работу /usr/bin/python изнутри, часть его являтся компилятором по отношению ко входному языку, а часть - интерпретатором байт-кода.

Те, кто писал про Python-интерпретатор видели ли файлы *.pyc? :)

Ты на простой вопрос ответь. Ты python запускаешь, чтобы получить результаты вычисления входной программы или чтобы перевести её на другой язык?

В этом СУТЬ.

Нет. Эта сущность беспомощна без процессора, который проинтерпретирует машинный код.

Нет любая «сущность беспомощна без процессора, который проинтерпретирует машинный код».

числа это конечно абстракция, но любое число можно сопоставить с предметами IRL. Например два яблока соответствуют абстракции 2. А вот абстракции ∞ НЕ соответствует никакое количество яблок.

А какоеколичество яблок соответствуе тчислу Pi+e*i?

Ты python запускаешь, чтобы получить результаты вычисления входной программы или чтобы перевести её на другой язык

Если файл в параметре библиотека, то чтобы получить .pyc для дальнейшего распростарнения.

И если я к gcc добавлю принудительный запуск скомпилированного файла, то он станет интерпретатором?

Файлы .pyc можно выполнять без .py. Например коммерческие модули так и распространяются.

Вариант с шитым кодом — это компиляция исходного кода + интерпретация периода исполнения.

Только интерпретация процессором. Шитый код — код на ассемблере выглядящий как

push 2
call dup
call plus
call dot
call ...

То есть литералы переводятся в push, а всё остальное в call.

Пробный камень для понимания — циклы. У компилятора, поскольку трансляция происходит перед запуском, трансляция тела цикла происходит один раз. У интерпретатора трансляция происходит на каждой итерации.

У SBCL единица трансляции — форма верхнего уровня. Она может быть любой командой Lisp. Цикл (весь) всегда является одной формой, поэтому будет компилироваться целиком. Но если, скажем в программа выглядит как

(defvar *a* (load-from-file "..."))
(loop :for i :in *a* :do ...)
(undefinde-symbol)

То сначала скомпилируется загрузка переменной *a* и выполнится чтение из файла, потом скомпилируется и выполнится цикл. А потом выяснится, что третья команда скомпилироваться не может и будет ошибка компиляции. И как это считать? Для каждой отдельной формы — компиляция, для файла целиком — интерпретация?

Если кто-то Питон считает интерпретируемым, он ошибается

The Python interpreter and the extensive standard library are freely available in source or binary form for all major platforms from the Python Web site (c) https://docs.python.org/3/tutorial/index.html

Те, кто писал про Python-интерпретатор видели ли файлы *.pyc

Писали разработчики Питона. И генерацию тех файлов тоже они писали...