23 votes

Quelle est la différence conceptuelle entre les Machines et les Conduits (ou d'autres bibliothèques similaires)?

Je voudrais apprendre la notion, de sorte que je serais en mesure de comprendre et d'utiliser les bibliothèques comme des machines.

J'ai essayé de suivre Rúnar Bjarnason parler sur les machines, mais il y a trop peu d'informations, fondamentalement juste un tas de types de données. Je ne peux même pas comprendre ce qu' k est en

newtype Machine k o = Step k o (Machine k o)
data Step k o r = Stop
                | Yield o r
                | forall t . Await (t -> r) (k t) r

ou ce qu' t est et pourquoi il est quantifiée. Ou, quelle est la différence conceptuelle entre le conduit-comme les bibliothèques et les machines?

35voto

Edward Kmett Points 18369

conduit et pipes sont à la fois beaucoup plus mature que machines, mais -- que dit - machines est d'essayer de prendre un chemin différent que d' conduit et pipes.

Avec machines, je suis en train de relativement simple API en termes de type d'arguments. Les deux conduit et pipes ont choisi d'unifier l'ensemble de leurs concepts à l'aide de 5-6 différents type de variable d'arguments.

Machines prend une approche différente du paramétrage d'une machine (ou Plan) sur sa "langue d'entrée", qui met toute la responsabilité sur un seul argument supplémentaire (ou deux dans le cas d'un Plan). Aussi par le choix de paramétrer la langue d'entrée de cette manière, il ouvre des possibilités de l'utilisation de machines qui peuvent accepter d'entrée (non-)de façon déterministe à partir de plusieurs sources d'entrée. Le résultat est fondamentalement juste un gratuit monade avec un supplément 'émettre des instructions de!

En échange d'un peu plus de rigueur de la politique sur la façon de mettre en place et à utiliser des machines, il peut éventuellement offrir une meilleure sécurité à propos asymptotique du code résultant.

Cela dit, pipes et conduit ont eu beaucoup de monde réel de l'utilisation et de l' machines est plus ou moins d'une aire de jeux pour moi, Rúnar Bjarnason et Paul Chiusano.

Il est actuellement adapté pour travail sur l'entrée que vous avez l'intention de consommer entièrement, mais moins pour travailler avec des complexes de ressources ou pour l'analyse de ce que vous obtenez avec ces deux autres Api.

Maintenant, sur ce quantificateur!

t il y a réellement quantifiée existentiellement. En faisant ainsi, nous pouvons faire l' Monad pour les machines se soucient pas de la functoriality de l' k paramètre. Ceci est important parce que de la façon dont Source est mis en œuvre. Si je n'ai pas besoin d' Source de travail, alors nous pourrions utiliser la plus simple

data Step k o r = Stop
                | Yield o r
                | Await (k r) r

Ce serait malheureux d'effets secondaires que lorsque vous êtes allé à composer une Machine avec un Source, que le compilateur ne sais pas ce qui Functor exemple de choisir et que vous souhaitez nager dans l'inutile annotations de type.

La quantification existentielle il y a un truc que j'ai choisi lorsque l'on travaille sur l' kan-extensions package. C'est une généralisation de celui de l' Yoneda types à partir de là.

Prograide.com

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.

Powered by:

X