<?>

Add JSON Path context to a parser When parsing a complex structure, it helps to annotate (sub)parsers with context, so that if an error occurs, you can find its location.
withObject "Person" $ \o ->
Person
<$> o .: "name" <?> Key "name"
<*> o .: "age"  <?> Key "age"
(Standard methods like '(.:)' already do this.) With such annotations, if an error occurs, you will get a JSON Path location of that error. Since 0.10
The parser p <?> msg behaves as parser p, but whenever the parser p fails without consuming any input, it replaces expect error messages with the expect error message msg. This is normally used at the end of a set alternatives where we want to return an error message in terms of a higher level construct rather than returning all possible characters. For example, if the expr parser from the try example would fail, the error message is: '...: expecting expression'. Without the (<?>) combinator, the message would be like '...: expecting "let" or letter', which is less friendly.
Name the parser, in case failure occurs.
Give a parser a name
A synonym for label in the form of an operator.
The parser p <?> msg behaves as parser p, but whenever the parser p fails without consuming any input, it replaces expect error messages with the expect error message msg. This is normally used at the end of a set alternatives where we want to return an error message in terms of a higher level construct rather than returning all possible characters. For example, if the expr parser from the try example would fail, the error message is: '...: expecting expression'. Without the (<?>) combinator, the message would be like '...: expecting "let" or letter', which is less friendly.
Use this to annotate a field with a type-level string (i.e. a Symbol) representing the help description for that field:
data Example = Example
{ foo :: Int    <?> "Documentation for the foo flag"
, bar :: Double <?> "Documentation for the bar flag"
} deriving (Generic, Show)
If the parser fails, prepend an error message.
A named production (used for reporting expected things).
Name the parser, in case failure occurs.
Name a parser for error reporting in case it fails.
Override the last backtrace level in the error report.
Check whether a is a valid attribute and b is a valid child of p.
Add JSON Path context to a parser When parsing a complex structure, it helps to annotate (sub)parsers with context, so that if an error occurs, you can find its location.
withObject "Person" $ \o ->
Person
<$> o .: "name" <?> Key "name"
<*> o .: "age"  <?> Key "age"
(Standard methods like '(.:)' already do this.) With such annotations, if an error occurs, you will get a JSON Path location of that error. Since 0.10
Add a comment to a parser This info will be used in the schema for documentation. For example:
data Result = Error | Ok
instance YamlSchema Result where
yamlSchema = alternatives
[ Error <$ literalString "Error" <?> "An error"
, Ok <$ literalString "Ok" <?> "Oll Klear"
]
Infix alias for label