LINUX.ORG.RU

Есть ли формально корректный, Тьюринг-полный, но не реализуемый ЯП?

 


1

2

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

★★★★★
Ответ на: комментарий от nihirash

Как минимум возможен условно ненаписуемый компилятор. Ну допустим минимальная длина его кода составит 10E+100 машинных команд x86

praseodim ★★★★★
() автор топика
Ответ на: комментарий от praseodim

Ну допустим минимальная длина его кода составит 10E+100

С чего ты взял, что это ненаписуемый компилятор.

Он может быть вполне себе облачно-оверлейным.

nihirash ★★★
()
Ответ на: комментарий от awesomebuntu

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

praseodim ★★★★★
() автор топика

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

Проясни определение слова «компилятор».

i-rinat ★★★★★
()
Ответ на: комментарий от praseodim

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

Тогда этот компилятор можно будет написать только с помощью него же.
Шах и мат.

awesomebuntu
()

Кстати, из чисто теоретики - это компилятор работающий с данными записанными по основанию экспаненты.

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

nihirash ★★★
()
Ответ на: комментарий от nihirash

Хм. А вот чтобы не мог быть при этом облачно-оверлейным.

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

praseodim ★★★★★
() автор топика

Элементарно. Просто нужно формально определить размер некоторых типов. Например булево значение должно занимать не более 0 бит. 0 — формально корректное значение, но на практике не реализуемое.

MimisGotAPlan
()
Ответ на: комментарий от i-rinat

Да хотя бы как в википедии определено https://en.wikipedia.org/wiki/Compiler для совсем простоты предположим, что компилировать надо в коды x86 процессора.

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

praseodim ★★★★★
() автор топика
Ответ на: комментарий от nihirash

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

Silerus ★★★★
()
Ответ на: комментарий от MimisGotAPlan

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

praseodim ★★★★★
() автор топика
Ответ на: комментарий от nihirash

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

А я и не говорил, что нельзя, но первую программу на нем сумели написать только через два года. Я просто привел в пример, что еще бы определить компилятор как-то через Malbolge же, в общем в этом направлении

praseodim ★★★★★
() автор топика
Ответ на: комментарий от praseodim

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

Да, так и определить — булевы значения должны занимать в памяти не более 0 бит. Формальной ошибки нет. Реализация невозможна. Что ты и хотел.

MimisGotAPlan
()

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

Dark_SavanT ★★★★★
()
Ответ на: комментарий от MimisGotAPlan

Да, так и определить — булевы значения должны занимать в памяти не более 0 бит. Формальной ошибки нет. Реализация невозможна. Что ты и хотел.

Тут есть уловки в духе теории информации и о том, какими битами мерить

nihirash ★★★
()
Ответ на: комментарий от Dark_SavanT

Рекурсия без выхода тоже некорректна. Хотя может быть в сторону фракталов надо глянуть.

praseodim ★★★★★
() автор топика
Ответ на: комментарий от praseodim

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

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

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

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

nihirash ★★★
()
Ответ на: комментарий от nihirash

какими битами мерить

Да пусть хоть по 10ГиБ каждый бит будет. 0 это 0 :)

MimisGotAPlan
()

Язык с функцией, позволяющей узнать, останавливается ли машина Тьюринга с номером N на заданном вводе.

anonymous
()

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

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

Stanson ★★★★★
()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от praseodim

язык Malbolge

Есть Befunge, который планировался для усложнения написания компилятора.

i-rinat ★★★★★
()
Ответ на: комментарий от praseodim

как в википедии определено

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

i-rinat ★★★★★
()

Prolog? Создать к нему конпелятор, производящий быстрый оптимизированный код, нельзя же, или я ошибаюсь? Всякие там идеи суперкомпиляции Турчина.

Virtuos86 ★★★★★
()
Ответ на: комментарий от Dark_SavanT

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

Плюсы?

x3al ★★★★★
()

Можно что-нибудь с проблемой остановки придумать.

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

Davidov ★★★★
()

Есть сверхтьюринговые нереализуемые ЯП

SZT ★★★★★
()

Думаю, C++34 будет таким. Даже в коде C++17-совместимого компилятора уже чёрт ногу сломит, при том, что C99-компилятор пишется за месяц.

vzzo ★★★
()

ПК - не сферическая МТ, у ПК в отличии от МТ есть физические ограничения на время работы, память и т.д.. Плясать надо от этого.

peregrine ★★★★★
()

доказательство существования такого компилятора.

Возмём какую либо «гипотезу»(раньше(до появления доказательства отсутсвия таких троек целых)- подошли бы решения ВТФ) существования подходящих решений чьё(решений) существование доказано и доказано их бесконечное счётное число - но их значения либо вообще либо трудно известны(те же числа мерсена) -

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

ну и как уже тут ранее предложили начнём компиляцию этого компилятора этим же компилятором.

имхо время самокомпиляции меньше счётной бесконечности но сильная увереность больше времени существования вселенной исчисленное в квантах планка-времени.

anonymous
()

спецификации были бы корректными.

т.е достаточно в спецификации опираться на доказанные существованием но не известные конкретно значения и использовать эти значения для реализации --- что приводит к существованию спецификации с одновременным не сущестованнием компилятора сей спецификации в код реализующий таковую спецификацию и одновременно трудность получения такового компилятора в дальнейшем по причине трудности конструктивных решений «доказанных существованием» но вычислительно-трудных значений

anonymous
()
Ответ на: комментарий от MyTrooName

ты себе не очень, наверное, представляешь, что такое E+100

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

nihirash ★★★
()
Ответ на: комментарий от nihirash

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

ты себе совершенно не представляешь, что такое E+100

MyTrooName ★★★★★
()
Ответ на: комментарий от MyTrooName

существуют условно непреодолимые препятствия

Кто тебе мешает сделать n-узлов, которые будут распределять обработку информации так, чтобы ее все таки обработать?

nihirash ★★★
()
Ответ на: комментарий от MyTrooName

Ты себе совершенно не представляешь, чем отличается E+100, допустим, от любого бесконечно большого числа.

buddhist ★★★★★
()
Ответ на: комментарий от MimisGotAPlan

0 бит => отсутствие информации => никакой речи о каком-либо значении. Проблемы с логикой = «формальной ошибки нет»?

ados ★★★★★
()
Ответ на: комментарий от ados

Формализм и здравый смысл — понятия параллельные и невзаимосвязанные. Логика и здравый смысл тоже. Так почему же ты лезешь тут со здравым смыслом?

MimisGotAPlan
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.