является ли то и другое трансляторами?

Да.

Сабж

В википедии забанили?

платиновые треды

Это очень грустно, что linux стал настолько дружественен к пользователям :(

Это просто кто-то сдаёт хвосты в универе.

Ничем не отличается. RTFM про Futamura projections.

Здесь всё подробно объясняют: http://d2bk0s8yylvsxl.cloudfront.net/stanford-compilers/recoded_videos/01-01-...

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

RTFM про Futamura projections

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

http://ru.wikipedia.org/wiki/%CA%EE%EC%EF%E8%EB%FF%F2%EE%F0

http://ru.wikipedia.org/wiki/%C8%ED%F2%E5%F0%EF%F0%E5%F2%E0%F2%EE%F0

Не благодари.

Совсем, блин, обленились...

является ли то и другое трансляторами?

Да.

Сабж

В википедии забанили?

Кстати, как раз в википедии есть понятие «Простой интерпретатор анализирует и тут же выполняет (собственно интерпретация) программу покомандно». И почему ты считаешь, что он является транслятором? Для примера возьмём sh.

И почему ты считаешь, что он является транслятором? Для примера возьмём sh.

Вдимо, потому что он транслирует входной текст в выходной, не?

compilator & interpretator

Этому треду уже 10 лет, а ты до сих пор не знаешь, чем же они отличаются. Не стыдно?

Как-то читал, что согласно теории множеств, количество чисел натурального ряда равно количеству, например, четных, так как оба множества бесконечны. И вот, подумалось, в развитие этой интересной мысли, что вообще говоря, любые 2 произвольно взятых числа равны, поскольку количество чисел, которые идут после любого из них — равно. Из этого следует, что например, 1 = 2 или 1 = 100. Более строго, может быть, это можно выразить так. Например, берем числа 1 и 2. Какое количество чисел идет после 1 до бесконечности? Бесконечность. После 2-х? Тоже бесконечность. Бесконечность минус бесконечность равно 0. Следовательно, 1 и 2 равны нулю. Доказано. Правильно ли я рассуждаю?

Вдимо, потому что он транслирует входной текст в выходной, не?

Входной текст «df > ~/test». Что является выходным текстом?

Ну так ты ж его перенаправил, это не значит, что его нет, а значит, что он пошел в «другую струю». С другой стороны, можно считать отсутствие выхлопа тоже вариантом выхлопа, концептуально, так сказать. ИМХО, это сути не меняет. Разве компилятор не может выплюнуть «пустой файл программы»?

Лучше просто cat — выходным является ввод пользователя, так что если интерпретатор и «транслирует» код в конечные значения, то вместе с пользователем и всем остальным окружением :)

А с чего Вы решили, что вывод cat вместе с введенными пользавотелем данными не является все го лишь фазой трансляции?

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

Бесконечность минус бесконечность равно 0

вообще-то неопределенность

Ну так ты ж его перенаправил, это не значит, что его нет, а значит, что он пошел в «другую струю». С другой стороны, можно считать отсутствие выхлопа тоже вариантом выхлопа, концептуально, так сказать. ИМХО, это сути не меняет. Разве компилятор не может выплюнуть «пустой файл программы»?

Ладно, пусть будет входной текст «cp -r a b». А если считать отсутствие вывода полностью эквивалентным пустой программе, то хочу заметить, что пустая программа не выполняет необходимых побочных эффектов «создание файла».

Шелл не создаёт «выходную программу». Он просто выполняет команды, которые являются входной программой, а потому транслятором не является.

Лучше просто cat

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

Чего во что? Если в компилятор/декомпилятор/ассемблер/дизассемблер кинуть программу, то заведомо известно (с незначительными оговорками — сколько там рандомизации) что будет в результате. Если в интерпретатор кинуть программу, то выхлоп совсем не известен, так как она будет произвольным образом взаимодействовать с произвольным окружением.

Или трансляции не обязана соответствовать функция и она может делать просто что угодно?

Мне вот так видится:

interpretation : SourceLanguage * Environment -> Values * Environment — эффекты во все поля, наличие окружения в общем случае не позволяет говорить о соответствии между программами и конкретными значениями.

compilation : SourceLanguage -> TargetLanguage — чистая функция, есть соответствие.

execution : TargetLanguage * Environment' -> Values * Environment'

first(interpretation(l, e)) = first(execution(compilation(l), e))

или

storing : TargetLanguage -> (MachineCodeSegment < Machine)

execution : Machine -> Machine

extraction : Machine -> Values

first(interpretation(l, e)) = extraction(execution(storing(compilation(l)) * e))

Или трансляции не обязана соответствовать функция и она может делать просто что угодно?

Функцией, в данном случае, является сам транслятор. Он определенно соответствует «какой-то ф-ции». Кроме всего прочего, Вы путаете функцию с представлением ф-ции. Когда Вы пишите на бумаге «f(x)-->smth», ваша запись не есть функция, это лишь ее выражение.

Я не про конкретно программу cat без аргументов (которая принимает строки и их же печатает, то есть вполне является транслятором/циклом над ним), а про программу sh которая принимает cat без аргументов и возвращает... Что? Канал через который можно вести буфферезированное общение между stdin и stdout? Состояние памяти в котором работает /bin/cat? Наверно она просто _выполняет_ её и тем осуществляет это общение без всякой промежуточной трансляции и возвращает в итоге 0.

Следовательно, 1 и 2 равны нулю. Доказано. Правильно ли я рассуждаю?

аффтор цитаты неплохо на ноль делит.

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

Он определенно соответствует «какой-то ф-ции».

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

компилятор/декомпилятор/ассемблер/дизассемблер

и т.п.

Равно как с наличием самого факта трансляции (во временных рамках).

А то так у интерпретатора есть функциональная спецификация — функция из программ и окружения (из которого можно доставать ввод) в результат и окружение (куда можно отправлять вывод). Но зачем...

а про программу sh которая принимает cat без аргументов и возвращает... Что?

код бинарный. /bin/cat называется. Его и «возвращает».

Если подходить к вопросу без заезженых стереотипов, любой побочный эффект в ходе выполнения, и их совокупность можно считать выводом. Почему транслятор обязан писать все в «одно место»?

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

Но зачем...

man Теория Акторов

И что б я делал без "Комментариев к пользователю"?!

selena-gomes  наркоман, задаёт тупые вопросы
07.05.2014 19:47:44

Ок.

@anonymous

man Теория Акторов

Действительно, всё стало на свои места, можно начинать называть что угодно чем угодно и шланговать :)

Хы, 10 лет назад это уже считалось вбросом.

чем ты недоволен? «выходной текст» интерпретатора == бинарный код, который выполняет CPU. Точнее бинарный код это «буквы», а интерпретатор выдаёт определённые «слова».

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

Правда сегодня довольно редко используются «чистые» интерпретаторы, разве что GNU bash...

PS: при чём тут акторы?

код бинарный. /bin/cat называется. Его и «возвращает»

Не его, а его исполнение, его «ожидание». О его коде ни интерпретатор ни получатель понятия не имеют.

«выходной текст» интерпретатора == бинарный код, который выполняет CPU.

Является ли транслятором команда touch ? Входные данные есть (имя файла), выполнение бинарного кода тоже...

Является ли транслятором команда touch ? Входные данные есть (имя файла), выполнение бинарного кода тоже...

при чём тут «команда touch»

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

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

Ну а с какого на какой язык — значения не имеет. Вот gcc это вообще «полиглот». Кстати, с ключом -S gcc выплёвывает не бинарник, а текстовый файл.

Вот тебе hello world

	.file	"helloworld.c"
	.section	.rodata
.LC0:
	.string	"hello world"
	.text
	.globl	main
	.type	main, @function
main:
.LFB0:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	andl	$-16, %esp
	subl	$16, %esp
	movl	$.LC0, (%esp)
	call	puts
	movl	$0, %eax
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret
	.cfi_endproc
.LFE0:
	.size	main, .-main
	.ident	"GCC: (GNU) 4.8.2"
	.section	.note.GNU-stack,"",@progbits

это C → IA-32(x86). Только коммпилятор схалявничал, и не доделал до конца. Обычно он этот код в двоичном виде делает:

вот первые байты:

00000000  7f 45 4c 46 01 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 03 00 01 00 00 00  f0 82 04 08 34 00 00 00  |............4...|
00000020  34 0e 00 00 00 00 00 00  34 00 20 00 08 00 28 00  |4.......4. ...(.|
00000030  23 00 20 00 06 00 00 00  34 00 00 00 34 80 04 08  |#. .....4...4...|
00000040  34 80 04 08 00 01 00 00  00 01 00 00 05 00 00 00  |4...............|
00000050  04 00 00 00 03 00 00 00  34 01 00 00 34 81 04 08  |........4...4...|
00000060  34 81 04 08 13 00 00 00  13 00 00 00 04 00 00 00  |4...............|
00000070  01 00 00 00 01 00 00 00  00 00 00 00 00 80 04 08  |................|
00000080  00 80 04 08 08 06 00 00  08 06 00 00 05 00 00 00  |................|
00000090  00 10 00 00 01 00 00 00  08 06 00 00 08 96 04 08  |................|
000000a0  08 96 04 08 00 01 00 00  08 01 00 00 06 00 00 00  |................|
000000b0  00 10 00 00 02 00 00 00  1c 06 00 00 1c 96 04 08  |................|
000000c0  1c 96 04 08 c8 00 00 00  c8 00 00 00 06 00 00 00  |................|
000000d0  04 00 00 00 04 00 00 00  48 01 00 00 48 81 04 08  |........H...H...|
000000e0  48 81 04 08 20 00 00 00  20 00 00 00 04 00 00 00  |H... ... .......|
000000f0  04 00 00 00 50 e5 74 64  2c 05 00 00 2c 85 04 08  |....P.td,...,...|

Не его, а его исполнение, его «ожидание». О его коде ни интерпретатор ни получатель понятия не имеют.

какое нафиг «ожидание»? Не создавай не нужных сложностей, всё проще.

другие синхронно переводят живую речь (интерпретаторы).

Но sh (а также старый бейсик) никуда входной файл не переводят, а исполняют по мере чтения.

А если мы считаем, что выполнение — подвид «перевода», тогда вопрос про команду touch (а также ftp, mail, cp) остаётся открытым. Входные данные есть, действия есть.

«выходной текст» интерпретатора == бинарный код, который выполняет CPU.

Это называется компилятор в машинный код а не интерпретатор!

Можешь написать себе интерпретатор AST/байткода на C++ (только exec* не трогай) — он их обходит, с системой взаимодействует, никакого кода CPU на выход не даёт (хотя сам может быть скомпилирован в такой), только эффекты.

Выдавал бы — был бы JIT (родного рантайма, LLVM, для бедных — dlopen/exec*).

Ну а интерпретатор делает это в рантайме.

И из чего во что он переводит?

при чём тут акторы?

Я ХЗ.

какое нафиг «ожидание»? Не создавай не нужных сложностей, всё проще

Тогда код чего возвращает sh на текст «df > ~/test» ?

Явно не команды df, так как в коде ещё запись в файл теперь должна быть...

Но sh (а также старый бейсик) никуда входной файл не переводят, а исполняют по мере чтения.

процессор не умеет исполнять бэйсик и sh, потому его надо переводить в ассемблер. А уже потом исполнять.

А если мы считаем, что выполнение — подвид «перевода», тогда вопрос про команду touch (а также ftp, mail, cp) остаётся открытым. Входные данные есть, действия есть.

есть действие. Это выполнение кода из файла /usr/bin/touch.

Оболочка парсит входной текст, видит там непонятное(ей) слово «touch», и потому ищет в путях $PATH такой файл. Если-бы это было «echo», а оболочкой /bin/bash, то она-бы сама «перевела» echo в код.

Это называется компилятор в машинный код а не интерпретатор!

не имеет значения. Теоретически ты можешь сохранить «выхлоп» оболочки в виде машинных команд.

И из чего во что он переводит?

для тех кто в танке2: из одного ЯП в другой ЯП.

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

дальше читать перестал

Тогда код чего возвращает sh на текст «df > ~/test» ?

sh возвращает код, который запускает файл /bin/df.

так как в коде ещё запись в файл теперь должна быть...

Кто сказал «нужна запись»? Запись не нужна. Ещё раз: переводчик-синхронист ничего не пишет, а просто слушает и говорит. Слушает речь на одном языке, и повторяет на другом. Понятным реципиенту. А уже реципиент _выполняет_ нужное действие.

Ну а jit/llvm это такой переводчик речи с карточками, на одной стороне «stop», на другой «стоять». Или на одной стороне «run», на другой «бежать».

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

дальше читать перестал

а зря. Это утверждение более-менее правильное (мощность множеств одинаковая), ошибка дальше, когда поциент вычислил ∞-∞=0.

«Более-менее» — это до слов «так как».

Теоретически ты можешь сохранить «выхлоп» оболочки в виде машинных команд.

Не можешь, потому что никакого выхлопа машинных команд нет (и не надо про «оболочку» — речь про интерпретаторы вообще).

для тех кто в танке2: из одного ЯП в другой ЯП.

enum Cmd { ... };

void interpret(Cmd cmd) {
    switch (cmd) {
        ... i/o ...
    }
}

В случае такого интерпретатора — из какого в какой? Так и представляю, как элементы Cmd «соответствуют» кускам машинного кода полученного после компиляции функции interpret.

И из чего во что он переводит?

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

Теоретически ты можешь сохранить «выхлоп» оболочки в виде машинных команд.

Не можешь, потому что никакого выхлопа машинных команд нет (и не надо про «оболочку» — речь про интерпретаторы вообще).

почем «нет»? Он просто не сохраняется негде.

В случае такого интерпретатора — из какого в какой?

из C в ассемблер. Просто этот асмовый код не сохраняется в файл, а прямо так и выполняется. Можешь его сохранить в файл, а выполнять потом. Получится компилятор. Правда хреновый, такие компиляторы в 70х годах прошлого века были. И вот в них надо было упароваться, например вместо деления на 3 умножать на 0x5555, а то компилятор так ведь и переводит в mov ax,3; div Сейчас это уже не нужно.

Потому что компилятор достаточно умный, что-бы умножить на 0x5555

main:
.LFB0:
	.cfi_startproc
	pushl	%ebp
	.cfi_def_cfa_offset 8
	.cfi_offset 5, -8
	movl	%esp, %ebp
	.cfi_def_cfa_register 5
	andl	$-16, %esp
	subl	$16, %esp
	movl	$.LC0, (%esp)
	call	puts
	movl	8(%ebp), %ecx
	movl	$1431655766, %edx
	movl	%ecx, %eax
	imull	%edx
	movl	%ecx, %eax
	sarl	$31, %eax
	subl	%eax, %edx
	movl	%edx, %eax
	leave
	.cfi_restore 5
	.cfi_def_cfa 4, 4
	ret