Packages

  • package root

    This is the documentation for Parsley.

    This is the documentation for Parsley.

    Package structure

    The parsley package contains the Parsley class, as well as the Result, Success, and Failure types. In addition to these, it also contains the following packages and "modules" (a module is defined as being an object which mocks a package):

    • parsley.Parsley contains the bulk of the core "function-style" combinators.
    • parsley.combinator contains many helpful combinators that simplify some common parser patterns.
    • parsley.character contains the combinators needed to read characters and strings, as well as combinators to match specific sub-sets of characters.
    • parsley.debug contains debugging combinators, helpful for identifying faults in parsers.
    • parsley.expr contains the following sub modules:
      • parsley.expr.chain contains combinators used in expression parsing
      • parsley.expr.precedence is a builder for expression parsers built on a precedence table.
      • parsley.expr.infix contains combinators used in expression parsing, but with more permissive types than their equivalents in chain.
      • parsley.expr.mixed contains combinators that can be used for expression parsing, but where different fixities may be mixed on the same level: this is rare in practice.
    • parsley.syntax contains several implicits to add syntactic sugar to the combinators. These are sub-categorised into the following sub modules:
      • parsley.syntax.character contains implicits to allow you to use character and string literals as parsers.
      • parsley.syntax.lift enables postfix application of the lift combinator onto a function (or value).
      • parsley.syntax.zipped enables boths a reversed form of lift where the function appears on the right and is applied on a tuple (useful when type inference has failed) as well as a .zipped method for building tuples out of several combinators.
      • parsley.syntax.extension contains syntactic sugar combinators exposed as implicit classes.
    • parsley.errors contains modules to deal with error messages, their refinement and generation.
    • parsley.lift contains functions which lift functions that work on regular types to those which now combine the results of parsers returning those same types. these are ubiquitous.
    • parsley.ap contains functions which allow for the application of a parser returning a function to several parsers returning each of the argument types.
    • parsley.state contains combinators that interact with the context-sensitive functionality in the form of state.
    • parsley.token contains the Lexer class that provides a host of helpful lexing combinators when provided with the description of a language.
    • parsley.position contains parsers for extracting position information.
    • parsley.generic contains some basic implementations of the Parser Bridge pattern (see Design Patterns for Parser Combinators in Scala, or the parsley wiki): these can be used before more specialised generic bridge traits can be constructed.
    Definition Classes
    root
  • package parsley
    Definition Classes
    root
  • package token

    This package provides a wealth of functionality for performing common lexing tasks.

    This package provides a wealth of functionality for performing common lexing tasks.

    It is organised as follows:

    • the main parsing functionality is accessed via Lexer, which provides implementations for the combinators found in the sub-packages given a LexicalDesc.
    • the descriptions sub-package is how a lexical structure can be described, providing the configuration that alters the behaviour of the parsers produced by the Lexer.
    • the other sub-packages contain the high-level interfaces that the Lexer exposes, which can be used to pass whitespace-aware and non-whitespace-aware combinators around in a uniform way.
    • the predicate module contains functionality to help define boolean predicates on characters or unicode codepoints.
    Definition Classes
    parsley
  • final class Lexer extends AnyRef

    This class provides a large selection of functionality concerned with lexing.

    This class provides a large selection of functionality concerned with lexing.

    This class provides lexing functionality to parsley, however it is guaranteed that nothing in this class is not implementable purely using parsley's pre-existing functionality. These are regular parsers, but constructed in such a way that they create a clear and logical separation from the rest of the parser.

    The class is broken up into several internal "modules" that group together similar kinds of functionality. Importantly, the lexemes and nonlexemes objects separate the underlying token implementations based on whether or not they consume whitespace or not. Functionality is broadly duplicated across both of these modules: lexemes should be used by a wider parser, to ensure whitespace is handled uniformly; and nonlexemes should be used to define further composite tokens or in special circumstances where whitespace should not be consumed.

    It is possible that some of the implementations of parsers found within this class may have been hand-optimised for performance: care will have been taken to ensure these implementations precisely match the semantics of the originals.

    Definition Classes
    token
  • lexeme
  • nonlexeme
  • space
o

parsley.token.Lexer

nonlexeme

object nonlexeme

This object is concerned with non-lexemes: these are tokens that do not give any special treatment to whitespace.

Whilst the functionality in lexeme is strongly recommended for wider use in a parser, the functionality here may be useful for more specialised use-cases. In particular, these may for the building blocks for more complex tokens (where whitespace is not allowed between them, say), in which case these compound tokens can be turned into lexemes manually. For example, the lexer does not have configuration for trailing specifiers on numeric literals (like, 1024L in Scala, say): the desired numeric literal parser could be extended with this functionality before whitespace is consumed by using the variant found in this object.

Alternatively, these tokens can be used for lexical extraction, which can be performed by the ErrorBuilder typeclass: this can be used to try and extract tokens from the input stream when an error happens, to provide a more informative error. In this case, it is desirable to not consume whitespace after the token to keep the error tight and precise.

Source
Lexer.scala
Since

4.0.0

Linear Supertypes
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. nonlexeme
  2. AnyRef
  3. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. All

Value Members

  1. final def !=(arg0: Any): Boolean
    Definition Classes
    AnyRef → Any
  2. final def ##(): Int
    Definition Classes
    AnyRef → Any
  3. final def ==(arg0: Any): Boolean
    Definition Classes
    AnyRef → Any
  4. final def asInstanceOf[T0]: T0
    Definition Classes
    Any
  5. def character: CharacterParsers

    This is a collection of parsers concerned with handling character literals.

    This is a collection of parsers concerned with handling character literals.

    Character literals are described generally as follows:

    • desc.textDesc.characterLiteralEnd: the character that starts and ends the literal (for example in many languages this is ')
    • desc.textDesc.graphicCharacter: describes the legal characters that may appear in the literal directly. Usually, this excludes control characters and newlines, but permits most other things. Escape sequences can represent non-graphic characters
    • desc.textDesc.escapeSequences: describes the legal escape sequences that that can appear in a character literal (for example \n or )

    Aside from the generic configuration, characters can be parsed in accordance with varying levels of unicode support, from ASCII-only to full UTF-16 characters. Parsers for each of four different vareties are exposed by this object.

    Since

    4.5.0

  6. def clone(): AnyRef
    Attributes
    protected[lang]
    Definition Classes
    AnyRef
    Annotations
    @throws( ... ) @native()
  7. final def eq(arg0: AnyRef): Boolean
    Definition Classes
    AnyRef
  8. def equals(arg0: Any): Boolean
    Definition Classes
    AnyRef → Any
  9. def finalize(): Unit
    Attributes
    protected[lang]
    Definition Classes
    AnyRef
    Annotations
    @throws( classOf[java.lang.Throwable] )
  10. def floating: RealParsers

    This is a collection of parsers concerned with handling signed real numbers (like floats and doubles).

    This is a collection of parsers concerned with handling signed real numbers (like floats and doubles).

    These literals consist of a (possibly optional) integer prefix, with at least one of a fractional component (with .) or an exponential component.

    Real numbers are an extension of signed integers with the following additional configuration:

    • desc.numericDesc.leadingDotAllowed: determines whether a literal like .0 would be considered legal
    • desc.numericDesc.trailingDotAllowed: determines whether a literal like 0. would be considered legal
    • desc.numericDesc.realNumbersCanBe{Hexadecimal/Octal/Binary}: these flags control what kind of literals can appear within the number parser. Each type of literal may still be individually parsed with its corresponding parser, regardless of the value of the flag
    • desc.numericDesc.{decimal/hexadecimal/octal/binary}ExponentDesc: describes how the exponential syntax works for each kind of base. If the syntax is legal, then this describes: which characters start it (classically, this would be e or E for decimals); whether or not it is compulsory for the literal (in Java and C, hexadecimal floats are only valid when they have an exponent attached); and whether or not a + sign is mandatory, optional, or illegal for positive exponents

    Additional to the parsing of decimal, hexadecimal, octal, and binary floating literals, each parser can be given a precision of IEEE 754 float or double. This can either be achieved by rounding to the nearest representable value, or by ensuring that the literal must be precisely representable as one of these numbers (which is defined as being one of binary, decimal or exact float and double values as described by Java)

    Since

    4.5.0

    Note

    alias for real

    See also

    natural and integer for a full description of the configuration for the start of a real number

  11. final def getClass(): Class[_]
    Definition Classes
    AnyRef → Any
    Annotations
    @native()
  12. def hashCode(): Int
    Definition Classes
    AnyRef → Any
    Annotations
    @native()
  13. def integer: IntegerParsers

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

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

    Signed integer literals are an extension of unsigned integer literals with the following extra configuration:

    • desc.numericDesc.positiveSign: describes whether or not literals are allowed to omit + for positive literals, must write a +, or can never write a +.
    Since

    4.5.0

    See also

    natural for a full description of integer configuration

  14. final def isInstanceOf[T0]: Boolean
    Definition Classes
    Any
  15. def multiString: StringParsers

    This is a collection of parsers concerned with handling multi-line string literals.

    This is a collection of parsers concerned with handling multi-line string literals.

    String literals are described generally as follows:

    • desc.textDesc.multiStringEnds: the sequence of characters that can begin or end a multi-line string literal. Regardless of which of these is used for a specific literal, the end of the literal must use the same sequence
    • desc.textDesc.graphicCharacter: describes the legal characters that may appear in the literal directly. Usually, this excludes control characters and newlines, but permits most other things. Escape sequences can represent non-graphic characters for non-raw strings
    • desc.textDesc.escapeSequences: describes the legal escape sequences that that can appear in a string literal (for example \n or )
    Since

    4.5.0

  16. val names: Names

    This object contains lexing functionality relevant to the parsing of names, which include operators or identifiers.

    This object 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.

    Since

    4.0.0

  17. def natural: IntegerParsers

    This is a collection of parsers concerned with handling unsigned (positive) integer literals.

    This is a collection of parsers concerned with handling unsigned (positive) integer literals.

    Natural numbers are described generally as follows:

    • desc.numericDesc.literalBreakChar: determines whether or not it is legal to "break up" the digits within a literal, for example: is 1_000_000 allowed? If this is legal, describes what the break character is, and whether it can appear after a hexadecimal/octal/binary prefix
    • desc.numericDesc.leadingZerosAllowed: determines whether or not it is possible to add extraneous zero digits onto the front of a number or not. In some languages, like C, this is disallowed, as numbers starting with 0 are octal numbers.
    • desc.numericDesc.integerNumbersCanBe{Hexadecimal/Octal/Binary}: these flags control what kind of literals can appear within the number parser. Each type of literal can be individually parsed with its corresponding parser, regardless of the value of the flag
    • desc.numericDesc.{hexadecimal/octal/binary}Leads: controls what character must follow a 0 when starting a number to change it from decimal into another base. This set may be empty, in which case the literal is described purely with leading zero (C style octals would set octalLeads to Set.empty)

    Additional to the parsing of decimal, hexadecimal, octal, and binary literals, each parser can be given a bit-width from 8- to 64-bit: this will check the parsed literal to ensure it is a legal literal of that size.

    Since

    4.5.0

  18. final def ne(arg0: AnyRef): Boolean
    Definition Classes
    AnyRef
  19. final def notify(): Unit
    Definition Classes
    AnyRef
    Annotations
    @native()
  20. final def notifyAll(): Unit
    Definition Classes
    AnyRef
    Annotations
    @native()
  21. def rawMultiString: StringParsers

    This is a collection of parsers concerned with handling multi-line string literals.

    This is a collection of parsers concerned with handling multi-line string literals.

    String literals are described generally as follows:

    • desc.textDesc.multiStringEnds: the sequence of characters that can begin or end a multi-line string literal. Regardless of which of these is used for a specific literal, the end of the literal must use the same sequence
    • desc.textDesc.graphicCharacter: describes the legal characters that may appear in the literal directly. Usually, this excludes control characters and newlines, but permits most other things. Escape sequences can represent non-graphic characters for non-raw strings
    • desc.textDesc.escapeSequences: describes the legal escape sequences that that can appear in a string literal (for example \n or )
    Since

    4.5.0

    Note

    this will be parsed without handling any escape sequences, this includes literal-end characters and the escape prefix (often " and \ respectively)

  22. def rawString: StringParsers

    This is a collection of parsers concerned with handling single-line string literals.

    This is a collection of parsers concerned with handling single-line string literals.

    String literals are described generally as follows:

    • desc.textDesc.stringEnds: the sequence of characters that can begin or end a string literal. Regardless of which of these is used for a specific literal, the end of the literal must use the same sequence
    • desc.textDesc.graphicCharacter: describes the legal characters that may appear in the literal directly. Usually, this excludes control characters and newlines, but permits most other things. Escape sequences can represent non-graphic characters for non-raw strings
    • desc.textDesc.escapeSequences: describes the legal escape sequences that that can appear in a string literal (for example \n or )
    Since

    4.5.0

    Note

    this will be parsed without handling any escape sequences, this includes literal-end characters and the escape prefix (often " and \ respectively)

  23. def real: RealParsers

    This is a collection of parsers concerned with handling signed real numbers (like floats and doubles).

    This is a collection of parsers concerned with handling signed real numbers (like floats and doubles).

    These literals consist of a (possibly optional) integer prefix, with at least one of a fractional component (with .) or an exponential component.

    Real numbers are an extension of signed integers with the following additional configuration:

    • desc.numericDesc.leadingDotAllowed: determines whether a literal like .0 would be considered legal
    • desc.numericDesc.trailingDotAllowed: determines whether a literal like 0. would be considered legal
    • desc.numericDesc.realNumbersCanBe{Hexadecimal/Octal/Binary}: these flags control what kind of literals can appear within the number parser. Each type of literal may still be individually parsed with its corresponding parser, regardless of the value of the flag
    • desc.numericDesc.{decimal/hexadecimal/octal/binary}ExponentDesc: describes how the exponential syntax works for each kind of base. If the syntax is legal, then this describes: which characters start it (classically, this would be e or E for decimals); whether or not it is compulsory for the literal (in Java and C, hexadecimal floats are only valid when they have an exponent attached); and whether or not a + sign is mandatory, optional, or illegal for positive exponents

    Additional to the parsing of decimal, hexadecimal, octal, and binary floating literals, each parser can be given a precision of IEEE 754 float or double. This can either be achieved by rounding to the nearest representable value, or by ensuring that the literal must be precisely representable as one of these numbers (which is defined as being one of binary, decimal or exact float and double values as described by Java)

    Since

    4.5.0

    See also

    natural and integer for a full description of the configuration for the start of a real number

  24. def signed: IntegerParsers

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

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

    Signed integer literals are an extension of unsigned integer literals with the following extra configuration:

    • desc.numericDesc.positiveSign: describes whether or not literals are allowed to omit + for positive literals, must write a +, or can never write a +.
    Since

    4.5.0

    Note

    alias for integer

    See also

    unsigned for a full description of signed integer configuration

  25. def signedCombined: CombinedParsers

    This is a collection of parsers concerned with handling numeric literals that may either be signed integers or signed reals.

    This is a collection of parsers concerned with handling numeric literals that may either be signed integers or signed reals.

    There is no additional configuration offered over that found in integer or real.

    the bit-bounds and precision of the integer or real parts of the result can be specified in any pairing.

    Since

    4.5.0

  26. def string: StringParsers

    This is a collection of parsers concerned with handling single-line string literals.

    This is a collection of parsers concerned with handling single-line string literals.

    String literals are described generally as follows:

    • desc.textDesc.stringEnds: the sequence of characters that can begin or end a string literal. Regardless of which of these is used for a specific literal, the end of the literal must use the same sequence
    • desc.textDesc.graphicCharacter: describes the legal characters that may appear in the literal directly. Usually, this excludes control characters and newlines, but permits most other things. Escape sequences can represent non-graphic characters for non-raw strings
    • desc.textDesc.escapeSequences: describes the legal escape sequences that that can appear in a string literal (for example \n or )
    Since

    4.5.0

  27. val symbol: Symbol

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

    This object 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 object also contains a means of creating new symbols as well as implicit conversions to allow for Scala's string literals to serve as symbols within a parser.

    Since

    4.0.0

  28. final def synchronized[T0](arg0: ⇒ T0): T0
    Definition Classes
    AnyRef
  29. def toString(): String
    Definition Classes
    AnyRef → Any
  30. def unsigned: IntegerParsers

    This is a collection of parsers concerned with handling unsigned (positive) integer literals.

    This is a collection of parsers concerned with handling unsigned (positive) integer literals.

    Natural numbers are described generally as follows:

    • desc.numericDesc.literalBreakChar: determines whether or not it is legal to "break up" the digits within a literal, for example: is 1_000_000 allowed? If this is legal, describes what the break character is, and whether it can appear after a hexadecimal/octal/binary prefix
    • desc.numericDesc.leadingZerosAllowed: determines whether or not it is possible to add extraneous zero digits onto the front of a number or not. In some languages, like C, this is disallowed, as numbers starting with 0 are octal numbers.
    • desc.numericDesc.integerNumbersCanBe{Hexadecimal/Octal/Binary}: these flags control what kind of literals can appear within the number parser. Each type of literal can be individually parsed with its corresponding parser, regardless of the value of the flag
    • desc.numericDesc.{hexadecimal/octal/binary}Leads: controls what character must follow a 0 when starting a number to change it from decimal into another base. This set may be empty, in which case the literal is described purely with leading zero (C style octals would set octalLeads to Set.empty)

    Additional to the parsing of decimal, hexadecimal, octal, and binary literals, each parser can be given a bit-width from 8- to 64-bit: this will check the parsed literal to ensure it is a legal literal of that size.

    Since

    4.5.0

    Note

    alias for natural.

  31. def unsignedCombined: CombinedParsers

    This is a collection of parsers concerned with handling numeric literals that may either be unsigned integers or unsigned reals.

    This is a collection of parsers concerned with handling numeric literals that may either be unsigned integers or unsigned reals.

    There is no additional configuration offered over that found in natural or real.

    the bit-bounds and precision of the integer or real parts of the result can be specified in any pairing.

    Since

    4.5.0

  32. final def wait(): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws( ... )
  33. final def wait(arg0: Long, arg1: Int): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws( ... )
  34. final def wait(arg0: Long): Unit
    Definition Classes
    AnyRef
    Annotations
    @throws( ... ) @native()

Inherited from AnyRef

Inherited from Any

Ungrouped