Lines Matching refs:rules
69 rules, how they provide a general mechanism for computation, and how
74 terms) and how rules are written.
82 insight into how an unordered collection of rewrite rules are
103 then applying *rules* to "rewrite" the terms. This rewrite process
105 example until no more rules are applicable or until the term reaches a
133 one. This is because the abstraction allows for multiple rules to be
142 not present in hand-written pattern-matching code: the specific rules
146 the related rules at once. Said another way: hand-written code tends
152 lowering rules, considering each in isolation.
217 This will become much more useful once we have rewrite rules to
229 The heart of a term-rewriting system is in the set of *rules* that
232 rules. Each rule may or may not apply; if it applies, then it can be
234 rules until some criteria are met.
238 right-hand nomenclature comes from a common way of writing rules as:
282 different rules on different "shapes" of the tree of constructors in
286 typically allows *overlapping* rules. This means that more than one
287 pattern might match on the input. For example, the two rules:
318 under a set of rewrite rules, from which a heuristic
347 Now that we can specify rewrites via a list of rules, we can study how
353 For a simple example, consider the following rules:
361 This set of rules will rewrite `(A (B (D 42)))` to `(C (D 42))`, then
362 to `(E 42)` (via the first and second rules respectively).
366 rules allows us to *factor* a "program" of term-rewriting rules in the
382 then defining additional rules to rewrite further -- when it helps to
383 factor common behavior out of multiple rules, or aids in conceptual
386 [^5]: In fact, ISLE actually compiles rules for different top-level
388 separate Rust functions, so factoring rules to use intermediate
393 rules](https://en.wikipedia.org/wiki/Lambda_calculus#Reduction)
409 In other words, terms are just values, and rules specify alternative
410 ways to compute the same values. We might have rewrite rules that
424 These rules specify three ways to convert an IR `iadd` operator into
428 rules are applicable, then any sequence of rewrites that ends in a
429 terminating state (a state with no further-applicable rules) should be
441 could choose arbitrary (random) orders of lowering rules to
446 shown that are lowering rules are "internally consistent",
450 but takes mutations implicitly from the pool of rules rather
474 allows ISLE rules to call into Rust in both their patterns and
482 ISLE allows the user to specify rewrite rules, with a syntax similar
536 When multiple rules are applicable to rewrite a particular term, ISLE
547 lower priority. The default priority for all rules if not otherwise
550 Note that the system allows multiple applicable rules to exist with
555 the core language semantics and execution of rules with different
557 correct rules. However, the tie-breaking heuristic is *not* part of
559 rules whose correctness depends on one rule overriding another
630 than what the user implicitly defines with the given rules. What does
634 The types come into play when we define *rules*: one term of type `T`
669 The typing rules for patterns in ISLE are:
673 constant, etc.). This is because compilation and dispatch into rules
723 for example, a set of ISLE rules cannot be used to translate a term of
801 ISLE. Any term `A` that has one or more `(rule (A ...) RHS)` rules in
803 constructor can be invoked from the right-hand side of other rules.
1054 on rules, such that their only purpose is to allow a rule to match,
1081 context, it is possible that certain recursive rules could be exploited to
1087 recursive references in a term's rules, declare the term with the `rec`
1109 1. Every term with rules in ISLE becomes a single Rust function. The
1118 of rules, we do so by calling a function (the "constructor body");
1123 of several rules to apply, and execute code to build the right-hand
1133 factoring code into many sub-rules (subject only to function-call
1136 5. Backtracking -- attempting to match rules, and backing up to follow
1177 further rewriting rules results in a Rust function call to the body of
1178 the "internal constructor" built from these rules; the term thus never
1203 can be fallible because they are implemented by a list of rules whose
1381 understanding of how the DSL compiler weaves rules together into Rust
1391 a list of rules into a scheme to attempt to match rules in some order,
1392 possibly sharing match operations between similar rules to reduce
1417 existing tree as we process rules) and each rule's right-hand side