Control.Proxy를 사용하도록 StateT IO 모나로 변환 - 서버이고 클라이언트입니까?

Question

나는 게임 엔진을 구현 중이다. 현재 대부분의 코드는 StateT Game IO() 모나드에 있습니다. 나는 하나 개의 기능을 통해, 모든 선물 옵션을 사용자에게 묻는 응답 읽고, 그것을 반환

getChoice :: Show a => [ a ] -> IO a 

모든 IO 채널을 사용자 입력을 얻기 위해 IO를 사용하고 사실이다. 사용자 응답 (및 초기 상태)의 특정 흐름에 대해 게임은 결정 론적으로 진행되며 테스트를 돕기 위해 이러한 사용자 응답을 분석하고 싶습니다.

내가 파이프를 사용하도록 변환하려고하면 가장 가까운 느낌은 현재 StateT Game IO()에있는 모든 코드를 변경하고 Proxy p, Monad m => Client p [String] String m()에서 실행되도록하는 것입니다. 이 방법으로 사용자의 선택을 여전히 요청할 수 있습니다. 그러면 사용자 선택이 필요할 때 제공 될 것이라고 가정하고 차단 스타일로 엔진 코드를 작성할 수 있습니다.

그러나 이것은 틀린 것 같습니다. 분명히 사용자는 클라이언트 여야하고 게임 엔진은 서버입니까? 이 구별을 올바르게하기 위해 어떤 원칙을 사용할 수 있습니까? 상류 및 하류 request와 respond, 그대로 pipes에서

Answer 1

nushio와 마찬가지로 Client과 Server은 서로 완전히 대칭입니다. 비대칭을 도입하는 유일한 방법은 합성 연산자입니다. (>->)은 Client 끝에서 시작하고 (>~>)은 Server 끝에서 시작됩니다.

(>->)을 사용 중이므로 Client 구성 요소에 "주도권"이 있고 물건이 굴러 들었다는 의미입니다. 즉 Client이 request이 아닌 한 Server은 아무 것도하지 않습니다. 처음에는 Client이 시작되는 것을 제외하고는 Client과 Server 사이에는 차이가 없습니다.

당신이 Client 및 Server에 전문 ( >->)의 유형 주도권이 비대칭 반영

:

(>->) => ([String] -> Server [String] String IO r) 
     -> (()  -> Client [String] String IO r) 
     -> (()  -> Session    IO r) 

Server (즉, 사용자)를 만 Client (즉 게임 엔진)에 반응 , 이유는 서버가 [String] 유형의 인수를 받아 들여 공을 굴릴 수 있어야하기 때문입니다. 이는 게임 엔진이 사용자에게 선택 항목을 묻는 메시지를 표시하지 않으면 사용자가 선택할 수있는 선택 항목 집합이 없기 때문에 사용자가 "실행할 수 없습니다"라는 사실에 반영됩니다. 게임 엔진이 문제가 아닌 방식으로 사용자가 제어 할 수 있습니다. 다른 방법으로 지정하고 사용자가 게임 엔진을 구동하게하면 역할이 바뀝니다.

Answer 2

, Server S와 S Client 거의 교환 할 수있다. 한 가지 차이점은 첫 번째 요청을 발행하여 Session을 시작하는 것이 Client의 작업이라는 것입니다.

http://hackage.haskell.org/packages/archive/pipes/2.5.0/doc/html/Control-Proxy-Tutorial.html

난 당신이 모두 Client 및 Server으로 게임 플레이어를 공식화 할 수 꽤 확신 : 그것은 모든 감각에 관하여이다. 왜 그/그녀를 키보드 입력 서버로 생각하지 않습니까?