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

_>Только вот в большинстве случаев ФП не эффективно, так что используют подобное редко, скорее для развлечения.

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

_>Причём речь не реализации ФП в каком-то конкретном языке, а о противоречие самих принципов ФП оптимальной производительности.

Это, в основном, верно.

_>Простой пример. Вот делаем мы фильтрацию видео в реальном времени, причём набор фильтров настраивается пользователем. Казалось бы чисто алгоритмическая задачка и оптимальна для ФП. Но что мы получим, следуя классическим принципам ФП, типа иммутабельности данных? Допустим у нас будет десяток фильтрующих функций (последовательно применяющихся, в зависимости от настроек пользователя) и каждая из них должна будет создавать новую копию кадра (а это между прочим 2 миллиона точек по 2 или 4 байта)? И это всё 30 или 60 раз в секунду? А уж как кэш процессора реагирует на подобные вещи... ))) В то время как в любом императивном языке у нас будет работать ровно один буфер для данных, начиная от захвата и заканчивая выводом кадра. Причём для всех кадров. И все функции будут спокойно работать с этим буфером.

Мутабельность данных никак не противоречит идиоматическому ФП-подходу, если она семантически ненаблюдаема. Даже в обсуждаемом по соседству "хэллоуворлде" данные под капотом мутируются со страшной силой. Так и в вашем примере, промежуточные структуры данных не нужны, если не разделяются между несколькими потребителями, а просто передаются от производителя к одному потребителю.

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

EP>Нет — речь была не про ФП.

Да. Разговор был именно о ФП, точнее о том, что усилия необходимые для использования зачаточного фп-стиля в C++ превышают бенефиты от использования зачаточного ФП-стиля.

EP>Особенно оно не нужно там, где плохо мэппится в реальное железо.

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

EP>В сам язык ЛП не встроено. Но возможны библиотечные средства, причём как runtime, так и compile-time (на базе шаблонов или чистых функций).

Речь о том, что реализаций ЛП-языков даже с таким уровнем практичности в качестве языков общего назначения как у ФЯ в настоящее время не существует и не ожидается.

EP>Приведите другое определение UFP.

Захват в замыкание З ссылки на A продлевает жизнь А по крайней мере на время жизни замыкания З.

EP>Почему не работает для памяти?

Потому, что в высокоуровневых языках есть гарантия (разной степени силы/слабости, но достаточно хорошая, чтоб на нее можно было полагаться), что ссылка на некую языковую сущность работает: пока доступна ссылка, языковая сущность (объект в ООП, например) также существует. Такой гарантии в C++ нет.

EP>Они не считаются дефицитными до тех пор, пока GC не начинает захлёбываться.

Да, но этого достаточно, потому что в большинстве случаев он работает нормально. Исчерпать ресурсы, которые классифицируются как "дефицитные" несравнимо проще.

EP>Например GC'шники знают про stop-the-wrold, generations, off-heap, фрагментация Large Object Heap и т.п., подстраивают свой код соответствующим образом — и это как раз потому, что нет никакого "just works".

В основном есть. Потому, что сама система управления памяти "компактифицирующий GC с поколениями и некомпактифицируемым хипом для больших объектов" — это подстройка под типичный ООП/ФП код, обеспечивающий хорошую производительность для идиоматического кода. Проблемы начинаются после выхода из этой "благоприятной" области, на которую система и настроена.

EP>2. UFP — это передача замыкания выше области free variables, так? Free variable может чем угодно, а не только памятью

Free variable не может быть чем угодно. Это языковая сущность. "Память" — это уже другой, нижележащий уровень абстракции. UFP гарантирует продление жизни языковой сущности. Т.е. объекта File, а не файла, хендлером для которого этот файл является.

EP>Работающего [&] не будет даже при включённом GC. Даже при использовании GC нужен будет [=]

В высокоуровневом языке различие между передачей по ссылке и копированием вообще чаще всего семантически ненаблюдаемо. Соотвественно и никаких настроечных ручек у замыканий нет.

EP>Вообще-то вопрос был про то, как в Haskell передать замыкание с ресурсом-free-variable наверх. Region'ы судя по всему это проблему никак не решают, поэтому вопрос остаётся открытым.

Регионы предотвращают утечку ресурса.

EP>Ну да, нет нормального решения — "бессмысленно"

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

EP>Я просто прошу показать, или описать — как подобное возможно в Haskell. Какими средствами это будет достигнуто неважно (неважно будет ли эта система тождественна управлению дефицитными ресурсами или нет) — важен результат.

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

EP>

EP>    public delegate void fireworks();
EP>    public static fireworks fire()
EP>    {
EP>        using (var fs = File.Open("file", FileMode.Open))
EP>        {
EP>            return () => fs.Read(new byte[10], 0, 10);
EP>        }
EP>    }
EP>

EP>1. замыкание есть?

Да.

EP>2. free-variable в замыкании есть?

Есть.

EP>3. замыкание передаётся выше области free-variable?

Да.
При использовании using с корректностью замыкания ничего не случится, время жизни объекта-хендлера будет продлено, но файл для которого он является хендлером будет закрыт в момент возвращения лямбды из функции. Если using убрать, то управление открытием файла будет связано с управлением временем жизни его хендлера-объекта. Память, занятая объектом будет переиспользована не раньше, чем объект перестанет быть доступным (что требуется для решения UFP), произойдет это через какое-то зависящее от разных обстоятельств время (что продиктовано свойствами системы управления памятью). Через какое-то время, зависящее от разных обстоятельств, после этого выполнится и код, закрывающий файл (что создает проблему для prompt finalization). Но не существует никакой гарантии, что это не произойдет до завершения жизни объекта-хендлера. Т.е. решить и UFP и проблему prompt finalization управляя двумя видами ресурсов одним способом нельзя.

EP>Это в этом варианте?

А в чем вы видите противоречие? Вы с тем, на что я ссылался ознакомились?

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

EP>Что означает "идиоматический ФП-код"?

Комбинирование комбинаторов.

EP>Это синоним кода который тормозит?

Да. Чтоб такой код работал с более-менее приемлемой скоростью нужен специальный рантайм, заточенный под такие вещи и компилятор со специфическими оптимизациями. Поэтому в каком-нибудь гибриде, в который добавили функциональных фич потому, что это "модно" идиоматический ФП код (если его еще и получится написать) запросто может отличаться по производительности от кода а-ля фортран как скриптовый язык от компилируемого статтипизированного.

EP>То есть на равном месте вводится межпоточная синхронизация, об этом и речь.

А вы точно читали то, на что я ссылаюсь?

EP>Кстати, а что делать с thunk'ом который точно не будет использоваться, но держит ссылку на большую структуру или ресурс? Утечка?

"Точно не будет использоваться" только thunk, который ниоткуда не доступен — такой будет собран ГЦ (неизвестно, правда, когда). А вот thunk, который не использовался, хотя точно об этом можно сказать только по завершению работы программы — это да, утечка.
Чтоб организовать утечку, собственно, не требуется что-то никогда не использовать. Достаточно производить thunk-и медленнее, чем они потребляются.

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

_>Так с этим никто и не спорит. Собственно поэтому термин "обобщённое программирование" и относят обычно к указанным языкам, хотя в Хаскеле это тоже полностью реализовано.

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

_>Работа во время компиляции просто разная может быть. Возможно строго по правилам компилятора и всё. А возможно по указаниям программиста. )

Это как-то можно раскрыть?

_>Речь немного не о том. Вот допустим у нас есть некая чистая функция. В Хаскеле или C++ (у C++ есть свои способы исполнения кода во время компиляции, но он должен быть сформирован очень особым образом и имеет много ограничений) мы можем её исполнить только в рантайме. В D мы можем спокойно вызвать прямо эту функцию во время компиляции (при условии, что передадим ей данные, доступные во время компиляции, но это может быть и например содержимое внешнего файла). Причём в этом случае компилятор именно исполнит всё и вставит результат (кстати возможно тоже код) в бинарник, а кода самой функции там не будет вообще.

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

{-# LANGUAGE TemplateHaskell #-}
module Main (main) where

import Language.Haskell.TH.Syntax

-- main = print $ sum [1 .. 10000000 :: Integer] -- считаем в рантайме
main = print $(lift $ sum [1 .. 10000000 :: Integer]) -- считаем во время компиляции

Обычное метапрограммирование, параметрический полиморфизм тут не причем.

_>Причём это всё соберётся в бинарник с супербыстродействием.

Это точно про D? Он вроде супербыстродействием никогда похвастать не мог.

_>Я же говорю, напрямую нет смысла сравнивать. А по возможностям вполне можно.

Почему нет смысла сравнивать напрямую?

_>Да пожалуйста. ))) Такое впечатление, что демонстрация аргументации под ваши тезисы — это мне надо. ))) Ну нет, так нет. Значит тот ваш тезис так и останется просто болтовнёй. )

Такое впечатление, что демонстрация аргументации под ваши тезисы — это мне надо. Ну нет, так нет. Значит тот ваш тезис про "ужасы большой монады" так и останется просто болтовнёй.

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

K>>Да ну? Иммутабельные структуры данных для того и нужны, чтоб иметь несколько версий, разделяющих значительную часть данных, одновременно. Какая же это специфика языка?

_>С чего бы это? Иммутабательные структуры нам нужны для того, чтобы у функций не было состояний. Не надо путать принципы ФП и конкретную реализацию. Если вы замените в реализации ФП языка все ссылки на копирования, то абсолютно ничего, кроме быстродействия, не изменится.

ОК, разделять данные между версиями в теории не обязательно. Но никакой специфики языка тут нет. В библиотеках для ФЯ эти структуры реализуются так, что данные разделяются.

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

EP>>>>Кстати, про эффективность, а как thunk'и обновляются в многопоточной среде?
K>>>Глава 3
EP>>То есть на равном месте вводится межпоточная синхронизация, об этом и речь.
K>А вы точно читали то, на что я ссылаюсь?

Точно. Там используется lock-free алгоритм для межпоточной синхронизации

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

EP>>Узлы до сих пор фон-Неймановские
I>Это чтото новое, очень интересное — внезапно архитектура системы определяется архитектурой подсистем.

Ты вообще о чём? Распределённая система не снимает необходимости написания кода для узлов.
Если код для узлов будет в 10x раз медленней, то самих узлов понадобится минимум в 10x раз больше, а то и в 50x — за счёт расходов на коммуникацию

I>Надо полагать танковый батальон устроен точно так же как и танк ?

Танковый батальон — он "танковый", а не "пехотный". И между "танковыми батальоном" и "пехотным" — огромная разница

EP>>Что же касается организации распределённых вычислений — то да, тут естественно используются некоторые элементы присущие ФП стилю.
I>Некоторые элементы присущие ФП стилю используюся везде.

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

Я, например, стараюсь: делать чистые функции, там где чистые не получаются — регулярные, использовать функции высшего порядка — они часто являются действительно удобными, использовать non-member functions вместо методов, использовать ленивость по мере необходимости, использовать неизменяемые объекты или давать объектам value-semantics (привет referential transparency). Все эти элементы хорошо поддерживаются в C++, причём они прекрасно сочетаются с обычным ИП.

I>Более того — ФП влазло и в нативный код.

Подробнее.

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

I>>Это чтото новое, очень интересное — внезапно архитектура системы определяется архитектурой подсистем.

EP>Ты вообще о чём? Распределённая система не снимает необходимости написания кода для узлов.
EP>Если код для узлов будет в 10x раз медленней, то самих узлов понадобится минимум в 10x раз больше, а то и в 50x — за счёт расходов на коммуникацию

Это цифры с потолка. Эрланг показывает и доказывает что твои рассуждения ошибочны.

I>>Надо полагать танковый батальон устроен точно так же как и танк ?

EP>Танковый батальон — он "танковый", а не "пехотный". И между "танковыми батальоном" и "пехотным" — огромная разница

Ну да, и устроен он как танк.


I>>Более того — ФП влазло и в нативный код.

EP>Подробнее.

Ты не заметил лямбды в С++ ? Чудеса !

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

EP>>Для начала ответь на вопросы выше — там про управление ресурсами ничего не сказано.
I>Ну разумеется, всё есть.

Значит есть UFP?

I>>>Можно ли в замыкание С++ передать скажем, неинициализированый указатель или указатель на освобожденную память ?
EP>>Можно, точно также как и в других языках:
I>То есть — аналогичная проблема — вернуть в лямбде мусор есть и в С++.

Да, в C++ в замыкании можно вернуть мусор, точно также как и в C# и в Haskell.

I>Или в С++ есть некий фокус компилятора, благодаря которому юзер догадается что надо написать специальный оператор присваивания или конструктор копирования ?

В каком случае? Если, например, в замыкание move'нуть unique_ptr — то оно будет movable, but not copyable — компилятор не даст скопировать такое замыкание.

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

I>>>Это чтото новое, очень интересное — внезапно архитектура системы определяется архитектурой подсистем.
EP>>Ты вообще о чём? Распределённая система не снимает необходимости написания кода для узлов.
EP>>Если код для узлов будет в 10x раз медленней, то самих узлов понадобится минимум в 10x раз больше, а то и в 50x — за счёт расходов на коммуникацию
I>Это цифры с потолка. Эрланг показывает и доказывает что твои рассуждения ошибочны.

Какие именно рассуждения, и как он доказывает?
Кстати, про Erlang — выше приводили пример "идиоматичного ФП кода":

f = 0 : 1 : zipWith (+) f (tail f)

попробуй изобрази его на Erlang.
Да, и по-твоему Erlang это чистый ФП?

I>>>Надо полагать танковый батальон устроен точно так же как и танк ?
EP>>Танковый батальон — он "танковый", а не "пехотный". И между "танковыми батальоном" и "пехотным" — огромная разница
I>Ну да, и устроен он как танк.

Устроен танковый батальон естественно не как танк, но без танков нет батальона. Ты что сказать-то хотел своей метафорой?

I>>>Более того — ФП влазло и в нативный код.
EP>>Подробнее.
I>Ты не заметил лямбды в С++ ? Чудеса !

Это не чистое ФП, а как раз полезные его элементы. И "влазло" оно очень давно.
См. например STL — там же кругом value semantics (привет referential transparency) и higher order functions.

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

EP>>>Для начала ответь на вопросы выше — там про управление ресурсами ничего не сказано.
I>>Ну разумеется, всё есть.

EP>Значит есть UFP?

Есть.

I>>Или в С++ есть некий фокус компилятора, благодаря которому юзер догадается что надо написать специальный оператор присваивания или конструктор копирования ?

EP>В каком случае? Если, например, в замыкание move'нуть unique_ptr — то оно будет movable, but not copyable — компилятор не даст скопировать такое замыкание.

То есть, в кратце, тебе не нравится, что IDisposable это всего лишь рекомендация, и нет способа сделать это обязательным требованием. Правильно?

Вопрос — при чем здесь замыкания ?

RelationalFlatFileReader F()
{
   using(var f = File.Open(...))
   {
     return new RelationalFlatFileReader{File = f};
   }
}

Something удерживает и использует ссылку на File. Вопрос — очевидно ли, что
1 проблема та же, что и с замыканием ?
2 замыканий нигде нет ?

Снова вопрос — при чем здесь замыкания ?

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

EP>>>>Для начала ответь на вопросы выше — там про управление ресурсами ничего не сказано.
I>>>Ну разумеется, всё есть.
EP>>Значит есть UFP?
I>Есть.

И в C# нет более-менее автоматического решения UFP для такого случая?

I>>>Или в С++ есть некий фокус компилятора, благодаря которому юзер догадается что надо написать специальный оператор присваивания или конструктор копирования ?
EP>>В каком случае? Если, например, в замыкание move'нуть unique_ptr — то оно будет movable, but not copyable — компилятор не даст скопировать такое замыкание.
I>То есть, в кратце, тебе не нравится, что IDisposable это всего лишь рекомендация, и нет способа сделать это обязательным требованием. Правильно?

Я просто привёл один из примеров UFP — для которого в C# и Haskell нет более-менее автоматического решения, а в C++ есть.
Даже если использовать определение UFP, которое ограничивается только памятью — то сама проблема никуда не девается, и то что она очень похожа на UFP — это факт.

I>Вопрос — при чем здесь замыкания ?
I>[...]
I>Something удерживает и использует ссылку на File. Вопрос — очевидно ли, что
I>1 проблема та же, что и с замыканием ?
I>2 замыканий нигде нет ?
I>Снова вопрос — при чем здесь замыкания ?

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

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

I>>Это цифры с потолка. Эрланг показывает и доказывает что твои рассуждения ошибочны.

EP>Какие именно рассуждения, и как он доказывает?

На нём пишутся распределенные системы, внезапно ! Эрланг собтсвенно и начал с того, что порвал С++ в распределенных приложениях для телекоммуникаций.

EP>Кстати, про Erlang — выше приводили пример "идиоматичного ФП кода":
EP>

EP>f = 0 : 1 : zipWith (+) f (tail f)
EP>

попробуй изобрази его на Erlang.
EP>Да, и по-твоему Erlang это чистый ФП?

Это скучно.

I>>>>Надо полагать танковый батальон устроен точно так же как и танк ?
EP>>>Танковый батальон — он "танковый", а не "пехотный". И между "танковыми батальоном" и "пехотным" — огромная разница
I>>Ну да, и устроен он как танк.

EP>Устроен танковый батальон естественно не как танк, но без танков нет батальона. Ты что сказать-то хотел своей метафорой?

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

I>>Ты не заметил лямбды в С++ ? Чудеса !

EP>Это не чистое ФП, а как раз полезные его элементы. И "влазло" оно очень давно.

Ажно с первых версий stl.

EP>См. например STL — там же кругом value semantics (привет referential transparency) и higher order functions.

Вот-вот. Сколько лет stl ?

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

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

Если это состояние хранится в самой функции, то это уже не ФП. А если передаётся в неё как параметр (и при этом естественно является иммутабельным), то никаких проблем.

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

Не придумывай. ))) Это всего лишь одно из полезных побочных свойств ФП, а совсем не причина такого устройства. Более того, существование подобных плюсов проявилось относительно недавно, когда появилось многопоточное программирование и т.п., хотя языки с таким устройством существовали уже давным давно. )

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

I>Каким образом мерить эффективность?

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

I>ФП ничему не противоречит. Ты путаешь особенности вычислителя и требования ФП.

Ты можешь предложить реализацию ФП с не иммутабельными данными? )

I>А теперь представь себе распределенное приложение. Внезапно <любой императивный язык> слился весьма бесславно. Ты, конечно, можешь выкрутиться навроде "даже если одна функция написана на С++" значит и всё приложение написано на С++.

Что ты подразумеваешь под "распределённым приложением"? Что-то типа MPI? И почему это любой императивный язык тут сливается? )

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

EP>>>Значит есть UFP?
I>>Есть.

EP>И в C# нет более-менее автоматического решения UFP для такого случая?

Есть, с экземпляром класса File всё в порядке, он не разрушается и тд. Скажем, при подходе как в старом турбопаскале ты бы получил непойми что уже при попытке вызова метода, навроде Access Violation и тд.

I>>>>Или в С++ есть некий фокус компилятора, благодаря которому юзер догадается что надо написать специальный оператор присваивания или конструктор копирования ?
EP>>>В каком случае? Если, например, в замыкание move'нуть unique_ptr — то оно будет movable, but not copyable — компилятор не даст скопировать такое замыкание.
I>>То есть, в кратце, тебе не нравится, что IDisposable это всего лишь рекомендация, и нет способа сделать это обязательным требованием. Правильно?

EP>Я просто привёл один из примеров UFP — для которого в C# и Haskell нет более-менее автоматического решения, а в C++ есть.

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

EP>Даже если использовать определение UFP, которое ограничивается только памятью — то сама проблема никуда не девается, и то что она очень похожа на UFP — это факт.

I>>Вопрос — при чем здесь замыкания ?
I>>[...]
I>>Something удерживает и использует ссылку на File. Вопрос — очевидно ли, что
I>>1 проблема та же, что и с замыканием ?
I>>2 замыканий нигде нет ?
I>>Снова вопрос — при чем здесь замыкания ?

EP>Я согласен что подобная проблема существует и без замыканий. Возможно в UFP замыкания выделяются отдельным образом потому, что захват контекста происходит достаточно неявно.

1 Она существует без замыканий
2 Замыкания не теряют связь с локальными переменными, никогда, ни при каких случаях, до момента сборки мусора.

Единственное исключение в C# это указатели в unsafe. В С++ добавляется еще куча исключений из за отсутствия GC .

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

I>Выдай правило, которое расскажет когда же делать эту распаковку, а когда — нет.

В смысле когда? Всегда естественно) Ну если конечно эта функция не сводится к комбинации нескольких других такого же типа.

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

EP>>Я просто привёл один из примеров UFP — для которого в C# и Haskell нет более-менее автоматического решения, а в C++ есть.
I>UFP это про локальное состояние, т.е. когда функция теряет связь с локальными переменными. Не ресурсы теряет, а всего лишь переменные из скопа.
[...]
I>2 Замыкания не теряют связь с локальными переменными, никогда, ни при каких случаях, до момента сборки мусора.

Допустим у нас такое определение — ОК.
Что делать в случае, когда захватываются ресурсы? (пусть это не относится к UFP по данному выше определению)

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

I>Я тут на выходных посмотрел этот тред и чет не пойму твоих стонов про IO/ST в Хаскеле, поставил даже wxHaskell и wxwidgets и всё равно не ясно.

Мой вопрос про ST/IO в Хаскеле не имеет никакого отношения к wxHaskell, просто Klapaucius не отвечает на мой вопрос под предлогом того, что я не ответил на его вопрос про wxHaskell (хотя на самом деле ответил даже два раза). А мой вопрос был вызван тем, что Klapaucius заявил, что система ST/IO Хаскеля предоставляет некие дополнительные возможности, которых просто нет в других языках вообще. Я Хаскель смотрел когда-то, но не очень подробно (он мне не понравился после написания нескольких тестовых приложений и я его стёр), так что вполне допускаю, что мог это пропустить. Поэтому я попросил Klapaucius'а развить эту мысль и желательно на практических примерах. Однако, как видишь, никаких примеров в темке так и не было, так что подозреваю, что ничего такого я тогда так и не пропустил... )))

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

K>Мутабельность данных никак не противоречит идиоматическому ФП-подходу, если она семантически ненаблюдаема. Даже в обсуждаемом по соседству "хэллоуворлде" данные под капотом мутируются со страшной силой. Так и в вашем примере, промежуточные структуры данных не нужны, если не разделяются между несколькими потребителями, а просто передаются от производителя к одному потребителю.

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