Здравствуйте, Кодт, Вы писали:
К>Собственно, законы монад — это законы группы с единицей.
К>1) "в группе есть единица"
К>2) "группа замкнута"
К>3) "единица является нейтральным множителем как слева, так и справа"
К>4) ассоциативный закон, кстати!

Извините, что придираюсь, но не группы, а полугруппы с единицей, т.е. моноида.
В группе еще должен быть обратный элемент.

К>Отсюда стремительно вытекает вопрос: а нет ли в этой группе нуля, который является идемпотентным множителем? (А он обычно есть — функция fail)
К>А если у нас есть 0 и 1, то нельзя ли сделать полукольцо со сложением? (А можно — класс MonadPlus)

Может я туплю, но в начале у нас был аддитивный моноид, в котором нейтральный элемент почему-то назывался единицей.
Потом откуда-то появилась непонятно как определеная операция умножения и какой-то ноль в группе (нейтральный элемент то в группе только один, и раз уж его назвали единицей, то либо это не ноль, либо это не группа).
И что может быть ноль в полукольце, который не является идемпотентным множителем?

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

HH>Извините, что придираюсь, но не группы, а полугруппы с единицей, т.е. моноида.
HH>В группе еще должен быть обратный элемент.

Да, конечно, моноид. С группой я поторопился.

К>>Отсюда стремительно вытекает вопрос: а нет ли в этой группе нуля, который является идемпотентным множителем? (А он обычно есть — функция fail)
К>>А если у нас есть 0 и 1, то нельзя ли сделать полукольцо со сложением? (А можно — класс MonadPlus)

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

Почему это аддитивный? Нейтральный элемент "единица" намекает на иное.

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

К>Вот интересно, какой теоретический минимум необходим для объяснения монад на пальцах?

Кстати говоря, тут дискуссия была совсем о другом. Во всяком случае на тот момент, когда я присоединился к ней. Тут стоял вопрос о пользе от применения монад в классических мультипарадигменных языках, а не в языках подобных Хаскелю, где без них просто никак. И для такой дискуссии подобную математику по идее можно даже и не вспоминать, потому как иначе для сравнения придётся в начале перевести на язык математики все остальные фишки классических языков. )))

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

I>Давай внимательно посмотрим, чего твой спирит и yacc умеют

I>Покажи на yacc или спирит аналог вот такого кода

Эм, а можно подробное описание задачи, которую решает этот код? ) А то я не настолько в курсе библиотек .net'a, что бы с ходу понять это.

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

К>>Вот интересно, какой теоретический минимум необходим для объяснения монад на пальцах?

_>Кстати говоря, тут дискуссия была совсем о другом. Во всяком случае на тот момент, когда я присоединился к ней. Тут стоял вопрос о пользе от применения монад в классических мультипарадигменных языках, а не в языках подобных Хаскелю, где без них просто никак. И для такой дискуссии подобную математику по идее можно даже и не вспоминать, потому как иначе для сравнения придётся в начале перевести на язык математики все остальные фишки классических языков. )))

Тут два потока дискуссии: как понять и зачем использовать.

Про "как понять" я считаю, что теоркат избыточен, а командный подход (monkey see — monkey do!) ущербен. Но это мнение сложилось уже после вкуривания в теоркат.

Про "зачем использовать" — монады — это, во многом, идиома.
Прямое заимствование чужой идиомы в язык, где то же самое принято решать иными способами, (пусть и со скрипом, раз мы захотели позаимствовать что-то новое), — труд тяжёлый и странный.
Вот, к примеру, нуль. Его можно тремя способами протащить:
— через тип, поддерживающий нулевое значение (пустой контейнер, нулевой указатель, сигнальное значение вида NaN) и операции, толерантные к таким значениям
— через явное изменение потока управления (возврат и проверка кода ошибки и/или нулевых значений, соответствующее ветвление)
— через бросок и ловлю исключений

Любой из этих способов может оказаться эврикой! в конкретном месте программы.
Например, ветвился-ветвился, а потом сделал на монаде и превратил всё в линейный код.
Или гонял-гонял пустые строки по конвееру, а потом навтыкал throw по всей длине кода, и сразу выросла производительность.
Или кидал исключения на каждый чих, а потом переписал на if'ах, и производительность ещё круче выросла.

То есть, чужая идиома — это источник вдохновения, в первую очередь.

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

I>>Покажи на yacc или спирит аналог вот такого кода
_>Эм, а можно подробное описание задачи, которую решает этот код? ) А то я не настолько в курсе библиотек .net'a, что бы с ходу понять это.

Имитация простейшего отслеживания изменения цен на акции — выдаёт предупреждения при "изменении" тренда.

Разумеется, промышленный код выглядит слегка иначе и пример (вот исходник) на практике полезен не больше, чем ray tracer на linq.

При чём здесь yacc/spirit — я понять решительно отказываюсь. Подозреваю, это просто первый попавшийся страшный код по ключевому слову "Parse".

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

I>>Покажи на yacc или спирит аналог вот такого кода

_>Эм, а можно подробное описание задачи, которую решает этот код? ) А то я не настолько в курсе библиотек .net'a, что бы с ходу понять это.

"The lab defines an observable stock ticker using the Rx operators: Interval, Select, Scan and Publish. Then it calls the Rxx Parse operator and defines an in-line grammar that matches particular reversal trends, projecting them into an observable sequence of alerts."

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

S>Имитация простейшего отслеживания изменения цен на акции — выдаёт предупреждения при "изменении" тренда.

S>Разумеется, промышленный код выглядит слегка иначе и пример (вот исходник) на практике полезен не больше, чем ray tracer на linq.

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

S>При чём здесь yacc/spirit — я понять решительно отказываюсь. Подозреваю, это просто первый попавшийся страшный код по ключевому слову "Parse".

yacc/spirit позволяют сделать парсер. Теоретически, идейка рабочая, получили парсер, прогнали данные и дело в шляпе. Только фокус в том, что yacc/spirit умеют парсить только строчки, что делает эту хрень бесполезной.

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

I>Не всем же на бирже торговать. Рейтрейсеру понятно нужно быстродействие. А вот "измненение тренда" есть не только в HFT
Так и я не про биржу Для простых случаев там сам парсер по-моему нафиг не нужен, достаточно пары Observable.Scan() — для вычисления дельты и для определения смены знака дельты.

Для чего-то сложнее — сходу не скажу, надо будет предметно смотреть, но что-то я очень сомневаюсь в удобстве Rxx для действительно сложных случаев.

S>>При чём здесь yacc/spirit — я понять решительно отказываюсь. Подозреваю, это просто первый попавшийся страшный код по ключевому слову "Parse".
I>yacc/spirit позволяют сделать парсер. Теоретически, идейка рабочая, получили парсер, прогнали данные и дело в шляпе. Только фокус в том, что yacc/spirit умеют парсить только строчки, что делает эту хрень бесполезной.

Не, фокус в том, что парсеры ЯП и parser combinators (а rxx — это именно последнее) — две ортогональные вещи. Парсеры ЯП могут внутри использовать произвольные подходы, а parser combinators могут быть использованы не только для разбора структурированного текста.

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

К>Почему это аддитивный? Нейтральный элемент "единица" намекает на иное.

Тогда не понимаю... Откуда там берется полукольцо?
Чтобы было полукольцо должен быть моноид относительно операции сложения, полугруппа по умножению, дистрибутивность и ноль.
Если взять в качестве полугруппы по умножению например функции fi :a->a с композицией в качестве произведения,
то непонятно, какая будет аддитивная операция в этом полукольце?
А если взять функции f:b->c', g: a->b', то это вообще не группоид, потому что не определена композиция g(f(x)).

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

HH>Тогда не понимаю... Откуда там берется полукольцо?
HH>Чтобы было полукольцо должен быть моноид относительно операции сложения, полугруппа по умножению, дистрибутивность и ноль.
HH>Если взять в качестве полугруппы по умножению например функции fi :a->a с композицией в качестве произведения,
HH>то непонятно, какая будет аддитивная операция в этом полукольце?
HH>А если взять функции f:b->c', g: a->b', то это вообще не группоид, потому что не определена композиция g(f(x)).

Так, секундочку.

Элементы нашего полукольца — функции вида (x -> m y), а не просто (x), (m x) или функции (m x -> m y).

Изначально у нас моноид с умножением (a·b) x = (a x >>= b) и единицей return
return·f = f·return = f
f·(g·h) = (f·g)·h

Добавляем ноль: decline x = mzero или decline x = fail ""
decline·f = f·decline = decline

Добавляем сложение (a¦b) x = (a x `mplus` b x)
decline¦f = f¦decline= f
(f¦g)¦h = f¦(g¦h)

Вот насчёт дистрибутивности что-то сомненья погрызли, но вроде бы должна выполняться
f·(g¦h) ?= (f·g)¦(f·h)

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

К>Про "как понять" я считаю, что теоркат избыточен, а командный подход (monkey see — monkey do!) ущербен. Но это мнение сложилось уже после вкуривания в теоркат.

Мне кажется, что проще всего объяснять на примерах из реально существующего ПО. Их не так много, но они есть. В основном во всяческих конвейерных штуках, типа DirectShow/GStreamer или boost.range/linq. Т.е. когда человек видит очень разные вещи, но за которыми стоит некая общая абстракция, он начинает её видеть сам на интуитивном уровне.

К>Любой из этих способов может оказаться эврикой! в конкретном месте программы.
К>Например, ветвился-ветвился, а потом сделал на монаде и превратил всё в линейный код.
К>Или гонял-гонял пустые строки по конвееру, а потом навтыкал throw по всей длине кода, и сразу выросла производительность.
К>Или кидал исключения на каждый чих, а потом переписал на if'ах, и производительность ещё круче выросла.

К>То есть, чужая идиома — это источник вдохновения, в первую очередь.

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

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

_>Мне кажется, что проще всего объяснять на примерах из реально существующего ПО. Их не так много, но они есть. В основном во всяческих конвейерных штуках, типа DirectShow/GStreamer или boost.range/linq. Т.е. когда человек видит очень разные вещи, но за которыми стоит некая общая абстракция, он начинает её видеть сам на интуитивном уровне.

Ну вообще, разнообразные конвееры — это необязательно монады, а ещё и аппликативные функторы.


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

Каждому языку свои паттерны.
Мне вот set comprehension очень нравится как паттерн, при написании всяких скриптов-числодробилок на питоне и даже на коммандкоме. Но только до тех пор, пока это зрительно можно охватить. То есть, явное декартово произведение — пожалуйста, ленивый конвеер — туда-сюда (на шелле — больше сюда, внутри питона — меньше), а комбинирующие их функции высшего порядка, теряющие в наглядности — это уже пас.
А на С++ так и в конвееры играть не особо хочется.

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

I>"The lab defines an observable stock ticker using the Rx operators: Interval, Select, Scan and Publish. Then it calls the Rxx Parse operator and defines an in-line grammar that matches particular reversal trends, projecting them into an observable sequence of alerts."

Я уже понял всё из ссылки Sinix'а. Мдааа, очень смешной пример товарищи сделали...))) Всё тоже самое, что сделали они, делается обычным линейным кодом (причём вообще без библиотек каких-то) намного короче и проще — реально какой-то антипример получается...

Да, а если говорить не о данном конкретном примере, а вообще об идее, то тут у нас наблюдается банальный конечный автомат. Т.е. берём например boost.statechart и делаем точно такую же обобщённую хрень. И кстати для данного конкретного примера она опять же будет заметно страшнее линейного кода. )))

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

К>Ну вообще, разнообразные конвееры — это необязательно монады, а ещё и аппликативные функторы.

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

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

Так это если говорить о "голом" языке. А если накрутить специальную толстую библиотеку поддержки подобной вещи, то будет удобно в любом языке. Другое вопрос кто потратить своё время на написание такой библиотеки...

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

Спасибо, стало понятнее...

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

К>>Ну вообще, разнообразные конвееры — это необязательно монады, а ещё и аппликативные функторы.
_>Ну да, в подобных библиотека там вообще каша из всего этого. Собственно я предполагаю, что их авторы даже и не задумывались о своих продуктах в подобных терминах.

Это характерный путь развития.
В тех же базах данных — сперва придумали такую штуку, как "база", даже язык Кобол сделали, а потом уже началось — ER, реляционная модель, нормальные формы и прочая, прочая, с математическим аппаратом.
Хотя возможно, что математики изобрели РСУБД в то же самое время, но где-то в горах Пало-Альто или в подземном бункере ЦЕРН — но дальше астроядерных исследований у них не пошло.

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

_>Я уже понял всё из ссылки Sinix'а. Мдааа, очень смешной пример товарищи сделали...))) Всё тоже самое, что сделали они, делается обычным линейным кодом (причём вообще без библиотек каких-то) намного короче и проще — реально какой-то антипример получается...

В этом примере смешная генерация событий. Все остальное вполне нормально.

_>Да, а если говорить не о данном конкретном примере, а вообще об идее, то тут у нас наблюдается банальный конечный автомат. Т.е. берём например boost.statechart и делаем точно такую же обобщённую хрень. И кстати для данного конкретного примера она опять же будет заметно страшнее линейного кода. )))

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

Вобщем не надо слов, покажи код, я хочу увидеть это чудо — линейный код который будет проще и понятнее БНФ грамматики.

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

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

Вообще то как раз сводится, только не любая, а определённый подвид. )

I>Вобщем не надо слов, покажи код, я хочу увидеть это чудо — линейный код который будет проще и понятнее БНФ грамматики.

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

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

int prev=0, count=0;
bool up=true;
for(;;){
    const int val=rand(), change=val-prev;
    string alert;
    if(up&&change>0||!up&&change<0) count++;
    else{
        if(count>=2&&change>21) alert="\tup";
        if(count>=2&&change<-11) alert="\tdown";
        count=1;
        up=change>0;
    }
    cout<<val<<alert<<endl;
    prev=val;
    this_thread::sleep_for(chrono::seconds(1));
}

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

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

_>Вообще то как раз сводится, только не любая, а определённый подвид. )

Ога, которая называется регулярная грамматика.

I>>Вобщем не надо слов, покажи код, я хочу увидеть это чудо — линейный код который будет проще и понятнее БНФ грамматики.

_>Эээ, ты хочешь сказать, что вот тот страшный ужас — это типа БНФ так задаётся? ))) Жуть какая... ) Собственно не удивительно, когда люди пытаются протащить какой-то свой инструмент вообще везде.

В примере нет никакого БНФ, но это можно сделать.

_>Насчёт кода... Я там до конца не разобрался с ним (лень читать их документацию), но насколько я понял по поверхностному взгляду линейным аналогом их кода будет что-то вроде:

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

Вот похожая задача, есть некоторые эвенты, begin, end и тд. Они, понятно, соответсвуют друг другу. Могут быть вложеными. Нужно найти пару самого нижнего уровня, взять из нее какие то значения и бросить еще какой нибудь эвент

Покажи, как твой yacc и spirit смогут с эти справиться.