Text.Read.Compat

The lex function reads a single lexeme from the input, discarding initial white space, and returning the characters that constitute the lexeme. If the input string contains only white space, lex returns a single successful `lexeme' consisting of the empty string. (Thus lex "" = [("","")].) If there is no legal lexeme at the beginning of the input string, lex fails (i.e. returns []).

This lexer is not completely faithful to the Haskell lexical syntax in the following respects:

• Qualified names are not handled properly

• Octal and hexadecimal numerics are not recognized as a single token

• Comments are not treated properly

Parse a single lexeme

(parens p) parses "P", "(P0)", "((P0))", etc, where p parses "P" in the current precedence context and parses "P0" in precedence context zero

A possible replacement definition for the readList method (GHC only). This is only needed for GHC, and even then only for Read instances where readListPrec isn't defined as readListPrecDefault.

A possible replacement definition for the readListPrec method, defined using readPrec (GHC only).

readParen True p parses what p parses, but surrounded with parentheses.

readParen False p parses what p parses, but optionally surrounded with parentheses.

Symmetric choice.

Local, exclusive, left-biased choice: If left parser locally produces any result at all, then right parser is not used.

Combines all parsers in the specified list.

Consumes and returns the next character. Fails if there is no input left.

Lift a precedence-insensitive ReadP to a ReadPrec.

Look-ahead: returns the part of the input that is left, without consuming it.

Always fails.

(prec n p) checks whether the precedence context is less than or equal to n, and

• if not, fails

• if so, parses p in context n.

Resets the precedence context to zero.

Increases the precedence context by one.

The read function reads input from a string, which must be completely consumed by the input process. read fails with an error if the parse is unsuccessful, and it is therefore discouraged from being used in real applications. Use readMaybe or readEither for safe alternatives.

>>> read "123" :: Int123

>>> read "hello" :: Int*** Exception: Prelude.read: no parse

Parse a string using the Read instance. Succeeds if there is exactly one valid result. A Left value indicates a parse error.

>>> readEither "123" :: Either String IntRight 123

>>> readEither "hello" :: Either String IntLeft "Prelude.read: no parse"

Parse a string using the Read instance. Succeeds if there is exactly one valid result.

>>> readMaybe "123" :: Maybe IntJust 123

>>> readMaybe "hello" :: Maybe IntNothing

equivalent to readsPrec with a precedence of 0.

Parsing of Strings, producing values.

Derived instances of Read make the following assumptions, which derived instances of Text.Show.Show obey:

• If the constructor is defined to be an infix operator, then the derived Read instance will parse only infix applications of the constructor (not the prefix form).

• Associativity is not used to reduce the occurrence of parentheses, although precedence may be.

• If the constructor is defined using record syntax, the derived Read will parse only the record-syntax form, and furthermore, the fields must be given in the same order as the original declaration.

• The derived Read instance allows arbitrary Haskell whitespace between tokens of the input string. Extra parentheses are also allowed.

For example, given the declarations

infixr 5 :^:
data Tree a =  Leaf a  |  Tree a :^: Tree a

the derived instance of Read in Haskell 2010 is equivalent to

instance (Read a) => Read (Tree a) where

        readsPrec d r =  readParen (d > app_prec)
                         (\r -> [(Leaf m,t) |
                                 ("Leaf",s) <- lex r,
                                 (m,t) <- readsPrec (app_prec+1) s]) r

                      ++ readParen (d > up_prec)
                         (\r -> [(u:^:v,w) |
                                 (u,s) <- readsPrec (up_prec+1) r,
                                 (":^:",t) <- lex s,
                                 (v,w) <- readsPrec (up_prec+1) t]) r

          where app_prec = 10
                up_prec = 5

Note that right-associativity of :^: is unused.

The derived instance in GHC is equivalent to

instance (Read a) => Read (Tree a) where

        readPrec = parens $ (prec app_prec $ do
                                 Ident "Leaf" <- lexP
                                 m <- step readPrec
                                 return (Leaf m))

                     +++ (prec up_prec $ do
                                 u <- step readPrec
                                 Symbol ":^:" <- lexP
                                 v <- step readPrec
                                 return (u :^: v))

          where app_prec = 10
                up_prec = 5

        readListPrec = readListPrecDefault

Why do both readsPrec and readPrec exist, and why does GHC opt to implement readPrec in derived Read instances instead of readsPrec? The reason is that readsPrec is based on the ReadS type, and although ReadS is mentioned in the Haskell 2010 Report, it is not a very efficient parser data structure.

readPrec, on the other hand, is based on a much more efficient ReadPrec datatype (a.k.a "new-style parsers"), but its definition relies on the use of the RankNTypes language extension. Therefore, readPrec (and its cousin, readListPrec) are marked as GHC-only. Nevertheless, it is recommended to use readPrec instead of readsPrec whenever possible for the efficiency improvements it brings.

As mentioned above, derived Read instances in GHC will implement readPrec instead of readsPrec. The default implementations of readsPrec (and its cousin, readList) will simply use readPrec under the hood. If you are writing a Read instance by hand, it is recommended to write it like so:

instance Read T where
  readPrec     = ...
  readListPrec = readListPrecDefault

A parser for a type a, represented as a function that takes a String and returns a list of possible parses as (a,String) pairs.

Note that this kind of backtracking parser is very inefficient; reading a large structure may be quite slow (cf ReadP).