Hoogle Search
Within LTS Haskell 24.31 (ghc-9.10.3)
Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.
(
:$$: ) :: Doc s -> Doc s -> Doc ssymparsec Symparsec.Parser.Common stack docs on top of each other (newline)
(
:<>: ) :: Doc s -> Doc s -> Doc ssymparsec Symparsec.Parser.Common append docs next to each other
type family (pl :: PParser sl rl)
:<|>: (pr :: PParser sr rr) :: PParser OrS sl sr Either rl rrsymparsec Symparsec.Parser.Or Limited parser choice. Try left; if it fails, backtrack and try right. However, _the right choice must consume at least as much as the left choice._ If it doesn't, then even if the right parser succeeds, it will emit an error. This behaviour is due to the parser runner not supporting backtracking. We can emulate it by storing a record of the characters parsed so far, and "replaying" these on the right parser if the left parser fails. If the right parser ends before we finish replaying, we will have consumed extra characters that we can't ask the runner to revert. For example, Literal "abcd" :|: Literal "ab" is bad. An input of abcX will trigger the consumption error. I can't think of another way to implement this with the current parser design. I think it's the best we have. A more complex parser design may permit changing internal running state, so we could save and load state (this would permit a Try p parser). But that's scary. And you're better off designing your type-level string schemas to permit non-backtracking parsing anyway... Also problematic is that we never emit a left parser error, so errors can degrade. Perhaps your string was one character off a successful left parse; but if it fails, you won't see that error.
type family (pl :: PParser sl rl)
:<*>: (pr :: PParser sr rr) :: PParser Either sl (rl, sr) (rl, rr)symparsec Symparsec.Parser.Then Sequence two parsers, running left then right, and return both results.
type family (pl :: PParser sl rl)
:*>: (pr :: PParser sr rr) :: PParser Either sl sr rrsymparsec Symparsec.Parser.Then.VoidLeft Sequence two parsers, running left then right, and discard the return value of the left parser.
type family (pl :: PParser sl rl)
:<*: (pr :: PParser sr rr) :: PParser Either sl (rl, sr) rlsymparsec Symparsec.Parser.Then.VoidRight Sequence two parsers, running left then right, and discard the return value of the right parser.
type family (pl :: PParser sl rl)
:*>: (pr :: PParser sr rr) :: PParser Either sl sr rrsymparsec Symparsec.Parsers Sequence two parsers, running left then right, and discard the return value of the left parser.
type family (pl :: PParser sl rl)
:<*: (pr :: PParser sr rr) :: PParser Either sl (rl, sr) rlsymparsec Symparsec.Parsers Sequence two parsers, running left then right, and discard the return value of the right parser.
type family (pl :: PParser sl rl)
:<*>: (pr :: PParser sr rr) :: PParser Either sl (rl, sr) (rl, rr)symparsec Symparsec.Parsers Sequence two parsers, running left then right, and return both results.
type family (pl :: PParser sl rl)
:<|>: (pr :: PParser sr rr) :: PParser OrS sl sr Either rl rrsymparsec Symparsec.Parsers Limited parser choice. Try left; if it fails, backtrack and try right. However, _the right choice must consume at least as much as the left choice._ If it doesn't, then even if the right parser succeeds, it will emit an error. This behaviour is due to the parser runner not supporting backtracking. We can emulate it by storing a record of the characters parsed so far, and "replaying" these on the right parser if the left parser fails. If the right parser ends before we finish replaying, we will have consumed extra characters that we can't ask the runner to revert. For example, Literal "abcd" :|: Literal "ab" is bad. An input of abcX will trigger the consumption error. I can't think of another way to implement this with the current parser design. I think it's the best we have. A more complex parser design may permit changing internal running state, so we could save and load state (this would permit a Try p parser). But that's scary. And you're better off designing your type-level string schemas to permit non-backtracking parsing anyway... Also problematic is that we never emit a left parser error, so errors can degrade. Perhaps your string was one character off a successful left parse; but if it fails, you won't see that error.