... со всеми этими новыми (и не столь новыми, если мы подсчитаем IEnumerable) материал, связанный с монадами?
interface IMonad<T>
{
SelectMany/Bind();
Return/Unit();
}
Это позволит писать функции, которые работают на любом монадическом типе. Или это не так важно?
Подумайте о том, какой должна быть подпись для методов IMonad<T>. В Haskell класс Monad определяется как
class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
return :: a -> m a
Трудно перевести это прямо на интерфейс С#, потому что вам нужно иметь возможность ссылаться на конкретный подтип реализации ( "m a" или ISpecificMonad<a>) в определении общего интерфейса IMonad. ОК, вместо того, чтобы пытаться (например) IEnumerable<T> реализовать IMonad<T> напрямую, мы попробуем разложить реализацию IMonad на отдельный объект, который может быть передан вместе с конкретным экземпляром типа монады на все, что необходимо рассматривайте его как монаду (это "стиль передачи словаря" ). Это будет IMonad<TMonad>, а TMonad здесь будет не T в IEnumerable<T>, а IEnumerable<T>. Но подождите - это тоже не сработает, потому что подпись Return<T>, например, должна получить от любого типа T до a TMonad<T> для любого TMonad<>. IMonad следует определить как нечто вроде
interface IMonad<TMonad<>> {
TMonad<T> Unit<T>(T x);
TMonad<U> SelectMany<T, U>(TMonad<T> x, Func<T, TMonad<U>> f);
}
используя гипотетическую функцию С#, которая позволила бы нам использовать конструкторы типов (например, TMonad < > ) в качестве параметров типового типа. Но, конечно же, С# не имеет этой функции (более высокий тип полиморфизма). Вы можете reify конструкторы типов во время выполнения (typeof(IEnumerable<>)), но не можете ссылаться на них в типе сигнатур, не задавая им параметры. Таким образом, помимо -100 пунктов вещь, реализация этого "правильно" потребует не просто добавления другого обычного определения интерфейса, но и глубоких дополнений к системе типов.
Вот почему способность иметь понимание запросов по вашим собственным типам взломана (они просто "магически" работают, если существуют правильные имена меток с правильными сигнатурами) вместо использования механизма интерфейса и т.д.
Монады просто не важны для .NET-программистов. Даже не подозревая, что существуют монады, вы все равно можете создать структуру LINQ. Что еще более важно, это не выглядело бы иначе. Не имеет значения, думаете ли вы в терминах монадов (Haskell), переписывания дерева выражений (Lisp), операций на основе набора (SQL) или использования карты/сокращения для создания новых типов (Ruby, Python), конца результат будет таким же.
Фактически, я бы сказал, что монады совершенно бесполезны для разработчиков .NET. Каждый раз, когда я вижу библиотеку для .NET на основе монад, она всегда является более подробной и менее понятной, чем прямой код С# или VB. Причина проста, такие языки, как С# и VB, построены на гораздо более мощных строительных блоках, чем такие языки, как Haskell.
Haskell, в частности, должен использовать монады для всего, потому что это все, что у них есть. То же самое касается макросов в Lisp или динамического набора текста в JavaScript. Когда у вас есть один трюк, этот трюк должен быть чертовски хорош.