Stream

A duplex communications channel (results in creation of a duplex Handle). The standard libraries use this device type when creating Handles for open sockets.

A co-recursive type yielding a single element at a time depending on the internal state it carries.

An instance of Stream has stream type s, underlying monad m and token type t determined by the stream Some rough guidelines for a "correct" instance of Stream:

• unfoldM uncons gives the [t] corresponding to the stream
• A Stream instance is responsible for maintaining the "position within the stream" in the stream state s. This is trivial unless you are using the monad in a non-trivial way.

These are stream fusion versions of some of the functions in Data.Conduit.Combinators. Many functions don't have stream versions here because instead they have RULES which inline a definition that fuses.

A Stream endpoint for a given method emits a stream of encoded values at a given Content-Type, delimited by a framing strategy. Type synonyms are provided for standard methods.

Monadic streams

Stream m a b is a computation in some Monad m that delivers a sequence of elements of type a followed by a result of type b. More concretely, a value of type Stream m a b can be run using runStreamInternal in the Monad m, and it delivers either

• the final result: Done b, or
• Yield a str where a is the next element in the stream, and str is the rest of the stream
• Effect mstr where mstr is some action running in m which generates the rest of the stream.

Stream is itself a Monad, and provides an operation yield that produces a new element of the stream. This makes it convenient to turn existing monadic computations into streams. The idea is that Stream is useful for making a monadic computation that produces values from time to time. This can be used for knitting together two complex monadic operations, so that the producer does not have to produce all its values before the consumer starts consuming them. We make the producer into a Stream, and the consumer pulls on the stream each time it wants a new value. Stream is implemented in the "yoneda" style for efficiency. By representing a stream in this manner fmap and >>= operations are accumulated in the function parameters before being applied once when the stream is destroyed. In the old implementation each usage of mapM and >>= would traverse the entire stream in order to apply the substitution at the leaves. The >>= operation for Stream was a hot-spot in the ticky profile for the ManyConstructors test which called the cg function many times in StgToCmm.hs

Megaparsec's input stream facilities. You probably do not want to import this module directly because Text.Megaparsec re-exports it anyway.

Type class for inputs that can be consumed by the library. Note that the Stream instances for Text and ByteString (strict and lazy) default to "input sharing" (see ShareInput, NoShareInput). We plan to move away from input sharing in a future major release; if you want to retain the current behaviour and are concerned with maximum performance you should consider using the ShareInput wrapper explicitly. Note: before the version 9.0.0 the class included the methods from VisualStream and TraversableStream.

Transmitting HTTP requests and responses holding String in their payload bodies. This is one of the implementation modules for the Network.HTTP interface, representing request and response content as Strings and transmitting them in non-packed form (cf. Network.HTTP.HandleStream and its use of ByteStrings.) over Stream handles. It is mostly here for backwards compatibility, representing how requests and responses were transmitted up until the 4.x releases of the HTTP package. For more detailed information about what the individual exports do, please consult the documentation for Network.HTTP. Notice however that the functions here do not perform any kind of normalization prior to transmission (or receipt); you are responsible for doing any such yourself, or, if you prefer, just switch to using Network.HTTP function instead.

An library for creating abstract streams. Originally part of Gray's/Bringert's HTTP module.

• Changes by Robin Bate Boerop robin@bateboerop.name:
• Removed unnecessary import statements.
• Moved Debug code to StreamDebugger.hs
• Moved Socket-related code to StreamSocket.hs.
• Changes by Simon Foster:
• Split Network.HTTPmodule up into to separate Network.[Stream,TCP,HTTP] modules

Streams should make layering of TLS protocol easier in future, they allow reading/writing to files etc for debugging, they allow use of protocols other than TCP/IP and they allow customisation. Instances of this class should not trim the input in any way, e.g. leave LF on line endings etc. Unless that is exactly the behaviour you want from your twisted instances ;)

Lightweight abstraction over an input/output stream.

Lightweight abstraction over an input/output stream.

An instance of Stream has stream type s, underlying monad m and token type t determined by the stream Some rough guidelines for a "correct" instance of Stream:

• unfoldM uncons gives the [t] corresponding to the stream
• A Stream instance is responsible for maintaining the "position within the stream" in the stream state s. This is trivial unless you are using the monad in a non-trivial way.

output body is a function that writes to a Builder stream

An infinite list