Есть ли вещи, которые вы прницпиально не понимаете... - Философия программирования

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

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

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

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

_>Это и будет та самая монада...

В данном случае вы сделали что-то Maybe-подобное, но механизм обобщения не показан. На самом деле понятно, как это предполагается использовать обобщенно, но проблема тут будет в том, что это обобщение не типизировано. Родственная проблема — семантическая неопределенность. Про (=<<) можно много чего сказать не зная ничего о конкретной имплементации, про ваш перегруженный сдвиг ничего сказать нельзя.

_>Да легко оно всё делается на практике и здесь. Вот только польза крайне сомнительна...

Ненужность чего угодно вообще легко обосновывается. Следите за руками:
1) На C++ пишется нечто, что автор реализации согласен считать X.
2) Реализация чего угодно на C++ выглядит, как правило, достаточно страшно, чтоб убедить, что с "нечто" лучше не связываться.
3) Раз уж имплементатор считает, что "нечто" — это X, то почему бы ему не поверить? Он же имплементатор — ему виднее.
4) Легко видеть, что польза X — крайне сомнительна.

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

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

Не надо подделывать мои слова. Я говорил по поводу данного примера вот это http://www.rsdn.ru/forum/philosophy/5400854 и всё.

I>Ну и ты задачу не решил, у тебя нет нигде обработки эвентов.

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

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

Что значит "есть"? ) У нас есть список объектов для анализа или что? )

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

Они вообще не для этих целей. Они обычно идут на предыдущем уровне — разбора текста в некие структуры. А анализ этих структур выполняется уже на следующем уровне другими инструментами.

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

K>Но это не верно. В "языках подобных Хаскелю" без монад можно обходится точно так же, как и не в подобных. И нужны они в этих языках для одного и того же. Никакого разделения по признаку "подобие Хаскелю" тут нет.

Интересно будет посмотреть на работу с системными функциями в Хаскеле без монад. ) Т.е. и без IO и т.п... )

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

K>В данном случае вы сделали что-то Maybe-подобное, но механизм обобщения не показан. На самом деле понятно, как это предполагается использовать обобщенно, но проблема тут будет в том, что это обобщение не типизировано. Родственная проблема — семантическая неопределенность. Про (=<<) можно много чего сказать не зная ничего о конкретной имплементации, про ваш перегруженный сдвиг ничего сказать нельзя.

В каком это смысле не типизировано?

K>Ненужность чего угодно вообще легко обосновывается. Следите за руками:

Эм, вообще то в данной темке я не пытался это доказать, а наоборот просил народ имеющий большой опыт в этом привести побольше практических примеров подобной пользы. Т.е. мне самому интересно. Однако что-то никто практических ничего не предложил. Более того, несколько редких существующих известных примеров привёл опять же я. Из всего этого вывод о малой нужности сам собой напрашивается... Однако если кто-то приведёт интересные полезные примеры, то я (да и многие в этой темке) буду только рад. )

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

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

_>Не надо подделывать мои слова. Я говорил по поводу данного примера вот это http://www.rsdn.ru/forum/philosophy/5400854 и всё.

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

I>>Ну и ты задачу не решил, у тебя нет нигде обработки эвентов.

_>Есть там всё, просто для краткости внутри одного цикла. А так, для формализма, можешь раскинуть генерацию чисел и их анализ в две разные функции.

Ого, и давно циклы в с++ стали реактивными ?

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

_>Что значит "есть"? ) У нас есть список объектов для анализа или что? )

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

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

_>Они вообще не для этих целей. Они обычно идут на предыдущем уровне — разбора текста в некие структуры. А анализ этих структур выполняется уже на следующем уровне другими инструментами.

Правильно, об чем и речь. А с монадическими парсерами можно одним и тем же кодом разбирать как текст, так и любые потоковые данные, в т.ч. эвенты.

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

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

У тебя вроде как позиция такая : "Я всё это могу на с++ (тупо императивно, yacc, spirit) наколбасить, следовательно монады не нужны"

Вот, можешь сюда посмотреть

http://www.cs.nott.ac.uk/~gmh/monparsing.pdf

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

К>

К>for x in xs :
К>  for y in foo(x) :
К>    for z in bar(y) :
К>      # вот тебе, бабушка, и флэтмап!
К>

Правильнее будет так:

for x in xs :
 for y in foo(x) :
   for z in bar(y) :
      # вот тебе, заказчик-падла, и n²!
      # А будешь выпендриваться перейду на рекурсию и будет тебе экспонента!
К>

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

I>yacc и spirit про то же. Только тебе сейчас неудобно говорить про парсинг, потому что yacc и spirit в таких задачах сосут не нагибаясь, они вообще для текста заточены.

Это приблизительно тоже самое, что сказать "gcc сосёт у javac на компиляции java кода".

I>Ого, и давно циклы в с++ стали реактивными ?

Причём тут цикл то вообще? ) Он в данном случае относится к генерации набора значений (или эвентов в твоей терминологии), а не к анализу. Я же тебе говорю, можно из того кода выделить отдельно функцию анализа и указать её как обработчик сообщений — тогда никаких циклов не будет.

I>Нет никакого списка, есть, считай, один колбек или эвент, который файрится все время работы приложения.

А как мы тогда можем понять, что достигли самой глубокой вложенности? ) Может в следующем вызове будет ещё глубже? )

I>Правильно, об чем и речь. А с монадическими парсерами можно одним и тем же кодом разбирать как текст, так и любые потоковые данные, в т.ч. эвенты.

Обычный парсер (переводит текст в объектную структуру) можно написать и с монадам и без них. Какой-то там анализатор объектной структуры тоже можно написать и с монадами и без. Не понятно что ты всё же хочешь сказать то. )

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

I>У тебя вроде как позиция такая : "Я всё это могу на с++ (тупо императивно, yacc, spirit) наколбасить, следовательно монады не нужны"

Если при этом императивно получится затратить такие же или меньшие усилия, то действительно монады не нужны. А если с ними можно быстрее добиться результата, то соответственно нужны. И у меня в этой темке как раз и был основной интерес в том, чтобы посмотреть на какие-то реальные примеры, на которых монады дают преимущество. Естественно не в Хаскеле, а в мультипарадигменных языках типа C++.

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

K>>Но это не верно. В "языках подобных Хаскелю" без монад можно обходится точно так же, как и не в подобных. И нужны они в этих языках для одного и того же. Никакого разделения по признаку "подобие Хаскелю" тут нет.

_>Интересно будет посмотреть на работу с системными функциями в Хаскеле без монад. )

Ничего интересного. Просто не будет повторного использования кода, написанного для монад. Все комбинаторы будут специализированными, только для IO. Либо, как вариант, будут использовать какую-нибудь альтернативный иерархии Functor-Applicative-Monad набор классов. Стрелки, к примеру.

_>Т.е. и без IO и т.п... )

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

seq [] = returnIO []
seq (x:xs) = bindIO x (\x' -> bindIO (seq xs) (\xs' -> returnIO (x':xs')))

А есть декартово произведение списков:

cart [] = [[]]
cart (x:xs) = concatMap (\x' -> concatMap (\xs' -> [x':xs']) (cart xs)) x

Никаких монад пока нет.
Мы видим тут дублирование кода. И, переписываем как одну функцию:

instance Monad IO where return = returnIO; (>>=) = bindIO
instance Monad [] where return = (:[]); (>>=) = flip concatMap
-- а вот тут они уже есть

sequence [] = return []
sequence (x:xs) = x >>= \x' -> sequence xs >>= \xs' -> return (x':xs')

Как можно сделать это в "языке подобном хаскелю" (и как это сделано в clean) без IO я показал здесь

Если же под "без монад" вы подразумеваете "без использования того, что можно обобщить с помощью монад", то нет, нельзя. К примеру, обычные функции (a -> b) — это монада Reader.

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

I>>yacc и spirit про то же. Только тебе сейчас неудобно говорить про парсинг, потому что yacc и spirit в таких задачах сосут не нагибаясь, они вообще для текста заточены.

_>Это приблизительно тоже самое, что сказать "gcc сосёт у javac на компиляции java кода".

Удивительно, но это ты предложил yacc и spirit а не я

I>>Ого, и давно циклы в с++ стали реактивными ?

_>Причём тут цикл то вообще? )

И мне хочется узнать, ведь это ты его всунул в свое решение.

> Он в данном случае относится к генерации набора значений (или эвентов в твоей терминологии), а не к анализу. Я же тебе говорю, можно из того кода выделить отдельно функцию анализа и указать её как обработчик сообщений — тогда никаких циклов не будет.

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

I>>Нет никакого списка, есть, считай, один колбек или эвент, который файрится все время работы приложения.

_>А как мы тогда можем понять, что достигли самой глубокой вложенности? ) Может в следующем вызове будет ещё глубже? )

А что тебя смущает ? Текстовый парсер как то справляется с такими задачами. Почему с другими данными должно быть иначе ?

I>>Правильно, об чем и речь. А с монадическими парсерами можно одним и тем же кодом разбирать как текст, так и любые потоковые данные, в т.ч. эвенты.

_>Обычный парсер (переводит текст в объектную структуру) можно написать и с монадам и без них. Какой-то там анализатор объектной структуры тоже можно написать и с монадами и без. Не понятно что ты всё же хочешь сказать то. )

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

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

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

>А если с ними можно быстрее добиться результата, то соответственно нужны. И у меня в этой темке как раз и был основной интерес в том, чтобы посмотреть на какие-то реальные примеры, на которых монады дают преимущество. Естественно не в Хаскеле, а в мультипарадигменных языках типа C++.

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

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

_>В каком это смысле не типизировано?

В прямом. Напишите, к примеру, liftM и подумайте какой у нее тип.

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

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

_>Если при этом императивно получится затратить такие же или меньшие усилия, то действительно монады не нужны. А если с ними можно быстрее добиться результата, то соответственно нужны. И у меня в этой темке как раз и был основной интерес в том, чтобы посмотреть на какие-то реальные примеры, на которых монады дают преимущество. Естественно не в Хаскеле, а в мультипарадигменных языках типа C++.

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

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

K>Как можно сделать это в "языке подобном хаскелю" (и как это сделано в clean) без IO я показал здесь

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

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

I>Удивительно, но это ты предложил yacc и spirit а не я

Что-то ты стал постоянно перевирать мои слова. Для этой задачи я предложил конечный автомат, а не yacc или spirit. Ну это если хочется обобщения, а так лично я бы просто в лоб написал, как и показал выше.

I>В данном случае у тебя вообще все в цыкле, так что пример даже на псевдокод не тянет.

Какой ещё псевдокод? ) Оно компилируется и работает. И выглядит (если раскидать на функции) в виде:

for(;;) Analyze(Generate());

А если хочешь через сообщения, то будет так (с той же функцией):

OnEvent(Event e){Analyze(e.value);}

И в чём проблема?

I>А что тебя смущает ? Текстовый парсер как то справляется с такими задачами. Почему с другими данными должно быть иначе ?

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

I>Я привел пример монадического парсера а ты начал цепляться то к языку, хотя и ежу ясно, что в ветке речь не про C#, то еще к чему то

Где я к языку цеплялся? )

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

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

K>В прямом. Напишите, к примеру, liftM и подумайте какой у нее тип.

Вообще то в том моём примере с boost.optional был как раз буквально этот код. И я что-то не увидел каких-то проблем с ним.

K>По поводу накидывания примеров, у меня позиция такая. Если по известным примерам человек не может оценить потенциал, то добавление примеров тут ничем не поможет, отношение никак не изменится.

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

K>Если под "мультипарадигменным языком" понимается C++ то нет, такие примеры привести нельзя потому, что усилия понадобятся существенно больше тех, которые нужны для написания идиоматического кода.

Ну а если скажем Питон возьмём? )

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

А чего конкретно в C++ не хватает для поддержки подобной функциональщины?

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

Ага, т.е. в итоге похоже что вы согласны с моей оценкой пользы от монад...

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

I>>В данном случае у тебя вообще все в цыкле, так что пример даже на псевдокод не тянет.

_>Какой ещё псевдокод? ) Оно компилируется и работает. И выглядит (если раскидать на функции) в виде:
_>И в чём проблема?

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

I>>А что тебя смущает ? Текстовый парсер как то справляется с такими задачами. Почему с другими данными должно быть иначе ?

_>Текстовый парсер аналогично может решить подобную задачку, только если у него сразу есть все данные целиком.

Это заблуждение. Самый глубокий блок == листовой блок, т.е. тот у которого нет других блоков. Здесь нужен простейший автомат с магазином. Очевидно, все что нужно, это получить закрывающий токен, ни больше, ни меньше. Все что после этого токена никого не интересует.

I>>Я привел пример монадического парсера а ты начал цепляться то к языку, хотя и ежу ясно, что в ветке речь не про C#, то еще к чему то

_>Где я к языку цеплялся? )

Насколько коряво выглядит грамматика в query comprehension С# не имеет никакого отношения к монадам, вообще.

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

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

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

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

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

А вот интересно было бы увидеть эдакий хит-парад монад, используемых в коде на хаскеле, отсортированный по частоте использования. Вроде: "из 12345 модулей на hackage 96% используют монаду List, 90% используют IO для ввода-вывода, 85% используют ST для мутабельных векторов, 61% использует Reader" и т.д.
Не удивлюсь, если 83% использованных монад придутся как раз на те вещи, что в императивных языках встроены.

	От:	Klapaucius
	Дата:	19.12.13 08:48
	Оценка:	1 (1)

	От:	Klapaucius
	Дата:	19.12.13 08:56
	Оценка:

	От:	Klapaucius
	Дата:	19.12.13 10:09
	Оценка:

	От:	alex_public
	Дата:	19.12.13 13:33
	Оценка:

	От:	alex_public
	Дата:	19.12.13 13:37
	Оценка:	+1

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	19.12.13 15:07
Оценка:

От:	VladD2	www.nemerle.org
Дата:	19.12.13 19:58
Оценка:	-2

От:	D. Mon	http://thedeemon.livejournal.com
Дата:	20.12.13 14:56
Оценка:	+1