机器和导管（或其他类似的库）之间的概念区别是什么？ [英] What's the conceptual difference between Machines and Conduits (or other similar libraries)?

问题描述

我想了解这个概念，以便我能够理解和使用库，例如​​机器。

我试图遵循RúnarBjarnason在机器上的谈话，但信息太少，基本上只是一堆数据类型。我甚至不明白什么 k 在

  newtype Machine ko =步骤ko（机器ko）
数据步骤kor =停止
 |收益率r 
 |全部等待（t  - > r）（kt）r 
  

或 t 是为什么它是量化的。或者， 类库和机器之间的概念区别是什么？ conduit 和 pipes 都比 machines ，但是 - 也就是说 - machines 正尝试采用与 conduit 和<$ c不同的路径$ c> pipes 。

使用 machines 就类型参数而言简单的API。 conduit 和 pipes 都通过使用5-6个不同类型的变量参数来统一所有的概念。

机器在其输入语言上采用不同的方法来参数化机器（或 Plan ）， （或者在 Plan 的情况下）两个参数。同样，通过选择以这种方式参数化输入语言，它可以使用可以接受来自多个输入源的确定性输入（非）的机器。结果基本上只是一个免费的monad，带有额外的'emit'指令！

作为一个关于如何构建和使用机器的更为严格的策略的交换，它可以最终

也就是说， pipes 和管道已经有很多真实世界的使用，并且 machines 对我来说或多或少是一个操场，RúnarBjarnason和Paul Chiusano。

它目前适用于完全打算使用的输入，但对于处理复杂资源或解析比使用其他两个API获得的输入更合适。

现在，关于这个量词！

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

  data步骤kor =停止
 |收益率r 
 |等待（kr）r 
  

这会产生不幸的副作用，那就是当你去制作一台机器使用 Source ，编译器不会知道要选择哪个 Functor 实例，并且您会游动在不必要的位置类型注释。

存在量化有一个我在处理 kan-extensions 包时遇到的技巧。这是对 Yoneda 类型之一的推广。

I'd like to learn the concept, so that I'd be able to understand and use libraries such as machines.

I tried to follow Rúnar Bjarnason's talk on machines, but there is too little information, basically just a bunch of data types. I can't even understand what k is in

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

or what's t is and why it's quantified. Or, what's the conceptual difference between conduit-like libraries and machines?

解决方案

conduit and pipes are both far more mature than machines, but -- that said -- machines is trying to take a different path than conduit and pipes.

With machines, I'm trying for a relatively simple API in terms of type arguments. Both conduit and pipes have chosen to unify all of their concepts by using 5-6 different type variable arguments.

Machines takes a different approach of parameterizing a machine (or Plan) on its "input language", which puts all the onus on a single extra argument (or two in the case of a Plan). Also by choosing to parameterize the input language in this way it opens up possibilities of using machines that can accept input (non-)deterministically from multiple input sources. The result is basically just a free monad with an extra 'emit' instruction!

In exchange for a slightly more rigorous policy about how you build and use machines, it can eventually offer better safety about asymptotics of the resulting code.

That said, pipes and conduit have had a lot of real world use and machines is more or less a playground for me, Rúnar Bjarnason and Paul Chiusano.

It is currently suitable for working on input that you intend to consume entirely, but less so for working with complicated resources or for parsing than what you get with those other two APIs.

Now, about that quantifier!

t there is actually existentially quantified. By doing so we can make the Monad for machines not care about the functoriality of the k parameter. This is important because of the way Source is implemented. If I didn't need Source to work, then we could use the simpler

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

This would have the unfortunate side-effect that when you went to compose a Machine with a Source, that the compiler wouldn't know what Functor instance to pick and you'd be swimming in unnecessary type annotations.

The existential quantification there is a trick I picked up when working on the kan-extensions package. It is a generalization of one of the Yoneda types from there.

这篇关于机器和导管（或其他类似的库）之间的概念区别是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！