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

_>Совершенно верно. Вот я и хочу увидеть конкретный вид этой абстракции, чтобы оценить почему имеются проблемы (если имеются) с её реализацией на языках типа C++.

liftM2 f a b = a >>= \a -> b >>= \b -> return $ f a b

Реализовать ее в принципе можно, я-то говорил, что у нее будет несодержательный с точки зрения практической пользы тип (по крайней мере пока в C++ концептов нет).

_>Имя не принципиально. Даже если переименовать sql, он всё равно останется со своей огромной кучей проблем и ограничений. Для узкого круга задач (типа работы с таблицами и то желательно без join'ов) он ещё более менее подходит, но linq то позиционируется гораздо шире...

Тогда я вообще не понимаю, о чем вы говорите. Где LINQ и где SQL? Какое отношения ограничения sql-я имеют к linq? Какие-там базовые примитивы — если комбинаторы самому писать можно?

_>Не, ну так специализированные библиотеки под особые задачи с концепциями типа монад есть и на C++. Но применяются то они только в этих самых особых случаях. В то время как в том же Хаскеле трудно найти приложение без монад.

Ну так я объяснил почему: неудобств связанных с применением монад и вообще написанием обобщенного кода в хаскеле меньше.

_>Возращает double. Но не в этом суть. Так получается что уже не для всех случаев полезны монады? )))

Суть как раз в этом. Если у вас exp возвращает double, то принимая числа даже меньше 1000 он уже возвращает ерунду. Просто система обработки ерунды встроена в операции с плавучкой. Понятно, что для большинства типов такой автоматической обработки нет и ее нужно организовывать. Кроме того, я сразу написал, что монады нужны для комбинирования функций вида a -> m b, и там же написал что полезно для комбинирования функций других видов. Мне теперь это повторять в каждом предложении?