О чистоте и нечистоте функций и языков
Именно эта противоречие вызывает недоумение, образует барьер, мешающий изучению функционального программирования. Объяснение чистоты функций, с помощью которых происходит ввод и вывод, обычно делается так. Мол, действия ввода/вывода оборачиваются в монаду IO и такая инкапсуляция сохраняет функциям чистоту. Очень похоже на то, как если бы травоядные оборачивали мясо в капусту (то есть инкапсулировали), и съедали, не умаляя стерильности своего вегетарианства.
Как чистые (как утверждается) функции, имеющие аргументом тип IO, инициируют ввод и вывод? Ведь они чисты и значит ленивы.
А ленивые функции сами по себе не могут заработать. Их должен вызвать кто-то неленивый.
Вопрос: кто вызывает чистую ленивую функцию с аргументом типа IO?
Если будет ответ, что все функции типа IO будут в конечном счёте вызваны функцией Язык Haskell — ленивый. Это означает, что он никогда не сделает работу, результат которой никому не нужен.
Вывод может быть один: функция Разоблачение магии
Фокус заключается в том, что все функции типа IO возвращают кортеж.
Одним элементом кортежа является собственно результат.
А вторым элементом являются указатели на нечистые подпрограммы, которые необходимо вызвать для выполнения ввода или вывода.
То есть чистые функции идут в одном пакете с указанием, как необходимо выполнить нечистые действия.
В итоге всё это стекается к Опубликовано: 2022.03.16, последняя правка: 2023.01.19 22:23
Отзывы✅ 2023/12/08 03:02, Comdiv #0 Цитата отсюда:Мысленным экспериментом без всякой связи с реализацией. Например: «Программа, целиком состоящая из чистых функций, не нужна» Тут как раз непонимание того, как это реализовать, хотя в первую очередь страдает реализация в вашем сознании понятия чистого функционального языка. Я не претендую на идеальность, но предложу зарисовку идеи, как его понимать.x -- вся память компьютераЗадача прагматического функционально чистого языка — предложить набор таких понятий, чтобы на них было удобно программировать без потребности засовывать все состояние компьютера в аргумент. Выходить за пределы функциональной чистоты для этого не обязательно. Насколько могу судить, многие разработчики с этим справились — вот вам и связь с реализацией. А то, что вы трактуете это как нарушение чистоты, так это в лучшем случае результат недоразумения. Если у вас особый взгляд и на понятие алгоритма, то ничего удивительного, что и на другие вещи смотрите по-своему. Беда только в том, что эта не та особость, которая даёт преимущества, а та, что надевает шоры. ✅ 2023/12/17 22:30, Автор сайта #1 предложу зарисовку В том то и дело, что зарисовок и эскизов много, в отличие от точных и научных фактов. Рассмотрим пример. Если в программе на Хаскелле имеется функцияwrite_file :: IO ()то вызывающая её функция тоже должна иметь тип IO (): use_write_file :: IO ()Из-за этого у нас и функция main тоже имеет тип IO (), поскольку в ней есть ввод/вывод: main :: IO ()Но функция, которая вызовет эту main, тоже должна иметь тип IO (). А вызывает функцию main операционная система. Ищу в WinAPI хотя бы одну функцию типа IO () и не нахожу её. То есть вызов main типа IO () невозможен. Тем не менее этот вызов происходит. Вам, наверное, отсутствие шор позволит разоблачить магов и фокусников, вызывающих монадические функции из немонадических. Мне желательно описание на ассемблере, чтобы по байтам. Я не видел, чтобы такие моменты растолковывались в зарисовках и эскизах. Но без точного описания быстро скатываемся к принятию «на веру», когда вместо объяснений и доказательств показывают «на пальцах». А это — переход от науки к её антиподу. А то, что вы трактуете это как нарушение чистоты, так это в лучшем случае результат недоразумения. Если у вас особый взгляд и на понятие алгоритма, то ничего удивительного, что и на другие вещи смотрите по-своему. Беда только в том, что эта не та особость, которая даёт преимущества, а та, что надевает шоры. Это Вы так видите. А другие люди высказывали другое мнение, отличное от Вас. И я дорожу их мнением.✅ 2023/12/18 16:40, veector #2 Простите пожалуйста за глупый вопрос, а зачем тогда придумали такую классификацию как "чистота функции", какой прок пытались получить от этого?✅ 2023/12/19 06:52, Вежлиный Лис #3 Параллелизация. Если разделить весь код на чистый и грязный (а обещают, что чистого в программе более 90 процентов), то можно проводить автоматизированную параллелизацию его чистой части. Очень актуально для процессоров с 32+ ядрами.✅ 2023/12/20 18:45, Автор сайта #4 Всё так и есть. Прогресс процессоров вынужденно пошёл по пути увеличения числа ядер. Чистые функции помогают «лишние» ядра задействовать. Стоит отметить, что фунциональное программирование так же помогает повысить безошибочность ПО. Во-первых, с помощью доказательного программирования. Во-вторых, полным или частичным тестированием. В-третьих, дублируя функции, когда по очереди работают разные версии одной и той же функции, а потом из полученных результатов путём «голосования» выбирается правильный. Это собственное ноу-хау: «Надёжные программы из ненадёжных компонентов». Последний вариант тоже утилизирует «лишние» ядра.Программы, целиком состоящие из чистых функций, действительно не нужны. Британские же учёные утверждают, что в Хаскелле всё функции чистые. И хотят, чтобы джентльменам верили на слово. Я же вижу логическое противоречие между утверждением о поголовной чистоте функций в Хаскелле и программами на нём, содержащими недетерминированность и побочные эффекты. Написать автору можно на электронную почту |
Продолжение цикла и выход из него