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

% raco pkg install disassemble

https://github.com/samth/disassemble

Ага, спасибо.

А это как лечится?

x: unbound identifier in module in: x

А если пишу так

(require disassemble)
(for ([i 10])
    (eval `(begin (define (x) ,i) (x))`
    (disassemble x #:size 26)))

ffi-obj: couldn't get "scheme_jit_find_code_end" from #f (/usr/bin/gracket: undefined symbol: scheme_jit_find_code_end)

А откуда оно возникает? Телепаты в отпуске.

Где ты это пишешь? В репле? В module-level оно и не будет работать. И что у тебя за кавычка в конце третьей строки?

Все описанные проблемы возникают в гуевой среде DrRacket, я так понимаю это интерактивный интерпретатор?

Я просто думал, что кавычки должны быть парными, фейл.

Ваши строки ввожу там же, с директивой #lang racket

Надо вводить в репле (часть окна снизу, с «>»), тогда должно все работать. #lang racket в репле вводить не надо.

ffi-obj: couldn't get «scheme_jit_find_code_end»

Надо racket из git'а поставить. disassemble функцию уже из него берёт. Или ждать следующего релиза.

Или предыдущую версию disassemble из истории git'а вытащить

Программа, которая написана так, чтобы ее выхлоп не был валидным ни на одном языке программирования? Программа без выхлопа? Ты что, идиот? По твоему что, любая программа вообще - интерпретатор? (на предпоследний вопрос ответ я знаю).

Спасибо. Но проще не морочить голову ради такой ерунды.

Программа, которая написана так, чтобы ее выхлоп не был валидным ни на одном языке программирования? Программа без выхлопа? Ты что, идиот?

мы про выхлоп компилятора/интерпретатора (T) некой программы (X) говорили.

Меня мало волнует выхлоп X, про него речи не было, я говорил про выхлоп T. Так вот, для любого X, любой T выдаёт на выход некий код на другом ЯП, нежели написана X. Например мой g++/gcc на входе принимает C++/C, на выходе выдаёт x86 код (или ассемблерный текстовый с ключом -S), который пишется в файл, а потом отдаётся процессору.

Ну а интерпретатор на выходе тоже выдаёт x86 код, который нигде не запоминается, а сразу отдаётся процессору.

А что даст выхлоп этого x86 кода — другой вопрос.

По твоему что, любая программа вообще - интерпретатор?

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

Всегда ваш, К.О.

мы про выхлоп компилятора/интерпретатора (T) некой программы (X) говорили.
Меня мало волнует выхлоп X, про него речи не было, я говорил про выхлоп T.

Для особо одаренных емулеков - выхлоп интерпретатора на T по определению - выхлоп X.

Так вот, для любого X, любой T выдаёт на выход некий код на другом ЯП, нежели написана X.

Нет, не выдает. Если выхлоп X - пустой, то выхлоп T - тоже пустой. Если Х - виснет, то выхлопа T - вообще нет. Что ты с этим делать будешь?

мы про выхлоп компилятора/интерпретатора (T) некой программы (X) говорили. Меня мало волнует выхлоп X, про него речи не было, я говорил про выхлоп T.

Для особо одаренных емулеков - выхлоп интерпретатора на T по определению - выхлоп X.

это демагогия.

Нет, не выдает. Если выхлоп X - пустой, то выхлоп T - тоже пустой. Если Х - виснет, то выхлопа T - вообще нет. Что ты с этим делать будешь?

Смотри: X это бесконечный цикл. Он «виснет» (К.О.). Но посмотри на систему: процессор работает, что-то читает, что-то пишет, _работает_. Вопрос: что? По определению, CPU может выполнять только свои команды, с этим ты согласен? Откуда он берёт команды, которые выполняет, загружая вычислитель на 100%?

это демагогия.

Нет, это не демагогия. Это определение интерпретатора. Общепринятое определение. Если емулек придумал какое-то свое определение, которое использует только емулек - то это его, емулека, половые проблемы. И если ты говоришь интерпретатор в смысле определения емулека, то так и говори «интерпретатор по емулеку», чтобы люди тебя понимали.

Откуда он берёт команды, которые выполняет, загружая вычислитель на 100%?

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

Те же яйца, не дизассемблирует.

Пусть анон напишет свою версию среды и модуля.

А то меня начинают терзать смутные сомнения... :)

Те же яйца, не дизассемблирует.

Возьми версию Racket отсюда: http://www.cs.utah.edu/plt/snapshots/ Тогда будет работать новая версия disassemble (параметр size тогда не нужен)

Или если хочешь точно как у анона, то бери disassemble с https://github.com/samth/disassemble/tree/ebf2e0c6c560a2af231e2dd7a770af95b67... (вручную замени файлы). Тогда ещё потребуется ndisasm: http://www.nasm.us/ (ну или смотри в дистрибутиве nasm)

Цитирую изначальный текст:

О, если смотреть более широко: являются ли трансляторами команды ftp, mail, host, lynx?

Я об этом. А ты о чем?

Да, теперь первый пример отработал, спасибо.

Нет, это не демагогия. Это определение интерпретатора. Общепринятое определение. Если емулек придумал какое-то свое определение, которое использует только емулек - то это его, емулека, половые проблемы. И если ты говоришь интерпретатор в смысле определения емулека, то так и говори «интерпретатор по емулеку», чтобы люди тебя понимали.

нет, это демагогия. Попытка спрятаться за определением.

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

контрпример я тоже приводил. Bash являетс интерпретатором, но парсит весь цикл целиком, а не частями. Посему очевидно, что можно и последовательность команд взять целиком, а не по одной. И она будет конечной.

О, если смотреть более широко: являются ли трансляторами команды ftp, mail, host, lynx?

Я об этом. А ты о чем?

о том, что ftp и прочее — утилиты, а не трансляторы. Но ты можешь их считать термами интерпретатора shell.

Bash являетс интерпретатором, но парсит весь цикл целиком, а не частями.

Ты так и не доказал, что он парсит весь цикл целиком. Или в bash нету евала?

Попытка спрятаться за определением.

Так не прячься за определение.

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

даже если текущая реализация и парсит частями, то не так уж и сложно это исправить.

Или в bash нету евала?

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

Так не прячься за определение.

я как раз и не прячусь. А наоборот, расширяю определение. За что меня и критикуют.

даже если текущая реализация и парсит частями, то не так уж и сложно это исправить.

Я готов посмотреть на исправление.

есть

oooops! значит исправление о котором ты говорил выше - не просто «не сложное», а вообще - невозможное :(

я как раз и не прячусь.

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

А наоборот, расширяю определение.

А зачем его расширять? Давай расширим еще больше и будем называть интерпретатором/компилятором вообще все что угодно.

oooops! значит исправление о котором ты говорил выше - не просто «не сложное», а вообще - невозможное :(

ты это считаешь доказанным фактом? И конечно готов дать ссылку на доказательство, да?

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

это реальность. Просто твоя теория дала сбой. Бывает. Реальность такова, что интерпретатор порождает поток машинных команд. Этот поток _можно_ сохранить, и получится компилятор.

Возражение про цикл(в т.ч. бесконечный) несерьёзно, ибо есть машинные команды для цикла.

Возражение про eval тоже несерьёзно, ибо что мешает сохранить в коде этот eval? Да и то, в большинстве случаев это и не нужно, т.к. eval не рекомендуется применять для генерации кода.

А зачем его расширять?

что-бы оно не противоречило реальности. Это как неевклидова геометрия. Евклидова конечно хороша, но на самом деле мир не плоский, а кривой. Ну вот такая она, реальность…

ты это считаешь доказанным фактом?

Конечно, доказанный.

И конечно готов дать ссылку на доказательство, да?

http://ru.wikipedia.org/wiki/Проблема_останова

это реальность.

Это твоя личная реальность емулека. В которой живет только один единственный емулек. У всех остальных другая реальность.

Этот поток _можно_ сохранить

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

что-бы оно не противоречило реальности.

Оно и не противоречит. Оно реальности соответствует, в отличии от твоих фантазий. В реальности есть четкая разница между компилятором и интерпретатором. И никто их не путает. Кроме емулеков.

Евклидова конечно хороша, но на самом деле мир не плоский, а кривой.

Кто тебе это сказал?

И конечно готов дать ссылку на доказательство, да?

http://ru.wikipedia.org/wiki/Проблема_останова

проблема останова тут не причём. Мне плевать, остановится алгоритм, или нет. Из цикла вида while true; do true; done _можно_ сделать код вида L: JMP L, а то, что ни тот ни другой код никогда не завершиться — да и чёрт с ним.

Это твоя личная реальность емулека. В которой живет только один единственный емулек. У всех остальных другая реальность.

ага, конечно.

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

http://www.informatik.uni-kiel.de/~wg/clicc.html не благодари

Евклидова конечно хороша, но на самом деле мир не плоский, а кривой.

Кто тебе это сказал?

Альберт Эйнштейн

проблема останова тут не причём.

Конечно при чем. Смысл в том что можно взять любую алгоритмически неразрешимую задачу, сводимую к проблеме останова. Можно например заставить компилятор доказывать ВТФ. Она, конечно, уже доказана - ко компилятор этого не знает.

Из цикла вида while true; do true; done _можно_ сделать код вида L: JMP L, а то, что ни тот ни другой код никогда не завершиться — да и чёрт с ним.

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

http://www.informatik.uni-kiel.de/~wg/clicc.html не благодари

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

Ну и предложенный тобой компилятор неполон.

Альберт Эйнштейн

Он такого не говорил, не ври.

Конечно при чем. Смысл в том что можно взять любую алгоритмически неразрешимую задачу, сводимую к проблеме останова. Можно например заставить компилятор доказывать ВТФ. Она, конечно, уже доказана - ко компилятор этого не знает.

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

Это _компилятор_, а я у тебя просил _интерпретатор_.

ты идиот? Я и говорил, что для любого ЯП можно сделать И компилятор И интерпретатор. Вот тебе компилятор для lisp'а, который сам по себе — один большой eval.

Ты же пытаешься доказать, что это делает _интерпретатор_.

не нужно приписывать мне свои фантазии. Интерпретатор этого не делает, по определению. И тем не менее, для данного ЯП _можно_ написать компилятор, с циклами и eval'ами.

Ну и предложенный тобой компилятор неполон.

ЩИТО? Чего не хватает? Блекджека или шлюх?

Он такого не говорил, не ври.

вот поступишь в восьмой класс, и поймёшь, что я не врал.

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

Помешает так, что в зависимости от результата решения будет разный код.

ты идиот? Я и говорил, что для любого ЯП можно сделать И компилятор И интерпретатор. Вот тебе компилятор для lisp'а, который сам по себе — один большой eval.

Что за хуйню ты несешь? Один большой евал - это интерпретатор, а не компилятор. И то что ты предложил - это не евл и даже не близко. Это в-опервых. Во-вторых - ты утверждал что любой интерпретатор - это компилятор. Именно это ты и доказываешь. Я все еще жду либо описания метода, как имея компилятор получить скомпилированный код, либо конкретный интерпретатор, который этот код предоставляет на основе логов процесса выполнения. Давай пруф, или ты - пиздобол.

ЩИТО? Чего не хватает? Блекджека или шлюх?

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

вот поступишь в восьмой класс, и поймёшь, что я не врал.

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

разбираются в тебе

разбираются в теме

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

Помешает так, что в зависимости от результата решения будет разный код.

нет. Будет один и тот же код, только будут запускаться разные его части для разных входных данных. Например для 5+5 выполнится add, а для 5*5 imul. А в коде будет и add и imul.

PS: О5, ты лолка анскильная себя выдал...

нет. Будет один и тот же код

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

PS: О5, ты лолка анскильная себя выдал...

Щито?

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

нет. Будет конечный код. Смотри: у тебя есть выражение, которое ты хочешь решить. Ты его преобразуешь в другое выражение, и пишешь в память. Потом в третье, и так далее.

Да, потребуется потенциально бесконечная память. Да, решение может быть бесконечным. Да, ты не выяснишь, бесконечно-ли решение или нет.

Вот только сам код будет вполне конечен.

Щито?

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

нет. Будет конечный код. Смотри: у тебя есть выражение, которое ты хочешь решить. Ты его преобразуешь в другое выражение, и пишешь в память. Потом в третье, и так далее.

И что дальше? Максимальное решение-то у тебя откуда возьмется?

Вот только сам код будет вполне конечен.

Откуда код вообще возьмется если для того чтобы его получить тебе нужно знать максимальное решение?

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

А что, на пост, где есть мат, нельзя отвечать? Не знал.

И что дальше? Максимальное решение-то у тебя откуда возьмется?

а зачем мне решение? Ты просил код, а не решение. Ну смотри: я не могу вычислить число π точно. За то я могу написать код, который вычисляет число π с бесконечной точностью (за бесконечное время).

Ещё раз: не путай решение и машинный код(язык программирования).

Откуда код вообще возьмется если для того чтобы его получить тебе нужно знать максимальное решение?

сгенеррится сам через время равное ∞.

А что, на пост, где есть мат, нельзя отвечать?

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

а зачем мне решение? Ты просил код, а не решение.

Ну а откуда ты возьмешь код, если у тебя нету решения? Смотри, есть функция f, она принимает некоторое число и возвращает код. И этот код f(n) идет на евал. Ты не знаешь заранее какое у тебя n (это решение). Как ты получишь код, который идет на евал, до того как получишь решение?

сгенеррится сам через время равное ∞.

Что эквивалентно тому, что он никогда не сгенерится, ок.

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

Ну ок, учту.

Ну а откуда ты возьмешь код, если у тебя нету решения? Смотри, есть функция f, она принимает некоторое число и возвращает код. И этот код f(n) идет на евал. Ты не знаешь заранее какое у тебя n (это решение). Как ты получишь код, который идет на евал, до того как получишь решение?

очень просто: вызову функцию f с аргументом n. Не вижу проблемы.

Что ты с диофантовыми уравнениями говорил? Давай покажу, как они решаются с конечным кодом и бесконечным евалом.

сгенеррится сам через время равное ∞.

Что эквивалентно тому, что он никогда не сгенерится, ок.

и что? При чём тут интерпретатор/компилятор? Если код работает бесконечно, он и будет _работать_ бесконечно. А то, что у него нет конца не доказывает того, что нет этого кода.

Т.е. решения нет, а код — есть.

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

очень просто: вызову функцию f с аргументом n. Не вижу проблемы.

А откуда ты возьмешь n?

А то, что у него нет конца не доказывает того, что нет этого кода.

«Программой» называется текст определенного вида. «текстом» называется конечная последовательность символов определенного языка. КОНЕЧНАЯ. Бесконечная последовательность символов не является ни текстом, ни программой.

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

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

Каждый терм транслируется в фиксированное количество определённых машинных команд. Потому мы можем выполнить eval и не зная код. К примеру вот программа 1 2 3 * +эта программа считает 1+2*3

Я надеюсь, реализацию на своём любимом ЯП ты сам сделаешь?

Каждый терм транслируется в фиксированное количество определённых машинных команд.

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