Hoogle Search

Within LTS Haskell 24.0 (ghc-9.10.2)

Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.

  1. ciosToLazyByteString :: AllocationStrategy -> (a -> (b, LazyByteString)) -> ChunkIOStream a -> (b, LazyByteString)

    bytestring Data.ByteString.Builder.Internal

    Convert a ChunkIOStream to a lazy tuple of the result and the written LazyByteString using unsafeDupablePerformIO.

  2. ciosUnitToLazyByteString :: AllocationStrategy -> LazyByteString -> ChunkIOStream () -> LazyByteString

    bytestring Data.ByteString.Builder.Internal

    Convert a ChunkIOStream () to a LazyByteString using unsafeDupablePerformIO.

  3. putToLazyByteString :: Put a -> (a, LazyByteString)

    bytestring Data.ByteString.Builder.Internal

    Execute a Put and return the computed result and the bytes written during the computation as a LazyByteString. This function is strict in the computed result and lazy in the writing of the bytes. For example, given

    infinitePut = sequence_ (repeat (putBuilder (word8 1))) >> return 0
    
    
    evaluating the expression
    fst $ putToLazyByteString infinitePut
    
    
    does not terminate, while evaluating the expression
    L.head $ snd $ putToLazyByteString infinitePut
    
    
    does terminate and yields the value 1 :: Word8. An illustrative example for these strictness properties is the implementation of Base64 decoding (http://en.wikipedia.org/wiki/Base64).
    type DecodingState = ...
    
    decodeBase64 :: StrictByteString -> DecodingState -> Put (Maybe DecodingState)
    decodeBase64 = ...
    
    
    The above function takes a StrictByteString supposed to represent Base64 encoded data and the current decoding state. It writes the decoded bytes as the side-effect of the Put and returns the new decoding state, if the decoding of all data in the StrictByteString was successful. The checking if the StrictByteString represents Base64 encoded data and the actual decoding are fused. This makes the common case, where all data represents Base64 encoded data, more efficient. It also implies that all data must be decoded before the final decoding state can be returned. Puts are intended for implementing such fused checking and decoding/encoding, which is reflected in their strictness properties.

  4. putToLazyByteStringWith :: AllocationStrategy -> (a -> (b, LazyByteString)) -> Put a -> (b, LazyByteString)

    bytestring Data.ByteString.Builder.Internal

    Execute a Put with a buffer-allocation strategy and a continuation. For example, putToLazyByteString is implemented as follows.

    putToLazyByteString = putToLazyByteStringWith
    (safeStrategy smallChunkSize defaultChunkSize) (x -> (x, L.empty))
    
    

  5. toLazyByteString :: Builder -> LazyByteString

    bytestring Data.ByteString.Builder.Internal

    Execute a Builder and return the generated chunks as a LazyByteString. The work is performed lazy, i.e., only when a chunk of the LazyByteString is forced.

  6. toLazyByteStringWith :: AllocationStrategy -> LazyByteString -> Builder -> LazyByteString

    bytestring Data.ByteString.Builder.Internal

    Heavy inlining. Execute a Builder with custom execution parameters. This function is inlined despite its heavy code-size to allow fusing with the allocation strategy. For example, the default Builder execution function toLazyByteString is defined as follows.

    {-# NOINLINE toLazyByteString #-}
    toLazyByteString =
    toLazyByteStringWith (safeStrategy smallChunkSize defaultChunkSize) L.Empty
    
    where L.Empty is the zero-length LazyByteString. In most cases, the parameters used by toLazyByteString give good performance. A sub-performing case of toLazyByteString is executing short (<128 bytes) Builders. In this case, the allocation overhead for the first 4kb buffer and the trimming cost dominate the cost of executing the Builder. You can avoid this problem using
    toLazyByteStringWith (safeStrategy 128 smallChunkSize) L.Empty
    
    This reduces the allocation and trimming overhead, as all generated LazyByteStrings fit into the first buffer and there is no trimming required, if more than 64 bytes and less than 128 bytes are written.

  7. primMapLazyByteStringBounded :: BoundedPrim Word8 -> LazyByteString -> Builder

    bytestring Data.ByteString.Builder.Prim

    Chunk-wise application of primMapByteStringBounded.

  8. primMapLazyByteStringFixed :: FixedPrim Word8 -> LazyByteString -> Builder

    bytestring Data.ByteString.Builder.Prim

    Heavy inlining. Encode all bytes of a LazyByteString from left-to-right with a FixedPrim.

  9. unpackAppendBytesLazy :: ByteString -> [Word8] -> [Word8]

    bytestring Data.ByteString.Internal

    No documentation available.

  10. unpackAppendCharsLazy :: ByteString -> [Char] -> [Char]

    bytestring Data.ByteString.Internal

    No documentation available.

Page 3 of many | Previous | Next