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

K>>Это совершенно отдельный разговор не про полезность монад, а про полезность контроля эффектов.

_>Совершенно верно. И как раз про это я спрашиваю уже очень давно и так ни разу и не получил ответа. Естественно про какие-то случаи из реальной практики, а не обобщённую теорию..

Нужен практический пример полезности контроля эффектов? Есть процесс, имеющий состояние и управляемый потоком событий. Результатом обработки события может быть либо ошибка (и старое состояние), либо новое измененное состояние и ряд эффектов (конкретно — изменение внешнего мира).

Без контроля эффектов псевдокод будет выглядеть так:

processEvent(Event, State)
{
  if (validateEvent(Event, State))
    return processValidEvent(Event, State);
  else
    return State;
}

Сложность функции validateEvent в реальности может оказаться слишком велика. Мы хотим писать так:

processEvent(Event, State)
{
  try
  {
    return processEventOrFail(Event, State);
  }
  catch
  {
    return State;
  }
}

State иммутабельно. Способ возврата ошибки (в данном случае — исключение) к примеру отношения не имеет.

Если бы processEventOrFail не имела побочных эффектов (в данном случае кроме возврата исключения), этот код был бы удовлетворителен. Если язык не позволяет тем или иным способом контролировать эффекты, мы будем выкручиваться как-то так (код по прежнему очень псевдо):

...
(NewState, Effects) = processEventOrFail(Event, State);
applyEffects(Effects);
return NewState;
...

что уже сложнее, при этом способа гарантировать отсутствие эффектов в processEventOrFail у нас по прежнему нет.

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

I>>Ты открой и посмотри, феникс этот и есть то, как выглядит функциональщина в C++

EP>Boost.Phoenix даёт:
EP>

лямбды — с приходом лямбд в C++11 менее актуально
EP>

полиморфные лямбды — с приходом полиморфных лямбд в C++14 менее актуально
EP>

короткую нотацию для лямбд, причём даже короче чем в C#: (_1 + _2)(11, 22) == 33

EP>А DO-сахар для монад реализуются ровно в сорок строк без всякого Phoenix'а:

Я не сильно знаю Хаскель что бы сравнить, но помня твои примеры про await, где то ты сильно недоговариваешь

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

I>Я не сильно знаю Хаскель что бы сравнить, но помня твои примеры про await, где то ты сильно недоговариваешь

А с await'ом что не так? AFAIK, даже в MSVC 2013 C++ __await реализован таким же способом, через stackful coroutine.

DO-сахар в Haskell'е ничего особенного не делает, он просто разворачивает вложенные продолжения:

unit(1) >>= [=](auto x) { return
    unit(2) >>= [=](auto y) { return
        unit(3) >>= [=](auto z) { return
            unit(x + y + z)
        };
    };
};

в линейную структуру

do
    x <- return 1
    y <- return 2
    z <- return 3
    return x + y + z

Поэтому достаточно легко реализуется на variadic макросах.

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

_>Ага, идея претензии понятна, но на самом деле она не имеет вообще никакого смысла в C++ по очень простой причине. Смысл был бы, если бы данный шаблон можно было скомпилировать (в библиотеку какую-то или даже просто объектный файл) сам по себе. Но это в C++ невозможно. Неинстанцированные шаблоны просто не существуют для компилятора и имеют смысл в коде не более чем комментарии.

Непонятно, как причина претензии лишает претензию смысла. Именно потому, что так происходит претензия и имеет смысл.

_>Ну а при инстанцированние очевидно уже возникает полная типизация во весь рост. Т.е. тут компилятор чётко выполняет свою работу в области типизации и не позволит существовать некорректному коду.

Чем раньше ошибка выявляется — тем лучше. Поэтому претензия вполне обоснована.

_>Вообще то я это давно понял, согласился и т.п. И продолжаю разговор уже именно про эти самые эффекты.

И тем не менее парой строчек ниже:

_>Во-первых они всё же используются чтобы частично скрыть некие "ужасы" реализации IO/ST Хаскеля.

опять двадцать пять.

_>Совершенно верно. И как раз про это я спрашиваю уже очень давно и так ни разу и не получил ответа. Естественно про какие-то случаи из реальной практики, а не обобщённую теорию..

Я же говорю, как только разберем "ужасы" — так сразу.

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

_>Сейчас прямо за секунду (а иначе лень) легко повторить это не могу, т.к. уже давно стёр и wxHaskell и сам Haskell у себя с компьютера, как не нужное. Но если кто-то хочет проверить мои слова, то алгоритм очень простой. Причём я указал на эти самые примеры в первом же своём сообщение на эту тему.

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

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

К>Ну понятно, что мета-типизация у плюсов утиная. Но компилятор всё равно проверит наличие функций из словаря Monad, — если они были востребованы, конечно.

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

К>А при желании можно явно прикрутить контракт — "принадлежность M<*> к модели Monad", самым простым способом — через enable_if и т.п.
К>Просто для хаскелла это является не желанием, а требованием, которое смягчено автоматическим выводом сигнатуры.

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

К>Сравни
К>

К>liftM2 f ma mb = do { a<-ma; b<-mb; return f a b }
К>

К>здесь нигде не сказано Monad m =>, но do-нотация или водопровод на это намекают. Так же, как на это будет намекать водопровод в определении плюсовой функции liftM2.

Ну, это не серьезно. Типы все равно будут проверены, даже если они не проаннотированы. Обобщенная сигнатура ведь может быть выведена не для всякого кода, а значит широкий класс ошибок будет выявляться без всякой специализации. Да и есть возможность узнать тип функции.
"Водопровод" же в коде на C++ ни на какую семантику не намекает. Его можно практически как угодно перегрузить. Понятно, что законы для классов в хаскеле — это только традиция, никак это не проверяется, но традиция все-таки есть, да и типы перегружаемого оператора фиксированы. В C++ из-за невозможности объявлять свои операторы (и следующего из этого дефицита имен для операторов) у такой традиции просто не было шанса сформироваться.
И раз уж речь о полезности монад вообще — в языке где законы для монад будут проходить машинную проверку — монады будут еще полезнее.

К>Мне здесь внезапно увиделась фиксация: раз в хаскелле эндофункторы — это из типа в тип и из функции в функцию, то давайте и во всех остальных языках будем проецировать типы и функции. При том, что механизмы операций над типами и функциями или убоги, или просто другие.
К>Не могу словами выразить, но чувствую, что где-то кидают.

Да, в языках, которые другие — от монад можно получить не всю перечисленную мной пользу. Вот в C# никакие эндофункторы из-за ограничений системы типов невозможны, так что "повторное использование" из списка можно вычеркивать, но все что сказано про "знаем 80% в каждом из всех возможных встроенных языков, изучив один любой" и "монадические законы подсказывают дизайн-решения для разработчика встроенного языка", и про синтаксическую маскировку "обвязки" — это все остается. И какую-то пользу из монад можно извлекать пока в языке есть хоть что-то отдаленно напоминающее функции вида "из легкого в что-то не очень простое".

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

K>И раз уж речь о полезности монад вообще — в языке где законы для монад будут проходить машинную проверку — монады будут еще полезнее.

В общем случае не получится, как минимум из-за проблемы остановки.

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

К>>Ну понятно, что мета-типизация у плюсов утиная. Но компилятор всё равно проверит наличие функций из словаря Monad, — если они были востребованы, конечно.
K>Ну это не совсем так и даже совсем не так. Функция может быть использована в другой обобщенной функции. А проверка будет только после конкретизации.

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

Очень грубо говоря, вместо M<T> будем оперировать HaskType<M<T>>, то есть, введём единую монаду (монадный трансформер) HaskType, и вообще всё на свете лифтанём в него.
Будет нам

function<HaskType<M<R>>(HaskType<M<X>>,HaskType<M<Y>>)> liftM2 ( function<HaskType<R>(HaskType<X>, HaskType<Y>)> )

K>И раз уж речь о полезности монад вообще — в языке где законы для монад будут проходить машинную проверку — монады будут еще полезнее.

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



К>>Мне здесь внезапно увиделась фиксация: раз в хаскелле эндофункторы — это из типа в тип и из функции в функцию, то давайте и во всех остальных языках будем проецировать типы и функции. При том, что механизмы операций над типами и функциями или убоги, или просто другие.
К>>Не могу словами выразить, но чувствую, что где-то кидают.

K>Да, в языках, которые другие — от монад можно получить не всю перечисленную мной пользу. Вот в C# никакие эндофункторы из-за ограничений системы типов невозможны, так что "повторное использование" из списка можно вычеркивать, но все что сказано про "знаем 80% в каждом из всех возможных встроенных языков, изучив один любой" и "монадические законы подсказывают дизайн-решения для разработчика встроенного языка", и про синтаксическую маскировку "обвязки" — это все остается. И какую-то пользу из монад можно извлекать пока в языке есть хоть что-то отдаленно напоминающее функции вида "из легкого в что-то не очень простое".

В таких языках функторы ад-хок и идиоматические, например, "а давайте сделаем на итераторах". И дальше — руками колбасить, подставляя типы какие следует куда следует (т.е. не компилятор, а сам программист выступит функтором). Но — в канве исходной идеи. Польза от компилятора в том, что он гораздо реже ошибается.

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

К>Это я и назвал "если будут востребованы".

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

К>А насколько это технически возможно

Технически это вполне возможно.

К>и насколько оправданно?

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

К>Опять же, кроме монад, у нас много где фигурируют законы.

Ну понятно, что речь идет о проверке законов для инстансов тайпклассов (или каких-то их аналогов), а не только для монад.

К>Насколько мы здесь рискуем попасть на проблему останова?

Во-первых, проблема останова касается языков с общей рекурсией. Если ее (и возможностей ее организовать вроде типов, которые строго позитивными не являются) в языке нет, то и беспокоиться не о чем. Если, к примеру, есть только структурная рекурсия и корекурсия, то завершимость можно проверить. (Для структурной рекурсии по индукции доказать, для корекурсии — еще проще, там каждый шаг завершается и "возвращает управление").
Во-вторых, в языках где ограничений на рекурсию нет, проблема останова на практике означает, что проверка завершения консервативная, будет код, для которого завершимость можно проверить, а будет такой, который завершается, но termination checker это проверить не в состоянии и такой код будет ложно считаться "незавершающимся". Эта ситуация ничем не отличается от проверки типов, которая также консервативна и отбраковывает вполне работающий код. На практике же, это не мешает с пользой проверять типы.
Проверка завершимости есть и для обычных языков, не только для пруф ассистантов вроде Агды. Вот, например, такой инструмент для Хаскеля.
В-третих, даже проверка законов без проверки завершения может быть полезна. Понятно, что какой-нибудь undefined в такой системе доказывает все что угодно, но программисты часто (ну ладно, иногда) будут стараться что-то доказать, и не смотря на дырявость системы и ложные сообщения чекера о том, что все проверено, какая-то часть ошибок будет обнаружена.
Даже третий, самый слабый вариант лучше "договорных" законов.

К>В таких языках функторы ад-хок и идиоматические, например, "а давайте сделаем на итераторах". И дальше — руками колбасить, подставляя типы какие следует куда следует (т.е. не компилятор, а сам программист выступит функтором). Но — в канве исходной идеи. Польза от компилятора в том, что он гораздо реже ошибается.

Ну да, все правильно.

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

EP>В общем случае не получится, как минимум из-за проблемы остановки.

С.м. мой ответ

Автор: Klapaucius
Дата: 09.01.14

.

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

EP>Late binding позволяет выводить типы там, где Haskell нужно заводить "с толкача"

Автор: Evgeny.Panasyuk
Дата: 15.08.13

.

Ну, понятно. Это же пример, который типизация необоснованно запрещает, а ее отсутствие — разрешает (как и множество других веселых вещей).
Вполне ожидаемо, что "разрешительная" (т.е. фактически отсутствующая) типизация плюсового обобщенного кода ее разрешит.

EP>К параметрам-типам шаблонов можно указывать как синтаксические требования (C++98 SFINAE, C++11 decltype SFINAE, C++14 Concepts), так и семантические — через traits (пользователь подписывается под тем, что его тип удовлетворяет необходимым аксиомам).

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

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

I>С++ не умеет те операторы, которые нужны для БНФ или РБНФ.
I>то есть придется эмулировать все подряд, например следование придется пилить явно, скобки и прочую вешь так же придется эмулировать, т.е. пилить явно.

Ужас то какой. )))

I>Вот смотри, твой спирит, я даже не знаю, не то смеяться, не то плакать.
I>...

Кстати, вот на таких примерах (когда строим полноценную AST) не видны некоторые удобнейшие (на мой вкус) возможности использования Спирита. Например такая int_[([](const int& n){cout<<n<<endl;})] % ',' штука не просто задаёт список интов разделённых запятой, но и сразу же пишется реакция на распознанное значение. Причём таких реакций может быть сколько угодно — хоть на каждый элемент грамматики или их группу. В итоге получается писать крайне краткие и быстрые парсеры для простых вещей.

I>вот BNF:
I>...
А это на каком языке программирования написано?

I>А вот фокус — та же грамматика на комбинаторах
I>...
I>тут не всё, справа надо добавить .map(AST.ляляля), т.е. трансляцию в АСТ, количество кода не сильно изменится

Генерация AST — это ладно, это действительно не надо показывать (т.к. тогда ещё само AST определять надо). А вот где сам парсинг то? ) В случае Спирита понятно, что парсинг всегда осуществляется ровно одним вызовом глобальной функции, которой передаётся строка и грамматика. А тут у нас что делать с этим списком переменных?

Т.е. вот предположим нам надо не AST сгенерировать, а напечатать разобранное выражение в консоль (но с другим форматирование естественно). Как будет тогда выглядеть полный код на базе твоего варианта? Кстати, в случае Спирита это одна строчка будет...

Ну а про разницу в скорости при определение грамматики во время копиляции или во время исполнения я даже особо упоминать не буду — про это по идее и так все помнят.

I>"не для вывода" мгновенная скорость так же бсолютно никому не интересна. Представь — надо управлять заслонкой печи в зависимости от скорости роста температуры. Как это в твоем случае сделать — не ясно, ибо мгновенная скорость может быть отрицительная, а температура в котле будет расти

Хы, в таких задачах (где есть всё работает по определённым законам и можно точно предсказывать "будущее") вообще всё по другому делают. Про фильтр Калмана слышал? ) Кстати, как ты думаешь, там будет фигурировать нормальная скорость или средняя? )))

Хотя, как я уже говорил, на самом деле все эти значения в каком-то смысле всё равно являются средними, но только в следствие несовершенства цифровой техники.

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

I>

I>js он паттерном идёт, как раз для того, что бы отделить от остального мусора

I>Очевидно, что в логе не только JS, там результаты функций, снимки состояния и тд и тд.

Так я не понял, после "pir:" может идти не js код или нет? Если может, то весьма любопытно взглянуть на твоё решение задачки "выловить среди произвольного текста кусок js кода"...

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

I>Пудозреваю, тебе самое время смотреть boost.phoenix

После выхода C++11 не вижу в нём особого смысла. Ну точнее формального говоря он конечно же есть — ленивые выражения на нём можно удобно конструировать. Но я подобным не увлекаюсь.

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

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

Конечно, но это если писать руками каждый раз. А если ты это всё скроешь в библиотечке за удобным интерфейсом? )

I>Эта хрень такая же страшная, как и boost.phoenix.

Внутри — возможно. А снаружи вроде как весьма удобно всё.

I>Все такие возможности очень актуальны, ибо в С++ возможностей для интеграции около нуля. Именно по этой причине для интеграции берут более другой язык — JS, Python, Lua и тд вплоть до С# или Джавы, не гнушаясь даже vbs.

Это ты вообще о чём? Что за интеграция? )

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

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

Хы, ну так "красоту" синтаксиса плюсов я защищать не собираюсь. ))) И особенно шаблоны с лямбдами. ))) Но смысловые части в C++ коде и в Хаскель коде тут абсолютно идентичные.

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

EP>А DO-сахар для монад реализуются ровно в сорок строк без всякого Phoenix'а:
EP>...

Красиво. Естественно это ни к чему в языках типа C++, где просто функция является аналогом do-сахара. Но хорошо демонстрирует преимущества наличия в языке средств метапрограммирования — если надо, то можно сделать почти всё что угодно.

P.S. Там в операторе >>= для optional мелкая недоработка есть, но она к сути дела никакого отношения не имеет. )

alex_public wrote:

> Кстати, вот на таких примерах (когда строим полноценную AST) не видны
> некоторые удобнейшие (на мой вкус) возможности использования Спирита.
> Например такая int_[([](const int& n){cout<<n<<endl;})] % ',' штука
> не просто задаёт список интов разделённых запятой, но и сразу же
> пишется реакция на распознанное значение.

С этим был подводный камень, что если составное rule не сматчилось до
конца, то action у составляющих всёравно срабатывает. Сейчас уже не в
курсе как с этим.

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

_>Красиво. Естественно это ни к чему в языках типа C++, где просто функция является аналогом do-сахара.

Да — самые распространённые монады (или альтернативы) уже есть в языке/библиотеках. Реального практического применения я пока ещё не придумал.

_>P.S. Там в операторе >>= для optional мелкая недоработка есть, но она к сути дела никакого отношения не имеет. )

Вижу, там нужен другой тип для Nothing.

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

_>Если бы processEventOrFail не имела побочных эффектов (в данном случае кроме возврата исключения), этот код был бы удовлетворителен. Если язык не позволяет тем или иным способом контролировать эффекты, мы будем выкручиваться как-то так (код по прежнему очень псевдо):

_>

_>...
_>(NewState, Effects) = processEventOrFail(Event, State);
_>applyEffects(Effects);
_>return NewState;
_>...
_>

_>что уже сложнее, при этом способа гарантировать отсутствие эффектов в processEventOrFail у нас по прежнему нет.

Это всё понятно. Но я вообще то как раз и спрашивал, а какой уже у нас будет тут код на языке позволяющем контроль эффектов? В чём будет его преимущество над кодом выше и т.п...