Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, samius, Вы писали:

S>>Да, а неизменяемый список — это не список. Неизменяемое дерево — не дерево, т.к. в список и дерево можно записывать данные, а в неизменяемые — нет. Так, получается?

BFE>Что получается?
см выше перед фразой "Так, получается?"

S>>>>Как же на таком языке реализовать машину Тьюринга, собственно, которая хранит данные в ленте?
BFE>>>Никак.
S>>Это опровержение полноты по Тьюрингу всех функциональных языков. Поздравляю с Нобелевкой!
BFE>Здесь нет опровержения. Небелевку не дают за математику
Хорошо, с премией Тьюринга!

BFE>>>Не уверен, что в доказательстве используется факт хранения.
S>>Не уверен, что факт хранения используется и в определении полноты.
BFE>Вот именно.
Тогда причем тут хранение вообще? Зачем оно нужно? Буфер должен поддерживать операции записи и чтения. Обеспечивать семантику очереди. С этим в ФП все в порядке.

BFE>>>simulate != реализовать
S>>По буквам — нет. Но в чем отличие?
BFE>Отличие в том, что эмуляция может работать как ей угодно, лишь бы результат совпадал.
Что не так с "как ей угодно"? Чем не устраивает?

S>>>>А машина Тьюринга позволяет хранить данные на ленте.
BFE>>>Но симулятор не обязан хранить данные.
S>>Кто же обязан, если симулятор не обязан? Каким же образом тогда симулятор симулирует машину Т?
BFE>Получает тот же результат.
Раз получает тот же результат, то, наверное, и не обязан хранить данные?

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, samius, Вы писали:


BFE>>>но для этого потребуется специальное устройство для хранения промежуточных данных. Таким образом композит 'функциональная программа'+'устройство для хранения промежуточных данных' превращается в императивную программу.
S>>И что за загадочное такое устройство нужно для хранения промежуточных данных?
BFE>Буфер.
Буфер можно организовать в самой программе на фя. Не нужно никакое постороннее устройство ей.

S>>Почему же функциональные языки полны без ссылки на специальное устройство для хранения промежуточных данных??
BFE>Да потому, что полноты хранение промежуточных данных не требуется.
Ну так раз для полноты не требуется, то и вообще не требуется. Полнота она об эквивалентной мощности полных по Тьюрингу языков. Если программа способна эмулировать вычисления на другом языке без какого-то хранения, то в чем вообще проблема с хранением?

Здравствуйте, Sinclair, Вы писали:

S>>>Ну... Да, меняет как бы ровно всё. Если ФП-язык Turing-complete, то на нём можно смоделировать Машину Тьюринга.
BFE>>Смоделировать — это не значит сделать один в один. Это значит, что тот же самый результат можно получить с помощью выполнения функциональной программы и с помощью Машины Тьюринга, если взять те же исходные данные.
S>Совершенно верно. Вот ровно всё-всё, что делает Машина Тьюринга с некоторыми исходными данными, можно получить с помощью выполнения некоторой функциональной программы.
Получить можно, но ведь речь-то как раз не об этом, а о том, как получить.

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

Тьюринг-полнота что-то говорит о записи результата на ленту? Нет. Она говорит только то, что результат выполнения функциональной программы и результат выполнения программы на Машине Тьюринга совпадут.

S>>>Берём программу на вашем любимом ОО-языке, сводим её к Машине Тьюринга (а это возможно в силу Тезиса Чёрча), и запускаем на нашей модели МТ, построенной на ФП-языке.
BFE>>Так вы сэмулировали функциональный язык на Машине Тьюринга, а надо наоборот, машину Тьюринга сэмулировать на функциональном языке.
S>Нет. Так я сэмулировал ОО на МТ, а МТ на ФП — получив, таким образом, исполнение ОО-программы на ФП-вычислителе.

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

BFE>>Делается это другим способом, с помощью преобразования одного состояния ленты Машины Тьюринга в другое состояние ленты Машине Тьюринга, но сама лента является внешней по отношению к преобразованию. Так вот, это преобразование не нуждается в хранении никаких промежуточных результатов.
S>Конечно. Так и программа "с буферизацией" не нуждается в хранении никаких промежуточных результатов.
Действительно. "Не нуждается". Размер программы "с буферизацией" (размер исполняемого кода), которая не нуждается в хранении никаких промежуточных результатов, превосходит максимальное число, которое можно записать в буфер этой программы. Так, например, для буфера в 1024 байт размер программы будет превышать число состоящие из 1024-х шестнадщетиричных цифр, что превышает количество атомов в наблюдаемой Вселенной. Только в этом случае программа "с буферизацией" не нуждается в хранении никаких промежуточных результатов, просто потому, что вам придётся вписать все возможные комбинации состояний в виде констант. А так-то да, "не нуждается".

Z>Как-то статья резко кончилась. Долго рассказывали как плохо иметь глобальное
Z>состояние, а потом резко "возьмите функциональный язык и будет вам счастье".

Здравствуйте, B0FEE664, Вы писали:

BFE>Опишите пожалуйста, как именно вы построили Машину Тьюринга на функциональном языке. Учтите, что у вас нет ленты для записи.

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

Здравствуйте, fmiracle, Вы писали:

BFE>>Неизменяемый кусок памяти — это константный объект, с ними никаких проблем, только это не буфер, т.к. в буфер можно записывать данные.

F>Ну тебе буфер нужен же не для того чтобы именно в вот эту область памяти тупо записать и перезаписать данные? Он нужен для того, чтобы где-то накопить данные, которые далее можно использовать, так ведь?
F>Ну объединяем эти неизменяемые области памяти в связный список и обрабатываем по частям — получаем накопление состояния, но без изменения этих самых блоков. Только копирования туда-сюда, целиком или частями, как там в задаче потребности.

Это уже не чистое функциональное программирование, так как появляется состояние программы.

Здравствуйте, AlexRK, Вы писали:

BFE>>Опишите пожалуйста, как именно вы построили Машину Тьюринга на функциональном языке. Учтите, что у вас нет ленты для записи.

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

В результате получилась императивная программа.

Здравствуйте, samius, Вы писали:

S>>>Надо сказать, что в ООП все именно так и устроено. 1000 функций A_ToString() B_ToString(), но перегруженных по типу аргумента неявно. ToString(A), ToString(B). А то, что функции лежат в файле A.cs, B.cs — так никто так же не запрещает и в процедурном программировании писать.

I>>Куда деть полиморфизм ? Вот есть у меня переменная некоего неуточненного типа, как мне узнать, в каком из 1000 модулей лежит нужный toString ?
S>Что за неуточненный тип в процедурном программировании? Полиморфизм функций там есть, а полиморфизма типов — нет.

Это значит, что точный тип ты не знаешь. Из конфига значения прочитал.

I>>Для работы с полиморфмными переменными на ходу изобретаются правила, а следовательно — изобретение ООП.
S>Полиморфные переменные в ПП? Это шутка?

В процедурном с этим никаких проблем никогда не было. Пример можно посмотреть в обычном Си, когда по указателю предаётся что угодно, в ассемблере, в котором в регистре передаётся что угодно и тд.
Более того, если есть даже не указатель, а обычное целое число, то здесь тоже возможен полиморфизм — это целое может быть номером дома, идентификатором, ключом, индексом и тд и тд. Собтсвенно, ровно тот же полиморфизм и ничего, живут люди.

Здравствуйте, B0FEE664, Вы писали:

BFE>>>Опишите пожалуйста, как именно вы построили Машину Тьюринга на функциональном языке. Учтите, что у вас нет ленты для записи.

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

BFE>В результате получилась императивная программа.

Почему?

Здравствуйте, samius, Вы писали:

S>Буфер можно организовать в самой программе на фя. Не нужно никакое постороннее устройство ей.
Как это сделать?

S>Ну так раз для полноты не требуется, то и вообще не требуется. Полнота она об эквивалентной мощности полных по Тьюрингу языков. Если программа способна эмулировать вычисления на другом языке без какого-то хранения, то в чем вообще проблема с хранением?
Проблема не с хранением, проблема с реализацией. По сути есть противоречие: нам надо временно сохранить данные, но мы не имеем права хранить что либо. Разрешить это противоречие можно, если только в сам алгоритм записать все возможные комбинации входных данных в виде констант. Другого способа я не вижу.

Здравствуйте, Poopy Joe, Вы писали:

PJ>Использовать c# для type drive development наверно можно, но читать это будет невозможно совершенно.
Я не большой эксперт чтобы говорить о type driven, потому что не щупал ручками. Поэтому говорить не могу хоть и подозреваю на аналогичные инструменты.

PJ>А что может быть хорошего в кортежах вида (int, int) вообще непонятно.
Оно несколько круче. Кортежи могут быть как неименованными, так и именнованными. В функционалах документированность кортежам давало использование в паттерн матчингах. В шарпах он также появился. Сильно не хватало кортежей при возврате результатов из функций. Чтобы вернуть значение зачастую программисты создавали синтетический тип для конкретного использования в одном месте.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>>>Куда деть полиморфизм ? Вот есть у меня переменная некоего неуточненного типа, как мне узнать, в каком из 1000 модулей лежит нужный toString ?
S>>Что за неуточненный тип в процедурном программировании? Полиморфизм функций там есть, а полиморфизма типов — нет.

I>Это значит, что точный тип ты не знаешь. Из конфига значения прочитал.
Если нет механизма перевода записи конфига в тип, то поиск модуля с ToString ничем не поможет.

S>>Полиморфные переменные в ПП? Это шутка?

I>В процедурном с этим никаких проблем никогда не было. Пример можно посмотреть в обычном Си, когда по указателю предаётся что угодно, в ассемблере, в котором в регистре передаётся что угодно и тд.
I>Более того, если есть даже не указатель, а обычное целое число, то здесь тоже возможен полиморфизм — это целое может быть номером дома, идентификатором, ключом, индексом и тд и тд. Собтсвенно, ровно тот же полиморфизм и ничего, живут люди.

Полиморфизм он о типах, о разных типах, а не о разных способах всунуть в один тип (целое или указатель) что взбредет в голову (дом или индекс).

Здравствуйте, B0FEE664, Вы писали:

S>>Ну так раз для полноты не требуется, то и вообще не требуется. Полнота она об эквивалентной мощности полных по Тьюрингу языков. Если программа способна эмулировать вычисления на другом языке без какого-то хранения, то в чем вообще проблема с хранением?
BFE>Проблема не с хранением, проблема с реализацией. По сути есть противоречие: нам надо временно сохранить данные, но мы не имеем права хранить что либо. Разрешить это противоречие можно, если только в сам алгоритм записать все возможные комбинации входных данных в виде констант. Другого способа я не вижу.

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

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

Здравствуйте, AlexRK, Вы писали:

ARK>>>Новое состояние ленты передается в каждый последующий шаг алгоритма входным параметром. Тот, в свою очередь, конструирует очередное состояние и передает дальше.
BFE>>В результате получилась императивная программа.
ARK>Почему?
По определению:

Императивное программирование — это парадигма программирования (стиль написания исходного кода компьютерной программы), для которой характерно следующее:

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

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

Здравствуйте, samius, Вы писали:

S>>>Да, а неизменяемый список — это не список. Неизменяемое дерево — не дерево, т.к. в список и дерево можно записывать данные, а в неизменяемые — нет. Так, получается?
BFE>>Что получается?
S>см выше перед фразой "Так, получается?"
Вы хотите сказать, что у вас так получится буфер?

S>>>>>Как же на таком языке реализовать машину Тьюринга, собственно, которая хранит данные в ленте?
BFE>>>>Никак.
S>>>Это опровержение полноты по Тьюрингу всех функциональных языков. Поздравляю с Нобелевкой!
BFE>>Здесь нет опровержения. Небелевку не дают за математику
S>Хорошо, с премией Тьюринга!
За что?

S>Тогда причем тут хранение вообще? Зачем оно нужно? Буфер должен поддерживать операции записи и чтения. Обеспечивать семантику очереди. С этим в ФП все в порядке.
Эээээ.... Вы точно отличаете буфер от серии операций над входными данными?

BFE>>Отличие в том, что эмуляция может работать как ей угодно, лишь бы результат совпадал.
S>Что не так с "как ей угодно"? Чем не устраивает?
Реализацией.

S>>>>>А машина Тьюринга позволяет хранить данные на ленте.
BFE>>>>Но симулятор не обязан хранить данные.
S>>>Кто же обязан, если симулятор не обязан? Каким же образом тогда симулятор симулирует машину Т?
BFE>>Получает тот же результат.
S>Раз получает тот же результат, то, наверное, и не обязан хранить данные?
Так в том и дело, что по условию данные нужно хранить.

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, samius, Вы писали:

S>>>>Да, а неизменяемый список — это не список. Неизменяемое дерево — не дерево, т.к. в список и дерево можно записывать данные, а в неизменяемые — нет. Так, получается?
BFE>>>Что получается?
S>>см выше перед фразой "Так, получается?"
BFE>Вы хотите сказать, что у вас так получится буфер?
Только так и получится. Изменяемых структур данных в чистом ФП нет.

BFE>>>Здесь нет опровержения. Небелевку не дают за математику
S>>Хорошо, с премией Тьюринга!
BFE>За что?
Это опровержение полноты по Тьюрингу всех функциональных языков.

S>>Тогда причем тут хранение вообще? Зачем оно нужно? Буфер должен поддерживать операции записи и чтения. Обеспечивать семантику очереди. С этим в ФП все в порядке.
BFE>Эээээ.... Вы точно отличаете буфер от серии операций над входными данными?
Точно не отличаю. Операции над входными данными и будут представлять буфер в ФП. Очередь входных данных — так буквально.

BFE>>>Отличие в том, что эмуляция может работать как ей угодно, лишь бы результат совпадал.
S>>Что не так с "как ей угодно"? Чем не устраивает?
BFE>Реализацией.
Что не так с реализацией? Какой критерий?

S>>Раз получает тот же результат, то, наверное, и не обязан хранить данные?
BFE>Так в том и дело, что по условию данные нужно хранить.
Нет, это надуманное условие. Достаточно добавлять данные в хвост очереди и предоставлять их с начала. Хранить — что это и зачем — не понимаю, что за этим стоит.

Здравствуйте, AlexRK, Вы писали:

ARK>Где же оно, великое хардкорное ФП? В ядрах операционных систем? В самолетах и марсоходах? В играх? В бизнес-приложениях? В движках гугла и яндекса, быть может? В веб-сайтах? Где? Какая доля от миллиардов программных проектов написана на Haskell/Lisp/ML? Какой процент вакансий на этих языках? Вопросы риторические.

Конечно риторические. Невозможно найти если не смотреть. Фейсбуком пользуешься? Ну вот хотя бы там.

ARK>Я не "ссылался на себя в начале тебе", что бы эта странная фраза ни значила. Я сослался на начало темы: http://rsdn.org/forum/philosophy/7540923.1

Автор: AlexRK
Дата: 12.09.19

Я писал в начале темы это не сослаться на начало темы, это сослаться на себя в начале теме.

ARK>Диалог:
ARK>

ARK>-
ARK>- ФП, который сможет стать популярным — если это вообще произойдет — будет другим, и синтаксически, и концептуально.
ARK>- Это как?
ARK>- Об этом я уже писал в начале этой темы.

ARK>Ты испытываешь сложности с интерпретацией смысла этого диалога? Или с пониманием фразы "об этом я уже писал в начале этой темы"?
Ответить на уточняющий вопрос, что ты уже отвечал и потом возмущаться, что этот ответ уже всплыл это сильно. С тобой точно все хорошо? go to пропустил?

Здравствуйте, samius, Вы писали:

I>>Это значит, что точный тип ты не знаешь. Из конфига значения прочитал.
S>Если нет механизма перевода записи конфига в тип, то поиск модуля с ToString ничем не поможет.

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

S>>>Полиморфные переменные в ПП? Это шутка?

I>>В процедурном с этим никаких проблем никогда не было. Пример можно посмотреть в обычном Си, когда по указателю предаётся что угодно, в ассемблере, в котором в регистре передаётся что угодно и тд.
I>>Более того, если есть даже не указатель, а обычное целое число, то здесь тоже возможен полиморфизм — это целое может быть номером дома, идентификатором, ключом, индексом и тд и тд. Собтсвенно, ровно тот же полиморфизм и ничего, живут люди.

S>Полиморфизм он о типах, о разных типах, а не о разных способах всунуть в один тип (целое или указатель) что взбредет в голову (дом или индекс).

Мы можем моделировать разные вещи при помощи Integer. При этом тип будет HouseNumber, Identifier, Key, Index и тд. Соответсвенно типы разные, а какая унутре неонка — дело десятое.

Здравствуйте, B0FEE664, Вы писали:

ARK>>>>Новое состояние ленты передается в каждый последующий шаг алгоритма входным параметром. Тот, в свою очередь, конструирует очередное состояние и передает дальше.
BFE>>>В результате получилась императивная программа.
ARK>>Почему?
BFE>По определению:
BFE>

BFE>Императивное программирование — это парадигма программирования (стиль написания исходного кода компьютерной программы), для которой характерно следующее:

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

BFE>То, что каждая из команд написана на функциональном языке ничего не меняет в этом определении.

Параметры функций — это никакие не "инструкции". Или что, у функций не может быть параметров? Функционального программирования не существует?

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

Здравствуйте, GlebZ, Вы писали:

GZ>Я не большой эксперт чтобы говорить о type driven, потому что не щупал ручками. Поэтому говорить не могу хоть и подозреваю на аналогичные инструменты.
Ты же сказал, что занимался ФП?!

PJ>>А что может быть хорошего в кортежах вида (int, int) вообще непонятно.
GZ>Оно несколько круче. Кортежи могут быть как неименованными, так и именнованными.
Это не круче, это те же яйца вид в профиль. Именованость не дает ничего от слова совсем.