Hoogle Search

Within LTS Haskell 24.34 (ghc-9.10.3)

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

  1. class Read a

    hledger-web Hledger.Web.Import

    Parsing of Strings, producing values. Derived instances of Read make the following assumptions, which derived instances of 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

  2. class Read a

    streamly Streamly.Data.Stream.MkType

    Parsing of Strings, producing values. Derived instances of Read make the following assumptions, which derived instances of 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

  3. module Yi.Keymap.Vim.Ex.Commands.Read

    No documentation available.

  4. class Read a

    classy-prelude-yesod ClassyPrelude.Yesod

    Parsing of Strings, producing values. Derived instances of Read make the following assumptions, which derived instances of 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

  5. class Read a

    constrained-categories Control.Category.Constrained.Prelude

    Parsing of Strings, producing values. Derived instances of Read make the following assumptions, which derived instances of 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

  6. class Read a

    constrained-categories Control.Category.Hask

    Parsing of Strings, producing values. Derived instances of Read make the following assumptions, which derived instances of 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

  7. class Read a

    copilot-language Copilot.Language.Prelude

    Parsing of Strings, producing values. Derived instances of Read make the following assumptions, which derived instances of 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

  8. class Read a

    verset Verset

    Parsing of Strings, producing values. Derived instances of Read make the following assumptions, which derived instances of 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

  9. readFile :: FilePath -> IO String

    base Prelude

    The readFile function reads a file and returns the contents of the file as a string. The file is read lazily, on demand, as with getContents.

  10. readIO :: Read a => String -> IO a

    base Prelude

    The readIO function is similar to read except that it signals parse failure to the IO monad instead of terminating the program.

Page 19 of many | Previous | Next