Je suis largement familiers avec les concepts de monades et des flèches utilisées dans la programmation fonctionnelle. Je comprends aussi qu'ils peuvent être utilisés pour résoudre les mêmes types de problèmes.
Cependant - et je suis toujours un peu confus sur la façon de choisir lequel utiliser dans une situation donnée.
Quand dois-je utiliser les monades et quand dois-je utiliser les flèches?
Il y a deux excellents documents par Lindley, Wadler & Yallop (discuté au LTU ici).
La chose la plus importante à comprendre est qu'il y a plus de choses qui sont des flèches qu'il y a des choses qui sont des monades. A l'inverse, les monades sont strictement plus puissant que les flèches (le deuxième de papier au-dessus spécifie précisément dans quel mode).
En particulier, les monades sont des flèches équipé d'une application de fonction de type (a ~> b, a) ~> boù (~>) est le constructeur pour une flèche. Lindley et coll. point que cela détruit le méticuleux distinction flèches à maintenir entre les termes et les commandes (ou, si vous préférez, des objets et des morphisms).
Les foncteurs applicatifs ont une grande variété d'applications, en particulier pour des choses qui sont mieux pensé que les opérations sur les flux. On peut en effet penser de flèches comme découlant de la généralisation de la notion d'un transformateur de flux (c'est à dire l'introduction d'un nouveau langage pour morphisms sur des objets construits par un foncteur applicatif).
Dans mon expérience, parce que les monades de brouiller la distinction entre les objets et morphisms (c'est à dire, si je suis en utilisant correctement les mots, donner lieu à un cartésien catégorie), puis d'un terme dans une monade est généralement beaucoup plus nécessairement opaque qu'un terme dans une flèche ou un foncteur applicatif (à noter toutefois que les deux vous permettent d'injecter des fonctions arbitraires par l' arr et pure méthodes respectivement).
Donc, si quelque chose est pas donné les caractéristiques d'une monade (même si, conceptuellement, il forme un), puis il est potentiellement ouvert à une plus grande inspection et d'optimisation. Il est aussi potentiellement plus facile à sérialiser. D'où l'utilisation des applicatifs et des flèches dans les analyseurs et de modélisation de circuits.
Le ci-dessus a tenté d'être générale et descriptive. Ci-dessous sont quelques-uns de mes opinions les règles du pouce.
Si vous avez besoin de modéliser quelque chose qui ressemble à l'état, commencer avec une monade. Si vous avez besoin de modéliser quelque chose qui ressemble global de contrôle de flux (c'est à dire les exceptions, les continuations), démarrer avec une monade. Si une exigence découle que les conflits avec la puissance et la portée de monades (c'est à dire pour qui rejoignent (join :: m (m a) -> m a) est trop puissant), puis envisager de s'éloigner de la puissance de la chose que vous utilisez.
Si vous avez besoin de modèle de flux, et de transformations sur les cours d'eau, et en particulier les flux pour lesquels certaines caractéristiques (en particulier une vue imprenable sur le passé et l'avenir) doit être opaque, puis démarrer avec un foncteur applicatif. Si vous avez besoin de plus de raisonnement sur les propriétés des transformations sur les cours d'eau, alors pensez à les atteindre d'une flèche.
Ou, très grossièrement mis, applicatifs sont pour les actions de circuits, des flèches pour les structures de circuits, et les monades sont pour usage général de calcul des effets.
Il y a bien sûr beaucoup plus à l'histoire. Pour les applicatifs, voir Conal Elliot est le travail sur le PRF en particulier. Pour les flèches, voir la HXT XML parser, la Yampa PRF projet, le Haskell sur un Cheval framework web, Hudak et Liu classique "Branchement d'un Espace de Fuite avec une Flèche" du papier, entre autres choses. Pour monades, voir partout. Et bien sûr prendre note que juste parce que quelque chose est une monade, qui ne veut pas dire que applicative de notation pourrait pas être plus clair et plus expressif.
La réponse courte est que les Flèches sont plus générales que les Monades et sont également de plus en plus lourde à utiliser. Ainsi, vous devez utiliser les Monades chaque fois que vous pouvez, en laissant à l'utilisation des Flèches pour les cas où les Monades ne sont pas applicables.
La "scenic route" suit la réponse.
John Hughes, la personne qui a introduit les Flèches, a publié deux grands papiers que je vous recommande: "la Généralisation des monades de flèches" et "Programmation avec des Flèches". Ces deux articles sont faciles à lire et à fournir la réponse à votre question. Même si certaines personnes ne comprennent pas tous les détails ou le code de ces deux articles, ils vont certainement trouver beaucoup d'informations et d'explications très utiles sur les Monades et des Flèches.
Je vais maintenant mettre en évidence les principaux points de ces articles qui se rapportent à votre question
Lorsque les Monades ont été introduit, les gens pensaient qu'ils étaient tout-puissants. En effet, les Monades pack beaucoup de puissance. Mais à un certain point, il a été constaté qu'il existe des cas où les Monades ne peut pas être appliquée. Ces cas ont à faire avec plusieurs entrées, surtout quand certains intrants sont statiques et certaines entrées sont dynamiques. Ainsi, John Hughes intensifié et a introduit des Flèches.
Les flèches sont plus générales que les Monades. Les flèches sont un sur-ensemble des Monades. Ils peuvent faire tout ce que les Monades et bien plus encore. Mais ils sont aussi plus difficiles à utiliser. John Hughes recommande que vous devriez utiliser Monades chaque fois que vous le pouvez et que vous devez utiliser les Flèches lorsque vous ne pouvez pas utiliser les Monades.
Je suis d'accord avec John Hughes. Je suis également rappelé d'Einstein de la citation "Tout devrait être rendu aussi simple que possible, mais pas plus".
Bien sûr, tout dépend de la situation particulière à portée de main. Laissez-moi vous expliquer. Supposons que vous êtes l'apprentissage Haskell. Ensuite, il serait une grande tâche pour faire de chaque programme à l'aide d'une approche monadique et de la refaire à l'aide d'une flèche. Quand vous apprenez, vous devriez vous efforcer d'explorer toutes les possibilités et mettre en œuvre toutes sortes d'approches. De cette façon, vous obtenez beaucoup de perspicacité et vous êtes en mesure de comparer les différentes solutions de première main.
Maintenant, supposons que vous souhaitez fournir une bibliothèque à la communauté. Eh bien, vous le devons aux personnes qui vont lire votre code que vous devez utiliser l'approche qui est la plus facile à comprendre et à toujours fait le travail. Vous avez également le devons aux personnes qui vont utiliser votre code que votre solution manque de complexité inutile. De cette façon, votre solution est plus facilement maintenable et moins sujettes à des erreurs et des bugs.
Mais que faire si vous êtes dans un cas limite? Supposons que vous n'êtes pas sûr de savoir si ou non vous aurez besoin de la puissance supplémentaire de Flèches. Alors, que devez-vous faire? Devriez-vous commencer avec une approche monadique et plus tard, passer à une flèche à base de si le besoin s'en fait sentir? Ou devriez-vous commencer avec des Flèches à partir de l'obtenir-aller, d'éviter un coûteux commutateur à mi-chemin à travers le projet?
Encore une fois, ma réponse est d'essayer la première méthode: utilisez des Monades si vous le pouvez. Si par la suite vous découvrez que vous ne pouvez pas utiliser les Monades, vous aurez à subir un coûteux commutateur, où vous devrez redémarrer et refaire le projet afin d'utiliser les Flèches. Cette approche sera certainement besoin de plus de temps et d'autres ressources à partir de votre part. Mais vous savez que vous avez fait la bonne chose, c'est pour essayer de fournir le plus simple, le plus clair, moins complexe solution possible.
En évitant la complexité inutile, est la chose la plus importante. Croyez le ou non, c'est la raison concepts (tels que la composition de fonctions, les Monades et des Flèches) de la Catégorie de la Théorie ont été introduites à l'Informatique. Ironique?
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
