dans le prochain .NET 4.0'/> dans le prochain .NET 4.0'/> dans le prochain .NET 4.0'/> Pourquoi il n'y a pas quelque chose comme IMonad <T> dans le prochain .NET 4.0 | abulletproofidea.com

Question Pourquoi il n'y a pas quelque chose comme IMonad dans le prochain .NET 4.0


... avec toutes ces nouveautés (et pas si nouvelles si on compte IEnumerable)?

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

Cela permettrait d'écrire des fonctions qui fonctionnent sur n'importe quel type monadique. Ou ce n'est pas si critique?


28
2017-11-10 17:55


origine


Réponses:


Pensez à la signature de IMonad<T>Les méthodes devraient être. Dans Haskell, la classe de caractères Monad est définie comme

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

Il est difficile de traduire cela directement dans une interface C # car vous devez pouvoir référencer le sous-type d'implémentation spécifique ("m a" ou ISpecificMonad<a>) dans la définition de l'interface générale IMonad. OK, au lieu d'essayer d'avoir (par exemple) IEnumerable<T> mettre en place IMonad<T> directement, nous allons essayer d'implémenter l'implémentation IMonad dans un objet séparé qui peut être transmis, avec l'instance de type monade spécifique, à tout ce qui doit être traité comme un monade (c'est le "style de passage de dictionnaire"). Ce sera IMonad<TMonad> et TMonad ici ne sera pas le T in IEnumerable<T>, mais IEnumerable<T> lui-même Mais attendez - cela ne peut pas fonctionner non plus, car la signature de Return<T> par exemple doit nous sortir de tout tapez T à un TMonad<T>, pour tout  TMonad<>. IMonad devrait être défini 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 caractéristique hypothétique C # qui nous permettrait d'utiliser constructeurs de types (comme TMonad <>) en tant que paramètres de type génériques. Mais bien sûr, C # n'a pas cette fonctionnalité (polymorphisme plus élevé). Vous pouvez réifier les constructeurs de type à l'exécution (typeof(IEnumerable<>)) mais ne peuvent pas s'y référer dans les signatures de type sans leur donner de paramètres. Donc, outre le point -100 points, l'implémentation de cette méthode "correctement" nécessiterait non seulement l'ajout d'une autre définition d'interface ordinaire, mais aussi des ajouts profonds au système de types.

C'est pourquoi la possibilité d'avoir des compréhensions de requêtes sur vos propres types est en quelque sorte piratée (elles fonctionnent simplement "comme par magie" si les noms de méthodes magiques correctes avec les bonnes signatures sont présentes) au lieu d'utiliser le mécanisme d'interface, etc.


61
2017-11-15 04:35



Les monades ne sont tout simplement pas importantes pour les programmeurs .NET. Sans même connaître les monades, vous pouvez toujours construire le framework LINQ. Plus important encore, cela ne serait pas différent. Peu importe que vous pensiez en termes de monads (Haskell), de réécriture d’arbres d’expression (Lisp), d’opérations basées sur des ensembles (SQL) ou d’utilisation de map / reduction 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 des monades, elle est invariablement à la fois plus verbeuse et moins compréhensible que le code C # ou VB. La raison est simple, les langages comme C # et VB reposent sur des blocs de construction beaucoup plus puissants que des langages comme Haskell.

Haskell en particulier a besoin d'utiliser des monades pour tout parce que c'est tout ce qu'elles ont. La même chose vaut pour les macros en Lisp ou la saisie dynamique en JavaScript. Quand vous avez un poney à un tour, ce truc doit être très bon.

Sur LINQ, Monads et la cécité du pouvoir


-20
2017-11-15 06:06