关于haskell:在管道库中使用请求和响应进行双向通信

Using request and response in with the Pipes library for bidirectional communication

这个问题是关于 Haskell Pipes 库的

背景:

在上一个问题中,我询问了如何使用管道形成循环,我得到的答案是"不要那样做。改用 requestresponse"。虽然有一个优秀且清晰的教程,其中涵盖了简单英语的 ProducersConsumersPipesEffectsrequestresponse ClientServer 的文档首先定义了类别并提到了一些其他 CompSci 概念,例如"生成器设计模式"。和"迭代设计模式"。从来没有解释过。所以我不知道如何"改用 requestresponse。"

设置

我有两个状态机,需要反复来回传递数据,robotintCode

机器人很简单:

1
2
3
4
5
6
7
8
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

yield是一个值,await是两条指令(一个新颜色和一个转弯),更新机器人的状态(r),然后重新开始。

intCode 虚拟机运行编程以与机器人通信。它需要一个程序(称为 code)并创建一个管道,该管道将 await 传感器从机器人读取,然后 yield 向它发送两条指令。

1
(boot code) :: Pipe Int Int m ()

假设 IntCode VM 不容易修改,但机器人是。

问题:

requestrespondawaityield 有何不同?

如何使用它们来促进机器人和虚拟机之间的持续通信?


awaityield的定义是:

1
2
await = request ()
yield = respond

所以它们与 requestrespond 密切相关。 awaityield 版本专门用于单向基于拉的流(Producers、Pipes 和 Consumers)。

要在两个端点之间进行双向通信,您需要设置一个 Client 和一个 Server 并连接它们。

Client 是发出请求的一元动作:

1
y <- request x

通过发送请求 x 并接收响应 yServer 是一个响应的单子动作:

1
x <- respond y

通过接受请求 x 并发送响应 y。请注意,这些操作是对称的,因此在给定的应用程序中,哪一半是 Client 哪一半是 Server 是任意的。

现在,您可能会注意到,当 Client 发送一个 x 并接收一个 y 作为响应时,Server 似乎是向后的。它在收到请求 x 之前发送响应 y!事实上,它只需要落后一步操作——基于拉的流中的服务器将希望将其响应 y 发送到上一个请求,以便接收下一个请求 x

作为一个简单的例子,这里有一个 Client,它请求数字相加来计算 2 的幂:

1
2
3
4
5
6
7
8
-- |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"

因为这个"落后一步"的业务,编写服务器来添加数字有点棘手。我们可以先写:

1
2
3
4
5
6
-- |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

诀窍是通过接受第一个请求作为一元动作的参数来开始:

1
2
3
4
5
-- |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

幸运的是,拉点连接器 +>> 具有正确的类型来连接这些:

1
2
mypipe :: Effect IO ()
mypipe = sum2 +>> power2

我们可以以通常的方式运行生成的效果:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
main :: IO ()
main = runEffect mypipe

ghci> main
1
2
4
8
16
32
64
128
256
512
1024
"Done"

请注意,对于这种类型的双向通信,请求和响应需要以同步的锁步运行,因此您不能进行一次让步和两次等待的等效操作。如果您想重新设计上面的示例以分两部分发送请求,您需要开发一个具有合理请求和响应类型的协议,例如:

1
2
3
4
5
6
7
8
9
10
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
    ...

对于您的大脑/机器人应用程序,您可以将机器人设计为客户端:

1
2
3
4
5
6
robotC :: Client Color (Color,Turn) Identity ()
robotC = go newRobot
  where
    go r = do
      (c, turn) <- request (color r)
      go $ update c turn r

或服务器:

1
2
3
4
5
6
robotS :: Server (Color,Turn) Color Identity ()
robotS = go newRobot
  where
    go r = do
      (c, turn) <- respond (color r)
      go $ update c turn r

因为机器人在消费输入之前会产生输出,作为客户端,它会适合带有大脑服务器的基于拉取的流:

1
2
3
4
brainS :: Color -> Server Color (Color,Turn) Identity ()
brainS = ...

approach1 = brainS +>> robotC

或者作为一个服务器,它将适合一个带有大脑客户端的基于推送的流:

1
2
3
4
brainC :: Color -> Client (Color,Turn) Color Identity ()
brainC = ...

approach2 = robotS >>~ brainC