机器和管道(或其他类似的库)之间的概念差异是什么？

Question

我想学习这个概念,这样我就能理解和使用诸如机器之类的库.

我试图关注RúnarBjarnason关于机器的讨论,但信息太少,基本上只是一堆数据类型.我甚至无法理解什么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

或者t它是什么以及它为什么被量化.或者,管道式库和机器之间的概念差异是什么？

Answer 1

conduit并且pipes都远超过成熟machines,但是-这说的- machines正试图采取比不同的路径conduit和pipes.

有了machines,我正在尝试在类型参数方面使用相对简单的API.二者conduit并pipes选择通过使用5-6不同类型的可变参数,以统一他们所有的概念.

机器采用不同的方法将机器(或Plan)参数化为"输入语言",这使得所有的责任都放在一个额外的参数上(或者在a的情况下为两个Plan).此外,通过选择以这种方式参数化输入语言,它开辟了使用可以从多个输入源确定性地接受输入(非)的机器的可能性.结果基本上只是一个带有额外"发射"指令的免费monad!

作为对如何构建和使用机器的更严格的策略的交换,它最终可以提供关于结果代码的渐近性的更好的安全性.

也就是说,pipes并且conduit有很多现实世界的使用,machines或多或少是我的游乐场,RúnarBjarnason和Paul Chiusano.

它目前适合处理您打算完全使用的输入,但对于处理复杂资源或解析而言,不如使用其他两个API获得的那样.

现在,关于量词!

t实际上存在量化.通过这样做,我们可以使Monad机器不关心k参数的功能性.这很重要,因为Source实施方式.如果我不需要Source工作,那么我们可以使用更简单的方法

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

这会产生令人遗憾的副作用,当你去Source编写一台带有a的机器时,编译器就不知道Functor要选择哪个实例,而你会在不必要的类型注释中游泳.

存在量化是我在处理kan-extensions包时所采用的技巧.它是其中一种Yoneda类型的概括.