Lines Matching refs:pattern

17 instruction lowering pattern is a specification that a certain
55 apply to any sort of backtracking pattern-matching problem, and will
123 highly applicable to *pattern-matching* problems: for example,
142 not present in hand-written pattern-matching code: the specific rules
236 A rule consists of two parts: the left-hand side (LHS), or *pattern*,
251 Each left-hand side is written in a pattern language that commonly has
267 These pattern-matching operators can be combined, so we could write,
268 for example, `(A (B x _) z)`. This pattern would match the term `(A (B
271 A pattern can properly be seen as a partial function from input term
287 pattern might match on the input. For example, the two rules:
324 Given a rule whose pattern has matched, we now need to compute the
329 pattern.
341 there are no wildcards) because a pattern is matching on a range of
380 pattern-matching (such as instruction selectors), the user should not
387       pattern terms (`(A ...)` and `(C ...)` in the example) into
487       ;; left-hand side (pattern): if the input matches this ...
493 The pattern (left-hand side) is made up of the following match
659 detail how they are used to verify that the pattern and rewrite
663 propagates type information through the pattern, resulting in a "type
671 * At the root of the pattern, we require that a *constructor* pattern
677 * At each part of the pattern except the root, there is an "expected
679   this matches the actual type of the pattern.
681 * A constructor pattern `(C x y z)`, given a constructor `(decl C (T1
685 * A variable capture pattern `x` is compatible with any expected type
698 If we are able to typecheck the pattern, we have a type environment
706   top-level constructor in the pattern. (In other words, a term can
750 In other words, a conventional instruction selection pattern engine
783 left-hand (pattern) or right-hand (expression) side of a rule.
807 Extractor behavior on a term allows it to be used in a pattern in the
817 memory, and can discover that a pattern `(A x y)` matches a term `A`
820 wherever a pattern-match is attempted, and can return "success" with
844 fail, just as any other part of a pattern-match can.
861 which will, for example, expand a pattern `(A (subterm ...) _)` into
922 pattern where just a variable binding occurs, even if the variable is
950 pattern-matching steps, and can be used to perform additional tests
981 The matching proceeds as follows: the main pattern (`LHS_PATTERN`)
989 to the next rule as if the main pattern had failed to match. (More on
991 succeeds, we match the associated pattern (`PAT2` or `PAT3` above)
994 available. Variables bound in the main pattern are available for all
997 (from the main pattern and if-let clauses) are available in the
1055 and not to perform any destructuring with a sub-pattern. For example,
1112    because pattern coverage can be incomplete).
1207 (see below) instead: only pattern left-hand sides are meant to be
1214 with the embedding application. When the generated pattern-matching
1216 an extractor pattern defined as an external extractor, it simply calls
1285 needed, in either a pattern (LHS) or an expression (RHS). These
1316 partial: if no rule's pattern matches, then the constructor
1504 <rule> ::= [ <ident> ] [ <prio> ] <pattern> <stmt>* <expr>
1513 <pattern> ::= <int>
1518             | <ident> "@" <pattern>
1519             | "(" "and" <pattern>* ")"
1520             | "(" <ident> <pattern>* ")"
1522 <stmt> ::= "(" "if-let" <pattern> <expr> ")"
1534 <extractor> ::= "(" <ident> <ident>* ")" <pattern>