Sequence actions, discarding the value of the first argument.
Examples
If used in conjunction with the Applicative instance for Maybe,
you can chain Maybe computations, with a possible "early return"
in case of Nothing.
Example1 expression
>>> Just 2 *> Just 3Just 3
Example1 expression
>>> Nothing *> Just 3Nothing
Of course a more interesting use case would be to have effectful
computations instead of just returning pure values.
Example4 expressions
>>> import Data.Char>>> import GHC.Internal.Text.ParserCombinators.ReadP>>> let p = string "my name is " *> munch1 isAlpha <* eof>>> readP_to_S p "my name is Simon"[("Simon","")]
Replace all locations in the input with the same value.
The default definition is fmap . const, but this may be
overridden with a more efficient version.
Examples
Perform a computation with Maybe and replace the result with a
constant value if it is Just:
Example2 expressions
>>> 'a' <$ Just 2Just 'a'>>> 'a' <$ NothingNothing
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.
parse p filePath input runs a parser p without user
state. The filePath is only used in error messages and may be the
empty string. Returns either a ParseError (Left)
or a value of type a (Right).
main = case parse numbers "" "11, 2, 43" of
Left err -> print err
Right xs -> print (sum xs)
numbers = commaSep integer
The most general way to run a parser. runParser p state filePath
input runs parser p on the input list of tokens input,
obtained from source filePath with the initial user state st.
The filePath is only used in error messages and may be the empty
string. Returns either a ParseError (Left) or a
value of type a (Right).
parseFromFile p fname = do
input <- readFile fname
return (runParser p () fname input)
The parser token showTok posFromTok testTok accepts a token t
with result x when the function testTok t returns Just x. The
source position of the t should be returned by posFromTok t and
the token can be shown using showTok t.
This combinator is expressed in terms of tokenPrim.
It is used to accept user defined token streams. For example,
suppose that we have a stream of basic tokens tupled with source
positions. We can than define a parser that accepts single tokens as:
mytoken x
= token showTok posFromTok testTok
where
showTok (pos,t) = show t
posFromTok (pos,t) = pos
testTok (pos,t) = if x == t then Just t else Nothing
The parser token showTok nextPos testTok accepts a token t
with result x when the function testTok t returns Just x. The
token can be shown using showTok t. The position of the next
token should be returned when nextPos is called with the current
source position pos, the current token t and the rest of the
tokens toks, nextPos pos t toks.
This is the most primitive combinator for accepting tokens. For
example, the char parser could be implemented as:
char c
= tokenPrim showChar nextPos testChar
where
showChar x = "'" ++ x ++ "'"
testChar x = if x == c then Just x else Nothing
nextPos pos x xs = updatePosChar pos x
The most primitive token recogniser. The expression
tokenPrimEx show nextpos mbnextstate test, recognises tokens when test
returns Just x (and returns the value x). Tokens are shown in error
messages using show. The position is calculated using nextpos, and finally,
mbnextstate, can hold a function that updates the user state on every token
recognised (nice to count tokens :-).
The function is packed into a Maybe type for performance reasons.
The parser try p behaves like parser p, except that it
pretends that it hasn't consumed any input when an error occurs.
This combinator is used whenever arbitrary look ahead is needed.
Since it pretends that it hasn't consumed any input when p fails,
the (<|>) combinator will try its second alternative even when the
first parser failed while consuming input.
The try combinator can for example be used to distinguish
identifiers and reserved words. Both reserved words and identifiers
are a sequence of letters. Whenever we expect a certain reserved
word where we can also expect an identifier we have to use the try
combinator. Suppose we write:
If the user writes "lexical", the parser fails with: unexpected
'x', expecting 't' in "let". Indeed, since the (<|>) combinator
only tries alternatives when the first alternative hasn't consumed
input, the identifier parser is never tried (because the prefix
"le" of the string "let" parser is already consumed). The
right behaviour can be obtained by adding the try combinator:
The parser unexpected msg always fails with an unexpected error
message msg without consuming any input.
The parsers fail, (<?>) and unexpected are the three parsers
used to generate error messages. Of these, only (<?>) is commonly
used. For an example of the use of unexpected, see the definition
of notFollowedBy.
>>> many (putStr "la")lalalalalalalalala... * goes on forever *
Example1 expression
>>> many NothingJust []
Example1 expression
>>> take 5 <$> many (Just 1)* hangs forever *
Note that this function can be used with Parsers based on
Applicatives. In that case many parser will attempt to
parse parser zero or more times until it fails.