>Язык - не компилирует!!!

Читат умеешь? - http://www.linux.org.ru/jump-message.jsp?msgid=2787592&cid=2788334 (и т.п. не раз уже только в этой теме)

> В чём? На уровне языков, а не реализаций.

Я имел в виду классические реализации, например gcc и sun java compiler. Языки вообще не бывают компилируемые или интерпретируемые. Просто утомляет каждый раз подчёркивать, что речь идёт про реализацию.

>В конце концов, Гвидо может быть и прав :D

Нет, ибо ситуация с CPython - совершенно однозначная :)

>Я имел в виду классические реализации

Ну тогда про них и говори :) Да, у gcc и sun-jdk концептуальная разница. Но это вопрос реализаций, а не языка.

>Просто утомляет каждый раз подчёркивать, что речь идёт про реализацию.

В данном случае это, как раз, концептуально важно уточнить ;) А то в этой теме очень разные по уровню люди есть, и кто-то искренне может сравнивать концепции Си++ и Java как языков в целом, смешивая языки и реализации :)

Администрация зоопарка предупреждает, перекармливание тролей может привести к расстройству их пищеварения и загрязнению продуктами жизнедеятельности всей прилегающей территории.

> Возьмём Си++ на ZX-Spectrum.

На ZX-Spectrum С++ не было.

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

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

истину глаголишь.

>На ZX-Spectrum С++ не было.

Хорошо, возьмём Hisoft C. Или HiSoft Pascal. Или Zeus-ассемблер :)

Возьмём компиляторы БК-0010.

Наконец, запустим MacOS в PearPC.

Суть-то не в деталях, а в принципе.

>Языки вообще не бывают компилируемые или интерпретируемые

Бывают. В языке C существует множество конструкций препроцессор, квалификаторы типов, и т. д., котрые ориентированы на компиляцию в машинный код. Так что C - компилируемый язык.

Perl позволяют генерацию кода на нем же в строковую переменную и динамический вызов интерпретатора (eval). Так что Perl - интерпретируемый язык.

>Все, что создает из исходного кода машинный код, способный исполняться непосредственно процессором есть компилятор

То есть транслятор, создающий машинный код Z80 при исполнении этого кода на x86 в эмуляторе компилятором быть перестаёт? :)

...

Вот и дождались того, о ком я говорил выше :D

>Все, что _программно_ исполняет поток команд или операторов, есть интерпретатор

Я и говорю, что нынешние x86 процессоры - все интерпретаторы.

>В языке C существует множество конструкций препроцессор, квалификаторы типов, и т. д., котрые ориентированы на компиляцию в машинный код. Так что C - компилируемый язык.

Так и запишем, человек Си-интерпретаторов никогда не видел :) Но от этого они существовать не перестают.

>Perl позволяют генерацию кода на нем же в строковую переменную и динамический вызов интерпретатора (eval). Так что Perl - интерпретируемый язык.

А если я из сишной программы вызову через exec gcc и скомпилирую исходный код - Си станет интерпретатором? :)

Или у тебя каша в голове ещё больше и кроме компиляторов, интерпретаторов и сред исполнения там смешались ещё и компиляторы как программные продукты? :)

> ситуация с CPython - совершенно однозначная :)

Конечно. CPython - это компилятор Python->байткод и интерпретатор байткода (pure Python библиотеки, строго говоря, не специфичны для CPython). Поскольку интерпретатор является самым важным и сложным компонентом, Гвидо ссылается на весь CPython как на "интерпретатор" ;)

> В языке C существует множество конструкций препроцессор, квалификаторы типов, и т. д., котрые ориентированы на компиляцию в машинный код. Так что C - компилируемый язык.

По C Interpreter сам погуглишь? Максимум что ты можешь утверждать, это ориентацию на компиляцию. Этакий хинт разработчику. Не более.

> Perl позволяют генерацию кода на нем же в строковую переменную и динамический вызов интерпретатора (eval). Так что Perl - интерпретируемый язык.

Практически любой лисп умеет eval. Практически любой лисп умеет компилироваться в машинный код. И?

> Если при исполнении тело цикла транслируется каждый раз по новой - это интерпретатор.

То есть, если транслятор парсит исходник и _одновременно_ его исполняет, это - интерпретатор, а если _сначала_ парсит, а _потом_ исполняет, то это - компилятор, так что ли? :)

По теме: "Основатель Google Сергей Брин: "Microsoft делала много плохих вещей в Америке" (http://hitech.newsru.com/article/20May2008/BRIN)

ну до маразма-то доходить не надо..

> То есть транслятор, создающий машинный код Z80 при исполнении этого кода на x86 в эмуляторе компилятором быть перестаёт? :)

нет, не перестаёт. он при этом _напрямую_ исполняется на виртуальном процессоре эмулятора. с точки зрения системы внутри виртуальной машины это реальный процессор

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

Интересный факт тут пожалуй единственный - Google не собирается ратифицировать Affero GPL!

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

>Практически любой лисп умеет eval. Практически любой лисп умеет компилироваться в машинный код. И?

Интересно посмотреть на работу eval в скомпилированном бинарнике.

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

>Поскольку интерпретатор является самым важным и сложным компонентом, Гвидо ссылается на весь CPython как на "интерпретатор" ;)

Этот вариант я в списке возможных причин рассматривал :)

Лучше скажите, правда ли что Google использует Plan 9?

>По C Interpreter сам погуглишь? Максимум что ты можешь утверждать, это ориентацию на компиляцию. Этакий хинт разработчику. Не более.

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

>То есть, если транслятор парсит исходник и _одновременно_ его исполняет, это - интерпретатор, а если _сначала_ парсит, а _потом_ исполняет, то это - компилятор, так что ли? :)

Именно так. Даже сохранение в промежуточный код в явном виде не обяательно.

Вообще-то, когда-то этому любой учебник по программированию учил. Более точную формулировку я выше указывал: http://www.linux.org.ru/jump-message.jsp?msgid=2787592&cid=2788293

>По теме:

Не замусоривайте тред

>нет, не перестаёт. он при этом _напрямую_ исполняется на виртуальном процессоре эмулятора

А в Питоне байткод напрямую исполняется на виртуальном процессоре Питона.

>питоновские проги напрямую на процессоре исполнить нельзя.

Зато, например, Java может напрямую на Java-процессоре исполняться.

> вот когда будет компилятор питона в машинный код

Тогда Питон волшебным образом превратится в компилятор? :D Сам-то понимаешь, какую чушь морозишь? :D Наличие или отсутствие совершенно независимого явления меняет суть определения?

>а пока это компилятор в байткод и интерпретатор байткода

А я где-то утверждал обратное? :D Как раз ты этому утверждению только что противоречил... Вообще, что творится в голове того, кто допускает формулировку: «вот когда будет компилятор питона в машинный код, тогда это будет компилятор. а пока это компилятор в ...» ? :)

...

В общем, ещё один «нативкодник» дэтектед. Нараз вычисляются люди, не знакомые ни с чем, кроме x86.

>Там компилятор в стандартной библиотеке.

ага. копилит евал в сошник, а потом грузит длопеном. может все-таки интерпретатор?

>Интересно посмотреть на работу eval в скомпилированном бинарнике.

Возьми SP-Forth. И посмотри, как натуральнейший нативный скомпилированный в машкод бинарник выполняет на Форте команду EVALUATE :)

Честное слово, люди, мир программирования - очень богат, и полезно знать котя бы немного за пределами x86, gcc и википедии :)

> >То есть, если транслятор парсит исходник и _одновременно_ его исполняет, это - интерпретатор, а если _сначала_ парсит, а _потом_ исполняет, то это - компилятор, так что ли? :)

> Именно так. Даже сохранение в промежуточный код в явном виде не обяательно.

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

>>Там компилятор в стандартной библиотеке.

> ага. копилит евал в сошник

Просто в машкод, который лежит в памяти

> может все-таки интерпретатор?

Наверняка и он тоже есть :D

>ага. копилит евал в сошник, а потом грузит длопеном. может все-таки интерпретатор?

Посмотри, пожалуйста, на SP-Forth. Он никаких .so-шников с dlopen'ом не грузит :) Он выполняет EVALUATE хоть прямо из памяти. И результат может тут же компилировать в память же и исполнять скомпилированное. А потом результат ещё и в машкодовый бинарник сохранить :)

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

>Честное слово, люди, мир программирования - очень богат, и полезно знать котя бы немного за пределами x86, gcc и википедии :)

Честное слово, надо сначала определиться с терминологией.

>погодите, кто из них компилятор-то? компилятор не может исполнять. исполнять может или процессор

Да, это уже я заговариваюсь :) В этом контексте выскочила из рассмотрения среда исполнения.

> Посмотри, пожалуйста, на SP-Forth.....

Может все-таки разберемся с терминами? Можно ввести понятие компилирующего интерпретатора (JIT). Тогда легче станет однозначно.

>Честное слово, надо сначала определиться с терминологией.

Я и дал строгое определение. Альтернативных, столь же неизменных во времени я пока не видел. Дайте строгое определение, по которому одна и та же реализация языка не будет становиться то компилятором, то интерпретатором, в зависимости от наличия или отсутствия чего-то на стороне - обсудим его :)

>Может все-таки разберемся с терминами? Можно ввести понятие компилирующего интерпретатора (JIT). Тогда легче станет однозначно.

У SP-Forth нет JIT. Потому что нет никакого байткода. Это рафинированнейший компилятор по терминологии «машкодников» :) Он прямо с сорца (или из строки в памяти) генерирует чистый машинный код без промежуточных представлений.

> А в Питоне байткод напрямую исполняется на виртуальном процессоре Питона.

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

>Зато, например, Java может напрямую на Java-процессоре исполняться.

ну и замечательно. javac.exe - компилятор, java.exe - виртуальная машина, которая _интерпретирует_ байткод (если опустить JIT). в чем проблема?

>Тогда Питон волшебным образом превратится в компилятор? :D Сам-то понимаешь, какую чушь морозишь? :D Наличие или отсутствие совершенно независимого явления меняет суть определения?

а вы понимаете, что говорите бред? Питон это язык, он ни во что не превратится. это так, к сведению.

>Нараз вычисляются люди, не знакомые ни с чем, кроме x86.

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

JIT это неполная версия термина JIT-compiler, никаким интерпретатором здесь не пахнет, не позорьтесь.

Компилирует в машинный код в память, как уже сказали. Может и интерпретатор быть. Может быть смешанная модель, когда основной код интерпретируется, функции, часто выполняемые компилируются в байт-код, к ним применяются оптимизации (например inline), очень часто выполняемые функции компилируются в машинный код.

>ну и замечательно. javac.exe - компилятор, java.exe

Всё с Ваим ясно. Вы, судя по всему, не только с процессорами, отличными от x86 дел серьёзных не имели, но и даже ... В общем, понятно :)

>учитывая, что я в основном разрабатываю под ARM, вы опять сморозили чушь.

Не видно :)

>Питон это язык, он ни во что не превратится. это так, к сведению.

CPython 2.5, согласно Вашей теории, является интерпретатром до появления Питон-процессора. После его появления волшебным образом начинает считаться компилятором? :)

...

Вообще, давайте уж определитесь, под Питоном вы имеете в виду абстрактный язык, конкретный продукт, связку конкретного транслятора с конкретной средой исполнения? Потому что Вы такого нагородили, что я совершенно не представляю, что у Вас в голове по этой теме. Когда определитесь - перечитайте ещё раз топик, по каждому из этих вариантов были уже комментарии. Вот на один из таких комментариев потом и отвечайте, а то Ваши «псевдокомпиляторы» наводят на грустные мысли.

как хорошо, что мне пофиг, что вам понятно и видно :)

CPython 2.5 является набором нескольких вещей.

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

питон - это язык такой. CPython - это его реализация. сам по себе язык не может быть компилируемым или интепретируемым. а вот данная реализация - это интерпретатор (плюс транслятор в байт-код)

>CPython 2.5 является набором нескольких вещей.

А теперь идём и читаем, что я писал в http://www.linux.org.ru/jump-message.jsp?msgid=2787592&cid=2788293 («Когда ты исполняешь программу на Питоне (CPython) она сперва компилируется в байткод. Не интерпретируется, а именно компилируется. Потом этот байткод интерпретируется (хотя, если на Питоне будет JIT - то и он будет компилироваться) в машинные коды процессора.»)

Так о чём мы спорим тогда? :)

>сам по себе язык не может быть компилируемым или интепретируемым

И про это в теме говорилось уже раз пять :)

так это вы начали спорить с утверждением "питон - интерпретатор"

чего спорить, если это и одно и другое и третье

> его спорить, если это и одно и другое и третье

Ну, слава Яйцам, договорились! Может теперь для разнообразия к теме вернемся? :)

>так это вы начали спорить с утверждением "питон - интерпретатор"

Я на это сразу же ответил (см. тред сначала), что нельзя говорить о языке, можно только о реализации. Что нельзя делать даже для реализации строгого утверждения, так как там связка компонентов. И спорил, собственно, дальше только по частным вопросам. Типа того, является ли в CPython транслятор исходных текстов в байткод коспилятором или интерпретатором :)

> И спорил, собственно, дальше только по частным вопросам.

Кажется Вы запутались и получается у Вас масло-масленое. :)))

Похоже :)

моё имхо по поводу компиляторов и интерпретаторов

питон, перл и пхп - интерпретаторы. они с eval-ом и т.д. по мне разница очень проста - может программа, созданная <чем_либо> исполняться без участия этого <чего_либо>? если может, то <что_либо> - это компилятор, а если не может - это интерпретатор. если есть eval, то выполнение программы включает в себя переходы из стадии выполнения в стадию компиляции, а т.к. строка под ним может быть любая, получается, что нам в программе нужна полная реализация самого транслятора => это уже не компилятор.

процессоры, в т.ч. специализированные, не считаем: процессор - не транслятор, он не создаёт программы. построчное исполнение не считаем: мне никто не мешает взять бинарь интерпретатора и прицепить к нему скрипт - вот вроде и программа. какая разница, чем она там внутри себя управляется?

отсюда питон, перл, пхп, pugs, hugs, все JVM, dosbox и т.п. - интерпретаторы. отсюда же gcc, javac, B::Bytecode - компиляторы.

компилируемый язык можно интерпретировать, а интерпретируемый, при отсутствии eval-а, можно компилировать. а названия "интерпретируемый язык", "компилируемый язык" основаны лишь на популярной практике их реализации, вот и всё.

>сам по себе язык не может быть компилируемым или интепретируемым

Зато он может быть склонен к той или иной реализации. Считаем язык интерпретируемым, если для него более логичным решением кажется интерпретатор. И компилируемым - если компилятор. Устраивает?

Ага, а теперь приведи мне (и обоснуй) критерий "логичности" того или другого решения?

Что по твоему мнению логичнее для, например: Lisp, C, Java, Erlang, Python?

>питон, перл и пхп - интерпретаторы

Ну, вот, опять. При чём, что все последующие утверждения в теме уже были рассмотрены.