haskell - ¿Cuál es la diferencia conceptual entre Máquinas y Conductos(u otras bibliotecas similares)?

conduit transducer-machines

Question

Me gustaría aprender el concepto para poder entender y usar bibliotecas como machines .

Intenté seguir la charla de Rúnar Bjarnason sobre las máquinas , pero hay muy poca información, básicamente solo un montón de tipos de datos. Ni siquiera puedo entender en qué está k

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

o lo que es t y por qué se cuantifica. O, ¿cuál es la diferencia conceptual entre bibliotecas y máquinas, como conductos ?

Answer 1

conduit y las pipes son mucho más maduros que las machines , pero, dicho esto, las machines están tratando de tomar un camino diferente al de los conduit y pipes .

Con las machines , estoy intentando una API relativamente simple en términos de argumentos de tipo. Tanto el conduit como las pipes han elegido unificar todos sus conceptos mediante el uso de 5 a 6 argumentos de variables de tipo diferente.

Machines adopta un enfoque diferente de la parametrización de una máquina (o Plan ) en su "idioma de entrada", lo que pone toda la responsabilidad en un solo argumento adicional (o dos en el caso de un Plan ). Además, al elegir parametrizar el idioma de entrada de esta manera, se abren posibilidades de usar máquinas que pueden aceptar entrada (no) determinísticamente de múltiples fuentes de entrada. ¡El resultado es básicamente una mónada gratuita con una instrucción ''emitir'' adicional!

A cambio de una política un poco más rigurosa sobre cómo construir y utilizar las máquinas, puede ofrecer una mejor seguridad sobre los asintóticos del código resultante.

Dicho esto, las pipes y conduit han tenido un gran uso en el mundo real y las machines son más o menos un campo de juego para mí, Rúnar Bjarnason y Paul Chiusano.

Actualmente es adecuado para trabajar en entradas que pretende consumir por completo, pero menos para trabajar con recursos complicados o para analizar que lo que obtiene con esas otras dos API.

Ahora, sobre ese cuantificador!

t realidad hay cuantificada existencialmente. Al hacerlo, podemos hacer que la Monad para máquinas no se preocupe por la funcionalidad del parámetro k . Esto es importante por la forma en que se implementa la Source . Si no necesitara Source para trabajar, entonces podríamos usar el más simple

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

Esto tendría el desafortunado efecto secundario de que cuando compusiera una Máquina con una Source , el compilador no sabría qué instancia de Functor elegir y estaría nadando en anotaciones de tipo innecesarias.

La cuantificación existencial es un truco que aprendí al trabajar en el paquete kan-extensions . Es una generalización de uno de los tipos de Yoneda partir de ahí.