Arborist::Matcher
Inherits Arborist::DSL / Reference / Object
Constructors
Instance methods
The application of the skip rule is internally represented as a parameterized rule, such that the skip rule is specialized
for each expression that will follow. This approach made it possible implement the skip rule as:
parameterized_skip_rule[following_expr] <- !following_expr skip*
Eventually I concluded that implementing the skip rule as !{following expression} skip* was not what I wanted right now,
but this establishes the pattern of implementing parameterized rules, and I may decide to go back to implementing the skip
rule as !{following expression} skip*.
consumes a string of length count
returns nil if unable to consume count characters
returns the deepest/most-recent application of rule in the rule application stack
returns the leftmost/earliest/oldest/shallowest application of rule in the rule application stack that resulted in left recursion
returns the deepest/most-recent application of rule at position pos in the rule application stack
this method marks all ApplyCall calls on the call stack occurring more recent than oldest_application as unsafe to memoize
returns nil if the grammar rules don't match the full input string
if we're operating in Ohm mode, then the syntactic rule semantics apply. See https://github.com/harc/ohm/blob/master/doc/syntax-reference.md#syntactic-lexical for more information. From https://github.com/harc/ohm/blob/master/doc/syntax-reference.md#syntactic-lexical:
Syntactic vs. Lexical Rules
A syntactic rule is a rule whose name begins with an uppercase letter, and lexical rule is one whose name begins with a lowercase letter. The difference between lexical and syntactic rules is that syntactic rules implicitly skip whitespace characters.
For the purposes of a syntactic rule, a "whitespace character" is anything that matches its enclosing grammar's "space" rule. The default implementation of "space" matches ' ', '\t', '\n', '\r', and any other character that is considered whitespace in the ES5 spec.
per https://tratt.net/laurie/research/pubs/html/tratt__direct_left_recursive_parsing_expression_grammars/: growing is the data structure at the heart of the algorithm. A programming language-like type for it would be Map<Rule,Map<Int,Result>>. Since we statically know all the rules for a PEG, growing is statically initialised with an empty map for each rule at the beginning of the algorithm (line 1).
So, we want to initialize the growing map just prior to using it, since that will be the only point that we know for sure that all of the rules have been added to the matcher.
remove all seeds of any rule in the range [start_pos, end_pos]
remove all seeds of any rule in the range (start_pos, <end of input string>]
this removes all "descendant" seeds that were used to grow a larger seed, <larger_seed>, that encompases all the descendant seeds
returns an array of pairs of the form {pos, rule}, each summarizing an ApplyCall
todo: decide whether this should return the previous seed value