Esrap

In addition to regular Packrat / Parsing Grammar / TDPL features Esrap supports

Esrap was originally written by Nikodemus Siivola. It is now developed and maintained by Jan Moringen.

Esrap is maintained in Git:

git clone -b stable git://github.com/scymtym/esrap.git

will get you a local copy (omit -b stable to get the latest development version).

http://github.com/scymtym/esrap

is the GitHub project page.

Esrap is licenced under an MIT-style licence.

For more on packrat parsing, see http://pdos.csail.mit.edu/~baford/packrat/thesis/ for Bryan Ford’s 2002 thesis: “Packrat Parsing: a Practical Linear Time Algorithm with Backtracking”.

For left recursion support in packrat parsers, see http://www.vpri.org/pdf/tr2007002_packrat.pdf for A. Warth et al’s 2008 paper: “Packrat Parsers Can Support Left Recursion”.

Table of Contents

1 Parsing Expressions

Parsing proceeds by matching text against parsing expressions. Matching has three components: success vs failure, consumption of input, and associated production.

Parsing expressions that fail never consume input. Parsing expressions that succeed may or may not consume input.

A parsing expressions can be:

Terminal

A terminal is a character or a string of length one, which succeeds and consumes a single character if that character matches the terminal.

Additionally, Esrap supports some pseudoterminals.

Nonterminal

Nonterminals are specified using symbols. A nonterminal symbol succeeds if the parsing expression associated with it succeeds, and consumes whatever the input that expression consumes.

The production of a nonterminal depends on the associated expression and an optional transformation rule.

Nonterminals are defined using defrule.

Note: Currently all rules share the same namespace, so you should not use symbols in the COMMON-LISP package or other shared packages to name your rules unless you are certain there are no other Esrap using components in your Lisp image. In a future version of Esrap grammar objects will be introduced to allow multiple definitions of nonterminals. Symbols in the COMMON-LISP package are specifically reserved for use by Esrap.

Sequence

(and subexpression ...)

A sequence succeeds if all subexpressions succeed, and consumes all input consumed by the subexpressions. A sequence produces the productions of its subexpressions as a list.

Ordered Choice

(or subexpression ...)

An ordered choice succeeds if any of the subexpressions succeeds, and consumes all the input consumed by the successful subexpression. An ordered choice produces whatever the successful subexpression produces.

Subexpressions are checked strictly in the specified order, and once a subexpression succeeds no further ones will be tried.

Negation

(not subexpression)

A negation succeeds if the subexpression fails, and consumes one character of input. A negation produces the character it consumes.

Greedy Repetition

(* subexpresssion)

A greedy repetition always succeeds, consuming all input consumed by applying subexpression repeatedly as long as it succeeds.

A greedy repetition produces the productions of the subexpression as a list.

Greedy Positive Repetition

(+ subexpresssion)

A greedy repetition succeeds if subexpression succeeds at least once, and consumes all input consumed by applying subexpression repeatedly as long as it succeeds. A greedy positive repetition produces the productions of the subexpression as a list.

Optional

(? subexpression)

Optionals always succeed, and consume whatever input the subexpression consumes. An optional produces whatever the subexpression produces, or nil if the subexpression does not succeed.

Followed-By Predicate

(& subexpression)

A followed-by predicate succeeds if the subexpression succeeds, and consumes no input. A followed-by predicate produces whatever the subexpression produces.

Not-Followed-By Predicate

(! subexpression)

A not-followed-by predicate succeeds if the subexpression does not succeed, and consumes no input. A not-followed-by predicate produces nil.

Lookbehind

(< amount subexpression)

A lookbehind succeeds if subexpression succeeds at the input position reached by moving backward amount, a positive integer, characters from the current position and consumes no input. A lookbehind produces whatever subexpression produces.

Lookahead

(> amount subexpression)

A lookahead succeeds if subexpression succeeds at the input position reached by moving forward amount, a positive integer, characters from the current position and consumes no input. A lookahead produces whatever subexpression produces.

Semantic Predicates

(predicate-name subexpression)

The predicate-name is a symbol naming a global function. A semantic predicate succeeds if subexpression succeeds and the named function returns true for the production of the subexpression. A semantic predicate produces whatever the subexpression produces.

Note: semantic predicates may change in the future to produce whatever the predicate function returns.

Functions as Terminals

(function function-name)

function-name is a symbol naming a global function. function-name’s lambda-list has to be compatible to (text position end) where text is the whole input and position and end indicate the maximal subsequence function-name should attempt to parse.

A function terminal succeeds if either

  1. function-name returns T as its third value.
  2. function-name returns nil as its third value (or returns only two values) and nil as its second value. This indicates that the entire remaining input has been consumed.
  3. function-name returns nil as its third value (or returns only two values) and an integer > position as its second value indicating the position up to which text has been consumed.
  4. function-name returns a value of type successful-parse as its first value.

When a function terminal succeeds, the first return value is an arbitrary production.

A function terminal fails if either

  1. function-name returns two values: an ignored value and position. Returning position indicates that no progress has been made.
  2. function-name returns three values: an ignored value, nil or an integer >= position and a string or a condition explaining the failure. In this case, when the second value is not nil, it indicates the exact position of the failure.
  3. function-name returns a value of type error-result as its first value.

Note that rules which use functions as terminals do not automatically pick up redefinitions of the used functions. For that to happen, the rules have to be redefined as well.

See example-function-terminals.lisp for examples.

Left Recursion

One aspect of designing Esrap rules is left recursion. A direct left recursive rule is of the form

(defrule left-recursion (or (and left-recursion STUFF) ALTERNATIVES))

The simplest indirect left recursive rule is of the form

(defrule left-recursion.1 left-recursion.2)
(defrule left-recursion.2 (or (and left-recursion.1 STUFF) ALTERNATIVES))

Esrap can handle both kinds of left recursive rules, but the linear-time guarantee generally no longer holds in such cases. The special variable *on-left-recursion* can be set to either nil or :error to control Esrap’s behavior with respect to allowing left recursion.

See example-left-recursion.lisp for examples.

2 Dictionary

2.1 Primary Interface

Macro: defrule symbol expression &body options

Define symbol as a nonterminal, using expression as associated the parsing expression.

Multiple options specifying transforms are composed in the order of appearance:


  (:text t)
  (:function parse-integer)
  =>
  (alexandria:compose #'parse-integer #'text)

Following options can be specified:

Function: parse expression text &key start end junk-allowed raw

Parses text using expression from start to end.

Incomplete parses, that is not consuming the entirety of text, are allowed only if junk-allowed is true.

Returns three values:

1) A production, if the parse succeeded, nil otherwise. 2) The position up to which text has been consumed or nil if the entirety of text has been consumed. 3) If the parse succeeded, even if it did not consume any input, t is returned as a third value.

The third return value is necessary to distinguish successful and failed parses for cases like


  (parse '(! #\a) "a" :junk-allowed t)
  (parse '(! #\a) "b" :junk-allowed t)

in which the first two return values cannot indicate failures.

raw controls whether the parse result is interpreted and translated into the return values described above. If raw is true, a parse result of type result or error-result is returned as a single value.

Note that the combination of arguments :junk-allowed t :raw t does not make sense since the junk-allowed parameter is used when parse results are interpreted and translated into return values which does not happen when :raw t.

Function: describe-grammar symbol &optional stream

Prints the grammar tree rooted at nonterminal symbol to stream for human inspection.

2.2 Utilities

Function: text &rest arguments

Arguments must be strings, or lists whose leaves are strings. Catenates all the strings in arguments into a single string.

2.3 Introspection and Intercession

Function: add-rule symbol rule

Associates rule with the nonterminal symbol. Signals an error if the rule is already associated with a nonterminal. If the symbol is already associated with a rule, the old rule is removed first.

Function: change-rule symbol expression

Modifies the nonterminal symbol to use expression instead. Temporarily removes the rule while it is being modified.

Function: find-rule symbol

Returns rule designated by symbol, if any. Symbol must be a nonterminal symbol.

Function: remove-rule symbol &key force

Makes the nonterminal symbol undefined. If the nonterminal is defined an already referred to by other rules, an error is signalled unless :force is true.

Function: rule-dependencies rule

Returns the dependencies of the rule: primary value is a list of defined nonterminal symbols, and secondary value is a list of undefined nonterminal symbols.

Function: rule-expression rule

Return the parsing expression associated with the rule.

Function: (setf rule-expression) expression rule

Modify rule to use expression as the parsing expression. The rule must be detached beforehand.

Generic Function: rule-symbol object

Returns the nonterminal associated with the rule, or nil if the rule is not attached to any nonterminal.

Method: rule-symbol (rule rule)

automatically generated reader method

Function: trace-rule symbol &key recursive break condition

Turn on tracing of nonterminal symbol. If recursive is true, turn on tracing for the whole grammar rooted at symbol.

If break is true, break is entered when the rule is invoked.

If supplied, condition has to be a function whose lambda-list is compatible to (symbol text position end). This function is called to determine whether trace actions should be executed for the traced rule.

symbol is the name of the rule being executed.

text is the whole text being parsed.

position is the position within text at which the rule is executed.

end is the end position of the portion of text being parsed.

Function: untrace-rule symbol &key recursive break condition

Turn off tracing of nonterminal symbol.

If recursive is true, untraces the whole grammar rooted at symbol.

break and condition are ignored, and are provided only for symmetry with trace-rule.

Function: expression-start-terminals expression &key when-rule-error-report

Return a list of terminals or tree of expressions with which a text parsable by expression can start.

A tree instead of a list is returned when expression contains semantic predicates, not or !. Elements in the returned list or tree are

The (outermost) list is sorted likes this:

1. string terminals 2. character terminals 3. the character wildcard terminal 4. semantic predicates 5. everything else

If supplied, when-rule-error-report restricts processing of nonterminals to rules whose :error-report option is compatible with the value of when-rule-error-report.

Function: describe-terminal terminal &optional stream

Print a description of terminal onto stream.

In additional to actual terminals, terminal can be of the forms


     (PREDICATE-NAME TERMINALS)
     ({not,!} TERMINALS)
     ({<,>} OFFSET TERMINALS)

   (i.e. as produced by EXPRESSION-START-TERMINALS).

2.4 Error Conditions

Variable: *on-left-recursion*

This special variable controls Esrap’s behavior with respect to allowing left recursion.

When :error, parse signals a left-recursion error when it encounters a left recursive rule. Otherwise the rule is processed.

Note: when processing left recursive rules, linear-time guarantees generally no longer hold.

Generic Function: esrap-error-position condition

Return the input position at which the parse failure represented by condition occurred.

Generic Function: esrap-parse-error-result condition

Return the result associated to the parse error represented by condition.

Generic Function: esrap-parse-error-context condition

Return the context result associated to the parse error represented by condition.

Condition: esrap-error

Class precedence list: esrap-error, parse-error, error, serious-condition, condition, t

Signaled when an Esrap parse fails. Use esrap-error-text to obtain the string that was being parsed, and esrap-error-position the position at which the error occurred.

Condition: left-recursion

Class precedence list: left-recursion, esrap-error, parse-error, error, serious-condition, condition, t

May be signaled when left recursion is detected during Esrap parsing.

left-recursion-nonterminal names the symbol for which left recursion was detected, and left-recursion-path lists nonterminals of which the left recursion cycle consists.

Note: This error is only signaled if *on-left-recursion* is bound to :error.

Condition: esrap-parse-error

Class precedence list: esrap-parse-error, esrap-error, parse-error, error, serious-condition, condition, t

This error is signaled when a parse attempt fails in a way that .

Condition: undefined-rule-error

Class precedence list: undefined-rule-error, undefined-rule, error, serious-condition, condition, t

Signaled when an undefined rule is encountered.