pattern.r3.combinators — com.github.pangloss/pattern 1.0.436

*descend* clj

*descent-depth* clj

*do-mutual-descent* clj

default clj

(default value)

Returns a rule that always returns the given value

descend clj

(descend expression)

(descend expression env)

If passing in an env, pass it as the first arg since within a rule handler, the expression part is likely to be a large hairy expression, and the env aspect will be easily lost at the end of it.

descend-all clj

(descend-all e*)

(descend-all e* env)

Descend each element in e*, threading the env and returning the result.

Like descend, if called without env it just returns the resulting expression and doesn't return the env, but if called with an env, it returns [result env].

An alternative strategy would be to merge the resulting envs, but that could require a custom merge strategy, so isn't provided as a built-in helper.

directed clj

(directed rule)

(directed opts raw-rule)

Recurs depth-first, but only into marked subexpressions.

Marking a subexpression looks like ?->x or ??->x (ie. marked with -> matcher mode), so a matcher like ?y would not get recurred into.

Does not iteratively descend into any expressions returned by matchers. To do any iterative descent, call descend within the handler on the subexpressions you wish to descend into.

You can also use opts to mark vars to descend by :name, :prefix or :abbr. Look at your rule metadata to see how the var names get that info extracted. For example to descend all rules that have an abbr of e, use

{:descend {:abbr #{'e}}}

Which would cause all descend the same as the following rule even if that rule had no -> markings:

(rule '[?->e ?->e0 ?->e123 ?no (?-> e*) ?->e:ok ?e-no ?e0:no])

You can provide an optional :fn-map via the opts argument, which is a map from additional mode symbols to functions that are applied to a captured match before it is passed to the rule handler. Only one function per symbol is allowed.

If a function is provided as the opts argument, it is treated as if you had passed in {:fn-map {'>- f}}, and if subexpressions are marked with >-, the expression, or the result of traversing into the expression if it is also marked with -> , will be passed to the function f. If no function is provided, [[identity]] is used. In this case, the matcher would look like one of ?>-, ??>-, ?>-> (note this is a shortened form), ?>-->, ??->>-, etc. The order of

• and -> does not matter. If any other symbols other than >- are provided in the :fn-map key of opts, the above description applies with the symbol you used.

You can provide a function on the :on-rule-meta opts key to make any arbitrary changes to rule metadata. The default is:

(fn on-rule-meta [rule-meta-before rule-meta-after]
  rule-meta-after)

The rule argument is typically a rule-list of simple rules, but in theory any type of rule combinator should work, however determining the resulting behavior may be tricky in some cases...

guard clj

(guard f rule)

in clj

(in x env)

Descend with an env without retaining the resulting env.

in-order clj

(in-order opts & rules)

Runs each of the rules in the list in a chain. If any rule succeeds, the subsequent rules are run with the new value. If a rule fails, the current value does not change and the next rule is run.

Each rule can itself be any rule-combinator.

opts:

:equiv? default: [[equiv?]]

iterated clj

(iterated the-rule)

(iterated equiv? the-rule)

Run the given rule combinator repeatedly until running the rule makes no further changes.

n-times clj

(n-times n rule)

Iteratively apply the rule n times.

The rule can be any rule-combinator.

on-mutual clj

(on-mutual initial-form name-rule-pairs)

(on-mutual equiv? initial-form name-rule-pairs)

The idea is that you can create a group of named rule sets where matchers are tagged with metadata and a matcher mode that tells this system to switch which rule set is applied for subexpressions of the given type. Effectively this lets you switch between expression types (or dialects?) when applying rules to an expression.

This is currently done in a somewhat simplistic way with bound variables because I'm not exactly sure how it should be structured but eventually it should be done without the need for extra global state like this.

on-subexpressions clj

(on-subexpressions the-rule)

(on-subexpressions equiv? the-rule)

Run the given rule combinator on all subexpressions depth-first.

prewalk-simplifier clj

(prewalk-simplifier the-rule)

(prewalk-simplifier walk the-rule)

(prewalk-simplifier equiv? walk the-rule)

Run the given rule combinator repeatedly, then continue on a prewalk descent of all subexpressions until running the rule makes no further changes at each level.

This is the same strategy that Clojure's macroexpansion uses.

You can provide a [[walk]] argument to use a custom variant of clojure.walk/walk.

rule-list clj

(rule-list & rules)

Try each of the rules in order top-down.

If any rule succeeds, return that result. If a rule matches but does not succeed, continues down the list.

Each rule can itself be any rule-combinator.

rule-list! clj

(rule-list! & rules)

Like rule-list, but throws an exception if no rule matches.

Each rule can itself be any rule-combinator.

rule-simplifier clj

(rule-simplifier & rules)

Run a list of rule combinators repeatedly on all subexpressions until running them makes no further changes.

DEPRECATED, use simplifier instead. This one does not let you set [[equiv?]].

rule-zipper clj

(rule-zipper rc)

Construct a zipper object for rule combinators to enable customization of rules, attaching custom metadata, etc.

simplifier clj

(simplifier the-rule)

(simplifier equiv? the-rule)

Run the given rule combinator repeatedly depth-first on all subexpressions until running the rule makes no further changes at each level.