A lexer describes how to transform the input string into a series of tokens.

Create a Lexer with a given description for the lexical structure of the language.

Create a Lexer with a given description for the lexical structure of the language, which reports errors according to the given error config.

This contains parsers for tokens treated as "words", such that whitespace will be consumed after each token has been parsed.

This contains parsers for tokens that do not give any special treatment to whitespace.

This combinator ensures a parser fully parses all available input, and consumes whitespace at the start.

This contains parsers that directly treat whitespace.

A Lexeme is a collection of parsers for handling various tokens (such as symbols and names), where either all or none of the parsers consume whitespace.

This turns a non-lexeme parser into a lexeme one by ensuring whitespace is consumed after the parser.

Parse the given string.

This contains lexing functionality relevant to the parsing of atomic symbols.

This contains lexing functionality relevant to the parsing of names, which include operators or identifiers. The parsing of names is mostly concerned with finding the longest valid name that is not a reserved name, such as a hard keyword or a special operator.

This contains lexing functionality relevant to the parsing of atomic symbols.

Symbols are characterised by their "unitness", that is, every parser inside returns Unit. This is because they all parse a specific known entity, and, as such, the result of the parse is irrelevant. These can be things such as reserved names, or small symbols like parentheses.

This type also contains a means of creating new symbols as well as implicit conversions to allow for Haskell's string literals (with OverloadedStringLiterals enabled) to serve as symbols within a parser.

This combinator parses a given soft keyword atomically: the keyword is only valid if it is not followed directly by a character which would make it a larger valid identifier.

Soft keywords are keywords that are only reserved within certain contexts. The apply combinator handles so-called hard keywords automatically, as the given string is checked to see what class of symbol it might belong to. However, soft keywords are not included in this set, as they are not always reserved in all situations. As such, when a soft keyword does need to be parsed, this combinator should be used to do it explicitly. Care should be taken to ensure that soft keywords take parsing priority over identifiers when they do occur.

This combinator parses a given soft operator atomically: the operator is only valid if it is not followed directly by a character which would make it a larger valid operator (reserved or otherwise).

Soft operators are operators that are only reserved within certain contexts. The apply combinator handles so-called hard operators automatically, as the given string is checked to see what class of symbol it might belong to. However, soft operators are not included in this set, as they are not always reserved in all situations. As such, when a soft operator does need to be parsed, this combinator should be used to do it explicitly.

This class defines a uniform interface for defining parsers for user-defined names (identifiers and operators), independent of how whitespace should be handled after the name.

The parsing of names is mostly concerned with finding the longest valid name that is not a reserved name, such as a hard keyword or a special operator.

Parse an identifier based on the given NameDesc predicates identifierStart and identifierLetter. The NameDesc is provided by mkNames.

Capable of handling unicode characters if the configuration permits. If hard keywords are specified by the configuration, this parser is not permitted to parse them.

Parse an identifier whose start satisfies the given predicate, and subseqeunt letters satisfy identifierLetter in the given NameDesc. The NameDesc is provided by mkNames.

Behaves as identifier, then ensures the first character matches the given predicate. Thus, identifier' can only refine the output of identifier; if identifier fails due to the first character, then so will identifier', even if this character passes the supplied predicate.

Capable of handling unicode characters if the configuration permits. If hard keywords are specified by the configuration, this parser is not permitted to parse them.

Parse a user-defined operator based on the given SymbolDesc predicates operatorStart and operatorLetter. The SymbolDesc is provided by mkNames.

Capable of handling unicode characters if the configuration permits. If hard operators are specified by the configuration, this parser is not permitted to parse them.

Parse a user-defined operator whose first character satisfies the given predicate, and subsequent characters satisfying operatorLetter in the given SymbolDesc. The SymbolDesc is provided by mkNames.

Behaves as userDefinedOperator, then ensures the first character matches the given predicate. Thus, userDefinedOperator' can only refine the output of userDefinedOperator; if userDefinedOperator fails due to the first character, then so will userDefinedOperator', even if this character passes the supplied predicate.

Capable of handling unicode characters if the configuration permits. If hard operators are specified by the configuration, this parser is not permitted to parse them.

A uniform interface for defining parsers for integer literals, independent of how whitespace should be handled after the literal or whether the literal should allow for negative numbers.

This is a collection of parsers concerned with handling signed integer literals.

Signed integer literals are an extension of unsigned integer literals which may be prefixed by a sign.

A collection of parsers concerned with handling unsigned (positive) integer literals.

Parse a single integer literal in decimal form (base 10).

Parse a single integer literal in hexadecimal form (base 16).

Parse a single integer literal in octal form (base 8).

Parse a single integer literal in binary form (base 2).

This parser behaves the same as decimal except it ensures that the resulting value is a valid 8-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as decimal except it ensures that the resulting value is a valid 16-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as decimal except it ensures that the resulting value is a valid 32-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as decimal except it ensures that the resulting value is a valid 64-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as hexadecimal except it ensures that the resulting value is a valid 8-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as hexadecimal except it ensures that the resulting value is a valid 16-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as hexadecimal except it ensures that the resulting value is a valid 32-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as hexadecimal except it ensures that the resulting value is a valid 64-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as octal except it ensures that the resulting value is a valid 8-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as octal except it ensures that the resulting value is a valid 16-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as octal except it ensures that the resulting value is a valid 32-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as octal except it ensures that the resulting value is a valid 64-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as binary except it ensures that the resulting value is a valid 8-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as binary except it ensures that the resulting value is a valid 16-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as binary except it ensures that the resulting value is a valid 32-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This parser behaves the same as binary except it ensures that the resulting value is a valid 64-bit number.

The resulting number will be converted to the given type a, which must be able to losslessly store the parsed value; this is enforced by the canHold constraint on the type. This accounts for unsignedness when necessary.

This type defines a uniform interface for defining parsers for textual literals, independent of how whitespace should be handled after the literal.

The type of these literals is determined by the parameter t.

Parses a single t-literal, which may contain any graphic ASCII character. These are characters with ordinals in range 0 to 127 inclusive.

It may also contain escape sequences, but only those which result in ASCII characters.

Parses a single t-literal, which may contain any unicode graphic character as defined by up to two UTF-16 codepoints.

It may also contain escape sequences.

Parses a single t-literal, which may contain any graphic extended ASCII character. These are characters with ordinals in range 0 to 255 inclusive.

It may also contain escape sequences, but only those which result in extended ASCII characters.

A collection of parsers concerned with handling single-line string literals.

String literals are generally described by the TextDesc fields:

• stringEnds
• graphicCharacter
• escapeSequences

A collection of parsers concerned with handling single-line string literals, without handling any escape sequences: this includes literal-end characters and the escape prefix (often " and \ respectively).

String literals are generally described by the TextDesc fields:

• stringEnds
• graphicCharacter
• escapeSequences

A collection of parsers concerned with handling multi-line string literals.

Multi-string literals are generally described by the TextDesc fields:

• multiStringEnds
• graphicCharacter
• escapeSequences

A collection of parsers concerned with handling multi-line string literals, without handling any escape sequences: this includes literal-end characters and the escape prefix (often " and \ respectively).

Multi-string literals are generally described by the TextDesc fields:

• multiStringEnds
• graphicCharacter
• escapeSequences

A collection of parsers concerned with handling character literals.

Charcter literals are generally described by the TextDesc fields:

• characterLiteralEnd
• graphicCharacter
• escapeSequences

This type is concerned with special treatment of whitespace.

For the vast majority of cases, the functionality within this object shouldn't be needed, as whitespace is consistently handled by lexeme and fully. However, for grammars where whitespace is significant (like indentation-sensitive languages), this object provides some more fine-grained control over how whitespace is consumed by the parsers within lexeme.

Skips zero or more comments.

The implementation of this combinator does not vary with whiteSpaceIsContextDependent. It will use the hide combinator as to not appear as a valid alternative in an error message: adding a comment is often legal, but not a useful solution for how to make the input syntactically valid.

Skips zero or more (insignificant) whitespace characters as well as comments.

The implementation of this parser depends on whether whiteSpaceIsContextDependent is true: when it is, this parser may change based on the use of the alter combinator.

This parser will always use the hide combinator as to not appear as a valid alternative in an error message: it's likely always the case whitespace can be added at any given time, but that doesn't make it a useful suggestion unless it is significant.

This combinator changes how lexemes parse whitespace for the duration of a given parser.

So long as whiteSpaceIsContextDependent is true, this combinator will be able to locally change the definition of whitespace during the given parser.

Examples

This parser initialises the whitespace used by the lexer when whiteSpaceIsContextDependent is true.

The whitespace is set to the implementation given by the lexical description. This parser must be used, by fully or otherwise, as the first thing the global parser does or an UnfilledRegisterException will occur.

See alter for how to change whitespace during a parse.