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

EP>Насколько я понял, именно опыта там и не было. Вот что написано перед вышеприведённой цитатой:
EP>

MLton does not use region-based memory management; it uses traditional GarbageCollection. We have considered integrating regions with MLton, but in our opinion it is far from clear that regions would provide MLton with improved performance, while they would certainly add a lot of complexity to the compiler and complicate reasoning about and achieving SpaceSafety. Region-based memory management and garbage collection have different strengths and weaknesses; it’s pretty easy to come up with programs that do significantly better under regions than under GC, and vice versa.

EP>То есть они рассматривали, но не пробовали.

Как не было? Одни разработчики компилятора SML (преимущественно экспериментального) — MLKit попробовали, сделали работающую реализацию, описали свой опыт в статьях. Другие разработчики другого компилятора SML (преимущественно "практического") — MLton, которые и сами собирались работать в этом направлении, оценили результаты как провальные и сами в этом направлении работать не стали. То, что вы цитируете — это именно из их заключения, но ссылки на статьи, на основании которых они его сделали там есть.

EP>Про "неработающие" замыкания в C++ из-за UFP любители GC мне тут уже третий раз говорят, хотя "плюсисты" не имеют с этим проблем. На деле же оказывается что работают, и не только для памяти.

Ну правильно: используют не ФЯ, идиомы не ФП — с чего бы им испытывать с этим проблемы, если все тропы протоптаны там, где их нет. Проблемы никуда не делись, просто они обходятся. Если же такие "решения" будут в ФП языке и программировать на нем будут с использованием ФП идиом — эти несчастные поимеют все проблемы по полной программе.

EP>ФП нужно, но не везде.

Особенно оно не нужно там, где невозможно.

EP>Никто не говорил что высокоуровневое программирование не нужно. Высокоуровневое это далеко не только ФП.

Точно, еще и ЛП есть. Как в плюсах с ЛП? Хотя чего там, с ним везде плохо.

EP>Как минимум есть решение UFP в виде копирования (что является именно решением согласно wiki).

Это, конечно, здорово, что какой-то обидевшийся за свой язык без решения UFP (тут просто бездна вариантов, конечно), написал это в викистатье, но вы сами-то рассудите здраво: копирование появилось задолго до того, как изобрели ссылки и сформулировали UFP. Как же так получается? Придумали проблему через годы после решения?

EP>Причём это работает не только для памяти.

Оно "работает" не только для памяти именно потому, что нормально не работает для памяти. Про странное сшивание управления дефицитными ресурсами с ресурсами которые в высокоуровневых языках дефицитными не считаются я уже в соседнем посте упоминал.

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

Да ну? А что вы скажете о том, когда проблемой UFP называют что-то иное, и на этом основании объявляют решенной.
Ладно, вы можете считать UFP все что угодно, я просто сформулирую свой критерий поддержки ФП другими словами, в контексте разговора понятными: нет работающего [&] — нет базовой поддержки ФП.

EP>Из дочернего региона в родительский возвращаются сами handle'ы, а не замыкания с хэндлами внутри?

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

EP>это же совсем не то, мы же про UFP говорим.

Вот именно. Говорили про UFP а вы все какое-то закрытие ресурсов по завершении использования приплетаете. Просто как в анекдоте про студента, который выучил только билет про блох, а попался вопрос про рыб.

EP>Собираются все действия над всеми ресурсами в одном месте, причём они могут быть interleaved, и зависить один от другого.
EP>В описанном же выше варианте действия над одним ресурсом собираются в одном месте, и только в нём. Это и есть ограничение.

В описанном выше варианте речь именно о "действия над всеми ресурсами в одном месте, причём они могут быть interleaved, и зависить один от другого".

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

EP>Хороший пример цикла привнесённого самим языком.

В данном случае — идиоматическим ФП-кодом. На языке можно вычисление числе Фибоначчи и как на паскале написать. Другое дело — зачем тогда вообще ФЯ пользоваться?

EP>Кстати, про эффективность, а как thunk'и обновляются в многопоточной среде?

Глава 3

EP>Это пример разделяемого владения. Если у нас есть персистентная и полностью иммутабельная структура, типа rope, где ссылки и узлы образуют directed acyclic graph — то прекрасно подходит ref-counting.

Ну да, а еще на эти узлы будут ссылки из структур с циклами. Да и в ФП rope будет скорее построена на структуре данных, использующей ленивость вроде finger-tree.

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

EP>>Это же и есть upwards funarg?
K>Нет, это сначала непонятно на чем основанное связывание prompt finalization проблемы и UFP, констатация простого факта, что их решения сочетаются плохо и выведение отсюда того, UFP не решается.

Оставим prompt finalization в стороне. Вот есть у нас using на ресурс в C#, или регион в Haskell — можем ли мы сделать замыкание на идентификатор ресурса (в funarg ведь про идентификаторы речь) и передать это замыкание наверх?

EP>>Не так. ФП нужно, но далеко не везде. Писать на C++ только в ФП стиле не имеет смысла.
K>Я сильно сомневаюсь, что писать на C++ в ФП стиле не то что имеет смысл, а вообще возможно. Если только не трактовать ФП стиль сильно расширительно.

На haskell.org написанно:

The following table shows which languages support functional programming (by supporting first-class functions) and for which the functional style is the dominant one.

В этой табличке для C++:

support functional programming by supporting first-class function

functional style is NOT the dominant one


EP>>В том примере нужна не ленивость, а monadic код. Ленивость помогла только в одном случае из двух, и как видно в общем случае не позволяет сделать обычный код монадичным.
K>Ничего не понимаю. Ленивость не делает код монадическим. Она нужна, чтоб функции, полученные как результат комбинации других не делали лишние вычисления/проходы. Т.е. в обсуждаемом случае нужна, чтоб монадический код нормально работал.

Для монады Maybe, ленивость позволяет foldr работать так, как работал бы foldrm.

K>И что за один случай из двух?

foldl

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

K>Я сильно сомневаюсь, что писать на C++ в ФП стиле не то что имеет смысл, а вообще возможно. Если только не трактовать ФП стиль сильно расширительно.

Да ладно, вот например https://github.com/beark/ftl народ развлекается по полной. )))

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

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

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

EP>>Про "неработающие" замыкания в C++ из-за UFP любители GC мне тут уже третий раз говорят, хотя "плюсисты" не имеют с этим проблем. На деле же оказывается что работают, и не только для памяти.
K>Ну правильно: используют не ФЯ, идиомы не ФП — с чего бы им испытывать с этим проблемы, если все тропы протоптаны там, где их нет.

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

EP>>ФП нужно, но не везде.
K>Особенно оно не нужно там, где невозможно.

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

EP>>Никто не говорил что высокоуровневое программирование не нужно. Высокоуровневое это далеко не только ФП.
K>Точно, еще и ЛП есть. Как в плюсах с ЛП? Хотя чего там, с ним везде плохо.

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

EP>>Как минимум есть решение UFP в виде копирования (что является именно решением согласно wiki).
K>Это, конечно, здорово, что какой-то обидевшийся за свой язык без решения UFP (тут просто бездна вариантов, конечно), написал это в викистатье,

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

K>но вы сами-то рассудите здраво: копирование появилось задолго до того, как изобрели ссылки и сформулировали UFP. Как же так получается? Придумали проблему через годы после решения?

Очевидно же: у проблем могут быть разные решения, с разными свойствами.
Например не во всех языках встроен удобный deep copy.

EP>>Причём это работает не только для памяти.
K>Оно "работает" не только для памяти именно потому, что нормально не работает для памяти.

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

K>Про странное сшивание управления дефицитными ресурсами с ресурсами которые в высокоуровневых языках дефицитными не считаются я уже в соседнем посте упоминал.

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

EP>>В языках же с GC с этим начинаются проблемы, и раз там нет нормального решения для этого варианта UFP, то естественно проблема декларируется несущественной/надуманной/нереальной/непрактичной:
K>Да ну? А что вы скажете о том, когда проблемой UFP называют что-то иное, и на этом основании объявляют решенной.

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

K>Ладно, вы можете считать UFP все что угодно, я просто сформулирую свой критерий поддержки ФП другими словами, в контексте разговора понятными: нет работающего [&] — нет базовой поддержки ФП.

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

EP>>Из дочернего региона в родительский возвращаются сами handle'ы, а не замыкания с хэндлами внутри?
K>Вообще-то смысл систем с регионами в том, чтоб предотвратить утечку хэндла из региона, но "при этом действия с ресурсами могут быть interleaved, и зависить один от другого".

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

K>Вам же нужна система автоматизации утекания хендлов в неизвестном направлении, о бессмысленности которой я не устаю повторять.

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

K>Т.е. вы отождествляете систему управления ресурсами, требующими систему вроде регионов (файлов), и систему управления ресурсами, которые дефицитными не являются и потому могут управляться системой, ограничения "регионов" преодолевающей.

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

EP>>это же совсем не то, мы же про UFP говорим.
K>Вот именно. Говорили про UFP а вы все какое-то закрытие ресурсов по завершении использования приплетаете. Просто как в анекдоте про студента, который выучил только билет про блох, а попался вопрос про рыб.

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

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

EP>>Собираются все действия над всеми ресурсами в одном месте, причём они могут быть interleaved, и зависить один от другого.
EP>>В описанном же выше варианте действия над одним ресурсом собираются в одном месте, и только в нём. Это и есть ограничение.
K>В описанном выше варианте речь именно о "действия над всеми ресурсами в одном месте, причём они могут быть interleaved, и зависить один от другого".

Это в этом варианте:

K>Более-менее осмысленное решение, это делать функцию вида ЭтоНамНадоЧтобПолучитьРесурс -> (ОткрытыйРесурс -> Результат) -> Результат, которая сначала собирает через второй аргумент функции, которые что-то будут с ресурсом делать, а потом выполняется сама, открывая ресурс, скармливая всем этим функциям и закрывая его. Т.е. те самые брекеты и их развитие вроде pipes-safe и resourcet.
?

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

K>В данном случае — идиоматическим ФП-кодом. На языке можно вычисление числе Фибоначчи и как на паскале написать. Другое дело — зачем тогда вообще ФЯ пользоваться?

Что означает "идиоматический ФП-код"? Это синоним кода который тормозит?
Кстати, про <b>числа Фибоначчи через мемоизацию</b>.

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

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

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

K>Вообще, то, что называется обобщенным программированием в С++ и других языках, где возможности для него появились в ходе развития языка, в языках где такие возможности были с самого начала вроде хаскеля никак специально не называется. Ну, нет ситуации, когда есть сформированная культура кодирования, и вдруг появляется новая, с использованием параметрического полиморфизма. Потому и дженериками там называются совсем другие вещи.

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

K>Параметрический полиморфизм, как и все что касается типов, бывает только времени компиляции. Речь о том, что то, что есть в плюсах не типизируется и потому типов как-то особо и не касается, а больше похоже на кодогенерацию.

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

K>Не понимаю, зачем протягивать в язык метапрограммирование через такую гм... заднюю дверь. Я D не знаю, но судя по увиденным примерам, это именно метапрограммирование, а не код на тайплевеле как в языках с полноценной системой типов т.е. с омегой/завтипами.

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

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

Естественно это всё уже не относится к теме обобщённого программирования — это я просто отвлёкся на пересекающуюся тему.

K>Почему? Параметрический полиморфизм совершенно точно есть и в хаскеле и в сишарпе и в яве. Просто в хаскеле даже без расширений возможностей больше, вроде абстрагирования от конструктора типа. Сравнивать вполне можно. В статье на которую я ссылку давал продемонстрированы подходы, которые отличаются гораздо сильнее.

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

K>Неужели вы уже где-то запостили сравнение и критику "кода в большой монаде" или как там вы это называете и императивного? Думаете, если вы будете бесконечно требовать что-то от меня, полностью игнорируя мои требования я о них забуду? Сразу говорю: этого не произойдет.

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

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

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

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

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

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

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

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

_>Только вот в большинстве случаев ФП не эффективно

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

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

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

_>Простой пример. Вот делаем мы фильтрацию видео в реальном времени, причём набор фильтров настраивается пользователем. Казалось бы чисто алгоритмическая задачка и оптимальна для ФП.

Из чего следует это "казалось бы" ?

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

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

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

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

S>>Проблема в том, что вы заранее не знаете, где какой код. У вас может смешиваться код, "знающий", что такое optional, и код, который ничего о нём не знает. Чтобы это решить, вам придётся либо явно описывать упаковку/распаковку в перегрузках LibFunc, либо всё-таки сделать из Optional монаду.

_>Ну так если в вашем пример функции уже есть упаковка в optional, то почему бы не быть и распаковке? )

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

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

K>>Вот именно. Говорили про UFP а вы все какое-то закрытие ресурсов по завершении использования приплетаете. Просто как в анекдоте про студента, который выучил только билет про блох, а попался вопрос про рыб.

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>

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

Ты снова путаешь замыкания и управление ресурсами.

Можно ли в замыкание С++ передать скажем, неинициализированый указатель или указатель на освобожденную память ?

Опаньки !

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

EP>Цель абстракции — описать мир, причём эффективно, а не придумать его. Пока у нас у всех фон-Нейманавские машины — чистый ФП будет находится на академической обочине.

Вычислители уже давно переросли фон-Неймановскую архитектуру. Пример — распределенные вычисления.

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

EP>>>Причём это работает не только для памяти.
K>>Оно "работает" не только для памяти именно потому, что нормально не работает для памяти.

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

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

K>>Про странное сшивание управления дефицитными ресурсами с ресурсами которые в высокоуровневых языках дефицитными не считаются я уже в соседнем посте упоминал.

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

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

Я бы сказал что нативный и менеджед миры изоморфны, т.е. любой из баззвордов типа "generations" имеет прямое отражение в с++.
Разница всего лишь в кривой вхождения. Если в менеджед эти баззворды нужны для экспертов, то в С++ первые три года люди получают самые азы — указатели, смартпоинтеры, счетчики ссылок и тд и тд и тд
Без этого просто нереально разрабатывать на с++.

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

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

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

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

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>>

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

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

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

Можно, точно также как и в других языках:

public delegate void fireworks();
public static fireworks fire()
{
    unsafe
    {
        int x = 11;
        int* p1 = &x, p2 = null;
        return () => { *p1 = 111; Console.WriteLine("alive!"); *p2 = 111; };
    }
}
public static void Main()
{
    var closure = fire();
    closure();
}

:

I>Опаньки !

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

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

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

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

EP>Узлы до сих пор фон-Неймановские

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

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

Некоторые элементы присущие ФП стилю используюся везде. Сейчас 90% кода это не нативный код и в ём обычное дело функциональщина.

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

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

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

Ну разумеется, всё есть.

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

EP>Можно, точно также как и в других языках:

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

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

EP>Оставим prompt finalization в стороне. Вот есть у нас using на ресурс в C#, или регион в Haskell

Ну да. Оставляем prompt finalization в стороне и сразу переходим к prompt finalization!

EP>можем ли мы сделать замыкание на идентификатор ресурса (в funarg ведь про идентификаторы речь) и передать это замыкание наверх?

В C# можем, в хаскеле есть средства для предотвращения этого а-ля ST.

EP>На haskell.org написанно:
EP>

EP>The following table shows which languages support functional programming (by supporting first-class functions) and for which the functional style is the dominant one.

EP>В этой табличке для C++:
EP>support functional programming by supporting first-class function
EP>functional style is NOT the dominant one

А если я в какой-нибудь вики напишу, что луна из сыра — вы поверите? Ну попробуйте тот же функциональный "хэллоуворлд" на C++ написать

fibs = fix $ (1:) . (1:) . (zipWith (+) <*> tail)

> fibs !! 100
573147844013817084101

И расскажете потом, сильно ли вам помогло то, что в какой-то вики написано, что C++ поддерживает ФП.

EP>Для монады Maybe, ленивость позволяет foldr работать так, как работал бы foldrm.

Не знаю, что вы подразумеваете под foldrm, foldr работает как foldr, а foldM совсем другая функция:

foldM :: Monad m => (a -> b -> m a) -> a -> [b] -> m a

т.е. сворачивание с эффектом.
foldr же в обсуждаемом примере просто расставляет лифтнутые (+) между элементами списка.

foldr (+) :: (Monad m, Num a) => m a -> [m a] -> m a

EP>foldl

Ленивость позволяет не вычислять невостребованное. А левая свертка cons списка востребует все, да еще как!