Pourquoi il n'y a pas quelque chose comme IMonad dans .NET 4.0 à venir

Question

... avec tous ces nouveaux (et pas si nouveau si l'on compte IEnumerable) choses liées monade?

interface IMonad<T>
{
 SelectMany/Bind();
 Return/Unit();
}

Cela permettrait d'écrire des fonctions qui fonctionnent sur tout type monadique. Ou il est pas si critique?

Answer 1

Pensez à ce que la signature pour les méthodes de IMonad<T> devrait être. Dans Haskell la Monade est définie classe de types comme

class Monad m where
  (>>=) :: m a -> (a -> m b) -> m b
  return :: a -> m a

Il est difficile de traduire directement à une interface C # parce que vous devez être en mesure de faire référence au sous-type spécifique mettant en œuvre ( « m a » ou ISpecificMonad<a>) dans la définition de l'interface IMonad générale. OK, au lieu d'essayer d'avoir (par exemple) IEnumerable<T> mettre en œuvre IMonad<T> directement, nous allons essayer de factoriser la mise en œuvre de IMonad sur dans un objet séparé qui peut être transmis, ainsi que la monade instance de type spécifique, à tout ce qui doit le traiter comme monade (ce qui est « style dictionnaire passage »). Ce sera IMonad<TMonad> et TMonad ici ne sera pas le T IEnumerable<T>, mais se IEnumerable<T>. Mais attendez - cela ne peut pas travailler non plus, parce que la signature de Return<T> par exemple doit nous faire de any type T à un TMonad<T>, pour any TMonad<>. IMonad devrait être définie comme quelque chose comme

interface IMonad<TMonad<>> {

    TMonad<T> Unit<T>(T x);
    TMonad<U> SelectMany<T, U>(TMonad<T> x, Func<T, TMonad<U>> f);
}

en utilisant une fonction hypothétique C # qui nous permettrait d'utiliser constructeurs de type (comme TMonad <>) en tant que paramètres de type générique. Mais bien sûr, C # ne possède pas cette fonctionnalité (polymorphisme supérieur kinded) . Vous pouvez réifier les constructeurs de type à l'exécution (typeof(IEnumerable<>)) mais ne peut pas se référer à eux dans les signatures de type sans leur donner les paramètres. Ainsi, en plus de la chose -100 points, la mise en œuvre de cette « correctement », il faudrait non seulement ajouter une autre définition de l'interface ordinaire, mais des ajouts profonds au système de type.

Voilà pourquoi la possibilité d'avoir des compréhensions de requête sur vos propres types est une sorte de piraté (ils tout simplement « magique » si les noms des méthodes magiques droit avec les signatures droite sont là) au lieu d'utiliser le mécanisme d'interface etc.

Answer 2

Monades sont tout simplement pas important pour les programmeurs .NET. Sans même savoir monades vous existez pouvez toujours construire le cadre LINQ. Plus important encore, il ne serait pas l'air différent. Peu importe si vous pensez en termes de monades (Haskell), l'expression ré-écriture arbre (Lisp), les opérations à base de set (SQL), ou en utilisant map / reduce pour créer de nouveaux types (Ruby, Python), le résultat final est va être le même.

En fait, j'irais jusqu'à dire que les monades sont carrément inutiles pour les développeurs .NET. Chaque fois que je vois une bibliothèque pour .NET basée sur monades, il est toujours à la fois plus bavard et moins compréhensible que # droite C ou un code VB. La raison est simple, des langages comme C # et VB sont construits sur beaucoup, blocs de construction beaucoup plus puissants que des langues comme Haskell.

Haskell en particulier a besoin d'utiliser pour tout monades parce que c'est tout ce qu'ils ont. La même chose vaut pour les macros dans Lisp ou en tapant dynamique JavaScript. Lorsque vous avez un poney un truc, ce truc doit être sacrément bon.

sur LINQ , monades, et l'aveuglement du pouvoir