[英]Using request and response in with the Pipes library for bidirectional communication
This question is about the Haskell Pipes library这个问题是关于 Haskell Pipes库的
Background:背景:
In a previous question , I asked how to form a cycle using pipes and the answer I got was "don't do that. Use request
and response
instead."在上一个问题中,我询问了如何使用管道形成循环, 我得到的答案是“不要那样做。改用
request
和response
。” While there is an excellent and clearly written tutorial that covers Producers
, Consumers
, Pipes
, and Effects
in plain English.虽然有一个优秀且编写清晰的教程,用简单的英语涵盖了
Producers
、 Consumers
、 Pipes
和Effects
。 The documentation for request
and response
Client
and Server
starts by defining Categories and mentioning some other CompSci concepts like " the generator design pattern. " and " the iteratee design pattern ." request
和response
Client
和Server
的 文档首先定义类别并提到一些其他 CompSci 概念,如“ 生成器设计模式”和“ 迭代设计模式” 。 which are never explained.从来没有解释过。 So I'm stuck not knowing how to "use
request
and response
instead."所以我不知道如何“使用
request
和response
”。
The Setup设置
I have two state-machines like thing that need to pass data back and forth repeatedly, robot
and intCode
.我有两个状态机,比如需要反复来回传递数据的东西,
robot
和intCode
。
The Robot is pretty simple:机器人非常简单:
robot :: Pipe Int Int m r -- robot never returns so its return type is polymorphic
robot = go newRobot
where
go r = do
yield $ color r
c <- toColor <$> await
turn <- toTurn <$> await
go $ update c turn r
It yield
sa value, await
s two instructions (a new color and a turn), updates the state ( r
) of the robot, and starts over.它
yield
sa 值, await
s两条指令(新颜色和转弯),更新机器人的状态 ( r
),然后重新开始。
The intCode
virtual machine runs programmed to communicate with the robot. intCode
虚拟机运行编程为与机器人通信。 It takes a program (called code
) and creates a pipe that will await
the sensor reading from the robot then yield
two instructions to it.它需要一个程序(称为
code
)并创建将一个管await
传感器从机器人读取然后yield
两个指令给它。
(boot code) :: Pipe Int Int m ()
Let's assume that the IntCode VM is not easily modified, but that the robot is.让我们假设 IntCode VM 不容易修改,但机器人是。
Questions:问题:
How are request
and respond
different from await
and yield
? request
和respond
与await
和yield
什么不同?
How do I use them to facilitate continuous communication between the robot and the VM?我如何使用它们来促进机器人和虚拟机之间的持续通信?
The definitions of await
and yield
are: await
和yield
的定义是:
await = request ()
yield = respond
so they are closely related to request
and respond
.所以它们与
request
和respond
密切相关。 The await
and yield
versions have just been specialized to unidirectional pull-based streams ( Producer
s, Pipe
s and Consumer
s). await
和yield
版本刚刚专门用于单向基于拉取的流( Producer
s、 Pipe
s 和Consumer
s)。
To perform bidirectional communication between two endpoints, you want to set up a Client
and a Server
and connect them.要在两个端点之间执行双向通信,您需要设置一个
Client
和一个Server
并连接它们。
A Client
is a monadic action that makes requests: Client
是一个发出请求的 monadic action:
y <- request x
by sending request x
and receiving response y
.通过发送请求
x
和接收响应y
。 A Server
is a monadic action that responds: Server
是一个一元动作,它响应:
x <- respond y
by accepting request x
and sending response y
.通过接受请求
x
并发送响应y
。 Note that these operations are symmetric, so in a given application it's arbitrary which half is the Client
and which half is the Server
.请注意,这些操作是对称的,因此在给定的应用程序中,哪一半是
Client
哪一半是Server
是任意的。
Now, you may notice that while the Client
sends an x
and receives a y
in response, the Server
seems backward.现在,您可能会注意到,当
Client
发送x
并接收y
作为响应时, Server
似乎落后了。 It sends response y
before receiving request x
!它在收到请求
x
之前发送响应y
! In fact, it just needs to operate one step behind -- a server in a pull-based stream will want to send its response y
to the previous request in order to receive the next request x
.事实上,它只需要向后一步操作——基于拉取的流中的服务器想要将其响应
y
发送到前一个请求,以便接收下一个请求x
。
As a simple example, here's a Client
that requests addition of numbers to calculate powers of two:作为一个简单的例子,这里有一个
Client
请求加法来计算 2 的幂:
-- |Client to generate powers of two
power2 :: Client (Int, Int) Int IO ()
power2 = go 1
where go n | n <= 1024 = do
liftIO $ print n
n' <- request (n,n) -- ask adder to add "n" and "n"
go n'
go n = liftIO $ print "Done"
Writing the server to add numbers is a little trickier because of this "one step behind" business.由于这种“落后一步”的业务,编写服务器以添加数字有点棘手。 We might start by writing:
我们可以从写开始:
-- |Server to sum numbers
sum2 :: Server (Int, Int) Int IO ()
sum2 = do
(n,n) <- respond ??? -- send previous response to get current request
let n' = n+n
??? <- respond n' -- send current reponse to get next request
The trick is to get things started by accepting the first request as an argument to the monadic action:诀窍是通过接受第一个请求作为 monadic 操作的参数来开始工作:
-- |Server to sum numbers
sum2 :: (Int, Int) -> Server (Int, Int) Int IO ()
sum2 (m, n) = do
(m', n') <- respond (m+n) -- send response to get next request
sum2 (m', n') -- and loop
Fortunately, the pull point-ful connector +>>
has the right type to connect these:幸运的是,pull point-ful 连接器
+>>
有正确的类型来连接这些:
mypipe :: Effect IO ()
mypipe = sum2 +>> power2
and we can run the resulting effect in the usual manner:我们可以以通常的方式运行结果效果:
main :: IO ()
main = runEffect mypipe
ghci> main
1
2
4
8
16
32
64
128
256
512
1024
"Done"
Note that, for this type of bidirectional communication, requests and responses need to run in synchronous lock-step, so you can't do the equivalent of yielding once and awaiting twice.请注意,对于这种类型的双向通信,请求和响应需要在同步锁步中运行,因此您不能执行一次让步并等待两次的等效操作。 If you wanted to re-design the example above to send requests in two parts, you'd need to develop a protocol with sensible request and response types, like:
如果您想重新设计上面的示例以分两部分发送请求,您需要开发一个具有合理请求和响应类型的协议,例如:
data Req = First Int | Second Int
data Res = AckFirst | Answer Int
power2 = ...
AckFirst <- request n
Answer n' <- request n
sum2 = ...
First m' <- respond (Answer (m+n))
Second n' <- respond AckFirst
...
For your brain/robot application, you can design the robot as either a client:对于您的大脑/机器人应用程序,您可以将机器人设计为客户端:
robotC :: Client Color (Color,Turn) Identity ()
robotC = go newRobot
where
go r = do
(c, turn) <- request (color r)
go $ update c turn r
or a server:或服务器:
robotS :: Server (Color,Turn) Color Identity ()
robotS = go newRobot
where
go r = do
(c, turn) <- respond (color r)
go $ update c turn r
Because the robot produces output before consuming input, as a client it will fit into a pull-based stream with a brain server:因为机器人在消费输入之前产生输出,所以作为客户端,它将适合带有大脑服务器的基于拉动的流:
brainS :: Color -> Server Color (Color,Turn) Identity ()
brainS = ...
approach1 = brainS +>> robotC
or as a server it will fit into a push-based stream with a brain client:或者作为服务器,它将适合带有大脑客户端的基于推送的流:
brainC :: Color -> Client (Color,Turn) Color Identity ()
brainC = ...
approach2 = robotS >>~ brainC
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.