Почему нет ничего похожего на IMonad < T > в предстоящем .NET 4.0
Я предлагаю просто использовать класс text-center:
<body class="container">
<div class="col-md-12 text-center">
<img data-src="holder.js/100x100" alt="" />
</div>
</body>
2 ответа
Подумайте, какая подпись для Методы IMonad должны быть. В Haskell класс типов Monad определяется как
class Monad m where
(>>=) :: m a -> (a -> m b) -> m b
return :: a -> m a
. Трудно перевести это напрямую в интерфейс C #, потому что вам нужно иметь возможность ссылаться на конкретный реализующий подтип («ma» или ISpecificMonad ) внутри определение общего интерфейса IMonad. Хорошо, вместо того, чтобы пытаться (например) IEnumerable реализовать IMonad напрямую, мы попытаемся выделить реализацию IMonad в отдельный объект, который может быть передается вместе с конкретным экземпляром типа монады, ко всему, что нужно рассматривать как монаду (это «стиль передачи словаря»). Это будет IMonad , а TMonad здесь будет не T в IEnumerable , а самим IEnumerable . Но подождите - это тоже не может работать, потому что подпись Return , например, должна переводить нас из любого типа T в TMonad , для любой TMonad <> . IMonad должен быть определен как что-то вроде
interface IMonad<TMonad<>> {
TMonad<T> Unit<T>(T x);
TMonad<U> SelectMany<T, U>(TMonad<T> x, Func<T, TMonad<U>> f);
}
с использованием гипотетической функции C #, которая позволит нам использовать конструкторы типов (например, TMonad <>) в качестве параметров универсального типа. Но, конечно же, C # не имеет этой возможности (высший полиморфизм) . Вы можете повторно изменить конструкторы типов во время выполнения ( typeof (IEnumerable <>) ), но не можете ссылаться на них в сигнатурах типов, не задавая им параметров. Таким образом, помимо «-100 баллов», реализация этого «должным образом» потребует не просто добавления еще одного обычного определения интерфейса, но и глубоких дополнений к системе типов.
Вот почему способность понимать запросы к вашим собственным типам как бы взломана (они просто «волшебным образом» работают, если есть правильные имена магических методов с правильными сигнатурами) вместо использования механизма интерфейса и т. Д.
потребует не просто добавления еще одного обычного определения интерфейса, но и глубоких дополнений к системе типов.Вот почему способность понимать запросы к вашим собственным типам как бы взломана (они просто «волшебным образом» работают, если есть правильные имена магических методов с правильными сигнатурами) вместо использования механизма интерфейса и т. Д.
потребует не просто добавления еще одного обычного определения интерфейса, но и глубоких дополнений к системе типов.Вот почему способность понимать запросы ваших собственных типов как бы взломана (они просто «волшебным образом» работают, если есть правильные имена магических методов с правильными подписями) вместо использования механизма интерфейса и т. Д.
Монады просто не важны для .NET-программистов. Даже не зная о существовании монад, вы все равно можете создать структуру LINQ. Что еще более важно, это не выглядело бы иначе. Неважно, мыслите ли вы терминами монад (Haskell), переписывания дерева выражений (Lisp), операций на основе наборов (SQL) или использования map / reduce для создания новых типов (Ruby, Python), конечный результат будет
На самом деле, я бы даже сказал, что монады совершенно бесполезны для разработчиков .NET. Каждый раз, когда я вижу библиотеку для .NET, основанную на монадах, она неизменно более подробна и менее понятна, чем простой код C # или VB. Причина проста: такие языки, как C # и VB, построены на гораздо более мощных строительных блоках, чем такие языки, как Haskell.
Haskell, в частности, должен использовать монады для всего, потому что это все, что у них есть. То же самое касается макросов в Лиспе или динамической типизации в JavaScript. Когда у вас есть пони с одним трюком, этот трюк должен быть чертовски хорош.