Data.RESP

Documentation

data RespReply

Top-level resp reply. Cannot be nested.

Constructors

RespPush !ByteString ![RespExpr]

RespExpr !RespExpr

Instances

Generic RespReply

Defined in Data.RESP

Associated Types

type Rep RespReply :: Type -> Type

Methods

from :: RespReply -> Rep RespReply x

to :: Rep RespReply x -> RespReply

Show RespReply

Defined in Data.RESP

Methods

showsPrec :: Int -> RespReply -> ShowS

show :: RespReply -> String

showList :: [RespReply] -> ShowS

Eq RespReply

Defined in Data.RESP

Methods

(==) :: RespReply -> RespReply -> Bool

(/=) :: RespReply -> RespReply -> Bool

Ord RespReply

Defined in Data.RESP

Methods

compare :: RespReply -> RespReply -> Ordering

(<) :: RespReply -> RespReply -> Bool

(<=) :: RespReply -> RespReply -> Bool

(>) :: RespReply -> RespReply -> Bool

(>=) :: RespReply -> RespReply -> Bool

max :: RespReply -> RespReply -> RespReply

min :: RespReply -> RespReply -> RespReply

type Rep RespReply

Defined in Data.RESP

type Rep RespReply = D1 ('MetaData "RespReply" "Data.RESP" "resp-1.0.0-LYF9uNboG4jCMPZqHytGRd" 'False) (C1 ('MetaCons "RespPush" 'PrefixI 'False) (S1 ('MetaSel ('Nothing :: Maybe Symbol) 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 ByteString) :*: S1 ('MetaSel ('Nothing :: Maybe Symbol) 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 [RespExpr])) :+: C1 ('MetaCons "RespExpr" 'PrefixI 'False) (S1 ('MetaSel ('Nothing :: Maybe Symbol) 'NoSourceUnpackedness 'SourceStrict 'DecidedStrict) (Rec0 RespExpr)))

data RespExpr

RESP3 Expression.

This descriminates the difference between RespString and RespBlob, even though both contain bytestrings, in order to not throw away information. A caller might care whether the response was delivered with "+", or "$".

We do not, however descriminate between the different encodings of null. As far as I can tell, these are considered a mistake in the previous versions of the RESP spec, and clients should treat the different encodings the same.

Why don't we parse RespString into Text? Well, the caller might not actually need to decode it into text, and so we let the caller decide. This way, we don't have to deal with encoding errors.

Similarly, we don't parse a RespMap into a HashMap, because that would involve imposing our choice of data structure on the caller. They might want to use HashMap, Map, or just use the lookup function.

Given these choices, our purview is simple: Parse the text protocol into a Haskell datatype, maintaining all useful information, and not imposing our taste onto the caller.

Constructors

RespString !ByteString

RespBlob !ByteString

RespStreamingBlob !LazyByteString

RespStringError !ByteString

RespBlobError !ByteString

RespArray ![RespExpr]

RespInteger !Int64

RespNull

RespBool !Bool

RespDouble !Double

RespVerbatimString !ByteString

RespVerbatimMarkdown !ByteString

RespBigInteger !Integer

RespMap ![(RespExpr, RespExpr)]

RespSet ![RespExpr]

RespAttribute ![(RespExpr, RespExpr)] RespExpr

Instances

Generic RespExpr

Defined in Data.RESP

Associated Types

type Rep RespExpr :: Type -> Type

Methods

from :: RespExpr -> Rep RespExpr x

to :: Rep RespExpr x -> RespExpr

Show RespExpr

Defined in Data.RESP

Methods

showsPrec :: Int -> RespExpr -> ShowS

show :: RespExpr -> String

showList :: [RespExpr] -> ShowS

Eq RespExpr

Defined in Data.RESP

Methods

(==) :: RespExpr -> RespExpr -> Bool

(/=) :: RespExpr -> RespExpr -> Bool

Ord RespExpr

Defined in Data.RESP

Methods

compare :: RespExpr -> RespExpr -> Ordering

(<) :: RespExpr -> RespExpr -> Bool

(<=) :: RespExpr -> RespExpr -> Bool

(>) :: RespExpr -> RespExpr -> Bool

(>=) :: RespExpr -> RespExpr -> Bool

max :: RespExpr -> RespExpr -> RespExpr

min :: RespExpr -> RespExpr -> RespExpr

type Rep RespExpr

Defined in Data.RESP

type Rep RespExpr

parseReply :: Scanner RespReply

parseExpression :: Scanner RespExpr