haskell-pipes

问题 I'm looking at the pipes library source code and for instance in the Core module I don't understand why the author is all over the place using the pattern of defining functions like that: runEffect = go where go p = ... Or: pull = go where go a' = ... Or: reflect = go where go p = ... Is this some trick to enable some optimizations? I find it ugly, if it's some optimization trick I really wish the compiler could do it without things like that. But maybe there's another reason? 回答1: GHC will

问题 This question is a bit codegolf and a lot newb. I'm using the awesome pipes library in Haskell, and I'd like to split a pipe to send the same data along multiple channels (do a broadcast). The Pipes.Concurrent tutorial suggests using spawn to create mailboxes, taking advantage of Output 's monoid status. For example, we might do something like this: main = do (output1, input1) <- spawn Unbounded (output2, input2) <- spawn Unbounded let effect1 = fromInput input1 >-> pipe1 let effect2 =

问题 This question is about the Haskell library Pipes. This question is related to 2019 Advent of Code Day 11 (possible spoiler warning) I have two Pipe Int Int m r brain and robot that need to pass information too each other in a continuous loop. That is the output of brain need to go to the input of robot and the output of robot needs to go the the input of brain . When brain finished I need the result of the computation. How do I compose brain and robot into a loop? Ideally a loop with the type

问题 This question is about the Haskell Pipes library 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." While there is an excellent and clearly written tutorial that covers Producers , Consumers , Pipes , and Effects in plain English. The documentation for request and response Client and Server starts by defining Categories and mentioning some other CompSci concepts like "the generator design

问题 In the Pipes Tutorial, it says that: The concrete type synonyms use () to close unused inputs and X (the uninhabited type) to close unused outputs: I'd like to understand why () and X are used the way they are. Why not X or () for both inputs and outputs? 回答1: X in pipes is normally spelled Void in the rest of the Haskell ecosystem, so let's pretend X = Void . It's defined like this: data Void And it has an "eliminator" absurd :: Void -> a absurd x = case x of {} If you have something of type

问题 I'm trying to understand the differences between conduit and pipes . Unlike pipes , conduit has the concept of leftovers. What are leftovers useful for? I'd like to see some examples where leftovers are essential. And since pipes don't have the concept of leftovers, is there any way to achieve a similar behavior with them? 回答1: Gabriel's point that leftovers are always part of parsing is interesting. I'm not sure I would agree, but that may just depend on the definition of parsing. There are

问题 The Problem Hello! I'm writing a logging library and I would love to create a logger, that would run in separate thread, while all applications threads would just send messages to it. I want to find the most performant solution for this problem. I need simple unboud queue here. Approaches I've created some tests to see how available solutions perform and I get very strange results here. I tested 4 implementations (source code provided below) based on: pipes-concurrency Control.Concurrent.Chan

问题 Say I have simple producer/consumer model where the consumer wants to pass back some state to the producer. For instance, let the downstream-flowing objects be objects we want to write to a file and the upstream objects be some token representing where the object was written in the file (e.g. an offset). These two processes might look something like this (with pipes-4.0 ), {-# LANGUAGE GeneralizedNewtypeDeriving #-} import Pipes import Pipes.Core import Control.Monad.Trans.State import

问题 Problem I'm attempting to implement a simple web server with Haskell and the Pipes library. I understand now that cyclic or diamond topologies aren't possible with pipes, however I thought that what I am trying to is. My desired topology is thus: -GET--> handleGET >-> packRequest >-> socketWriteD | socketReadS >-> parseRequest >-routeRequest | -POST-> handlePOST >-> packRequest >-> socketWriteD I have HTTPRequest RequestLine Headers Message and HTTPResponse StatusLine Headers Message types

问题 Using pipes, I'm trying to write an instance of MonadTransControl for the ProxyFast or ProxyCorrect type. This is what I've got: instance MonadTransControl (ProxyFast a' a b' b) where data StT (ProxyFast a' a b' b) a = StProxy { unStProxy :: ProxyFast a' a b' b Identity a} liftWith = undefined restoreT = undefined I have no idea how to write liftWith or restoreT. The instances for the other monad transformers all use a function that "swaps" the monads, for example EitherT e m a -> m (EitherT