FS22k Transducer User Manual

Transcription

1 FS22k Transducer User Manual Rebecca Nesson September 1, Meta-Notation Below, we use BNF notation to define the syntax of the rewriting system. In the BNF metanotation, all terminals are given in a computery font, like this. Vertical bars specify alternatives. An ellipsis following two constituents specifies zero or more occurrences of the first separated by occurrences of the second. For instance, the BNF rule: <list> ::= <string>,... would specify a comma-separated list of strings. 2 Specifying Patterns Tree variables. Patterns can be specified with tree variables: <pattern> ::= <tree-variable> = <tree-pattern> ( <pattern-children> ) <tree-variable> ::= <ident> <tree-pattern> ::= <label> <label> - <index> - <index> <label> ::= <ident> <index> ::= <ident> <ident> ::= Any sequence of alphabetic and numeric characters and hyphen. An ident can contain at most one hyphen Examples of identifiers: Exchange Chip-give Chip-1 east -chips Tree patterns are matched to input trees. If a tree pattern matches a particular input tree, then that tree is bound to the tree-variable that appears on the left-hand side of the equals sign. 1

2 Tree patterns with no <label> (such as - and -chips) match any tree. Variables starting with a <label> match any tree whose root node is labeled with the given symbol. Thus the variable - matches any tree and the variable Chip-give matches any trees whose root node is labeled with Chip. Upon matching, the tree variable becomes bound to the matched tree. That tree variable can then be used to refer to that tree in the result portion of a rule. No tree variable may occur more than once in a given pattern. The intended use for indices is to allow specification of (and later reference to) multiple variables that match trees with the same root label. Examples of patterns (omitting the details of children): x = Exchange() give = Chip-give() y = -() Pattern Children We ll now fill in the grammar for specifying the children of a node: <pattern-children> ::= ɛ <pattern>, <pattern-children> Note that because the pattern children are patterns themselves, they must also be complete patterns with bindings to tree variables. Examples of complete patterns: x = Exchange(give = -givechips, obtain = -obtainchips) Exchange = Exchange(a = chip-a, b = chip-b) y = Chip(q = quantity, c = color) The first example matches a tree with a root node labeled Exchange and two children, which can be anything. x will be bound to the whole tree while give and obtain will be bound to the left and right subtrees, respectively. The second example is similar except that the two children must each be rooted in nodes that are labeled with chip. The third example matches a tree whose root node is labeled Chip and whose children are labeled quantity and color respectively. Tree Sequences. To allow for matching against an indeterminate number of children, a variable matching a sequence of children is allowed at the end of the list of pattern children: <pattern-children> ::= <tree-variable> = can match against zero or more children. Note that it can only appear at the end of a list of pattern children, not instead of a tree. Example: and = And(chip = Chip, rest =...) This pattern matches a node with root labeled And, a leftmost child labeled Chip, and then one 2

3 or more additional children that can be labeled anything. The sequence of children comprising all but the leftmost one is bound to the tree variable rest. Note the difference between the following two patterns: c = Chip(rest =...) c = Chip() The first pattern will match against any tree with Chip at the root it need not have more than one child. The third pattern will match only against a leaf labeled Chip with no children. 3 Pattern Shorthands One can already see that specifying patterns in this notation can be quite cumbersome. First, one must always specify the children of a node, whether or not they are relevant to the rewrite. Second, it requires each tree pattern to be explicitly associated with a tree variable. To alleviate this problem, we define shorthands for specifying the most common types of patterns. Thus, the following pre-processing transformations are applied in order to generate the pattern expected by the grammar: Transformation 1: Omission of children The children may be omitted from any tree. When children are omitted from a particular tree, it is assumed that a properly labeled node with any number of children will match the pattern in question. <tree-pattern> ( <pattern-children> ) <tree-pattern> ( <pattern-children> ) <tree-pattern> <tree-pattern> (+ =...) + is used as the variable name for the..., but it is special because it cannot be used to refer to the generated... on the right-hand side of the rule. If a... is generated by Transformation 1, it can never be referred to on the right-hand side of the rule. Examples of shorthand leading to application of Transformation 1: x = exchange(c1 = chip-1(k1 =...), c2 = chip-2(k2 =...)) x = exchange(c1 = chip-1, c2 = chip-2) Note that these two rules specify quite similar patterns because when Transformation 1 is applied, to the second example it will generate: x = exchange(c1 = chip-1(+ =...), c1 = chip-2(+ =...)) The only difference between the first example and the resulting rule when Transformation 1 is 3

4 applied to the second example is that the children of the chip nodes cannot be referenced in the right-hand side of the rule generated by example 2. Transformation 2: Omission of tree variables The tree variable and accompanying equal sign can be left out of any pattern. When this occurs, it is interpreted as shorthand and a corresponding tree variable is generated for the tree pattern in question. <tree-variable> = <tree-pattern> <tree-variable> = <tree-pattern> <tree-pattern> <tree-pattern> = <tree-pattern> <tree-variable> =... <tree-variable> = * =... Examples of the application of Transformation 2: exchange(chip-1(), chip-2()) request(chip(...-1),...) request(chip(+ =...),...) In the first example, applying Transformation 2 will yield: exchange = exchange(chip-1 = chip-1(), chip-2 = chip2()) In the second example, applying Trasnformation 2 will yield: request = request(chip = chip(*-1 =...-1), * =...) Note that in the second example, the user is given distinct ways to refer to the different sequence variables present in the pattern. In the third example, we see a rule that has already undergone Transformation 1, which added the children to chip. When Transformation 2 is applied, it generates: request = request(chip = chip(+ =...), * =...) Because the + refers to a generated sequence variable, it is as if no binding were created for it. 4 Specifying Results Given a set of bindings resulting from matching an input tree to a pattern, the following notations allow the user to specify the tree that results from applying the rule. In the examples below, we assume that the following bindings are in force: Exchange Exchange(Chip(1,blue), Chip(2,green)) 4

5 -givechips -obtainchips Chip(1,blue) Chip(2,green) Generation of New Structure. The simplest way to form a result is to generate new tree structure without reference to the bindings created in the pattern match. This alone is not particularly useful, but when combined with use of references can be important. <result> ::= <ident> <ident> ( <result-children> ) Examples of new structure in results: a(b(), c()) => x(y); b(c) => c; Note that children may be omitted in results and there are no tree variables at all. In the second example, the result will be the single letter c, not the piece of the input tree that the tree variable c is bound to. In order to refer to the tree variable c, the result needs to use an explicit symbol to indicate that the value of c should be looked up. Tree References. Results can be specified with reference to tree variables that were bound by the corresponding pattern part of the rewrite rule by appending a special lookup symbol, $: <result> ::= <tree-variable>$ A tree variable reference specifies that the output should be whatever tree is bound to the referenced variable. In addition, the rule may specify that the tree variable should be looked up, and the input tree it is bound to should be rewritten again. This is specified with the special symbol : <result> ::= <tree-variable> Finally, it is possible to look up a tree using a tree variable and then apply a cut to it to remove everything but the root. The cut is specified with the special symbol \: <result> ::= <tree-variable>\ Examples of tree references in results: a(b, c) => x(c$, b$); a(b, c) => x(c, b ); a(b, c) => x(a\, b$, c$); In the first example, the result will be a new tree, rooted in x rather than a, and with the two children switched in position. Rather than just the letters c and b, the bound pieces of the input trees will appear in the result. The second example is similar except that before placing the bound pieces of the input trees into the result, they will be rewritten again themselves. This means that they will be matched to a rule (which may be a different rule) and rewritten into a new result. 5

6 Finally, in the third example, the input tree bound to a will have all its children cut off and the root node will become the first child of the new tree. Trees. Combinations of new structure and tree references can be used to build new trees within the results: <result> ::= <tree-variable>\( <result-children> ) <result-children> ::= ɛ <result>, <result-children> Note that if tree variables appear at the root of a result tree, they must be cut. They cannot be looked up without being cut. They also cannot be rewritten (though this may be changed in future implementations.) Sequence variables Sequence variables (...) are a slightly special case. When they are explicitly given a tree variable in a pattern (ex. rest =...), they should be referenced with those tree variables. When tree variables are generated for them by Transformation 2, they should be referred to not with the generated *, but with the sequence variable itself:... This makes the rules much more human readable, though it seems a bit confusing here. When sequence variables are indexed, they should be referred to by the sequence variable and index combination. When a sequence variable is generated by Transformation 1, it cannot be referenced on the right-hand side of the rule. Examples of sequence variables in rules: a(rest =...) => b(rest$); a(...) => b(...$); a(...) => b(*); NOT LEGAL! a(...-2) => b(...-2); a => b(...$); NOT LEGAL! 5 Specifying Rewrite Rules Given the languages for pattern and results, the following notation allows specification of rewrite rules: <rule> ::= <pattern> => <result> ; Examples: We ve seen examples of simple rules already. The following two rules are commonly useful, slightly odd rules that do a good job of exercising the capabilities of the system: - => -$; 6

7 -(...) => -\(... ); The first rule here matches to anything and then leaves it unchanged on the other side. This can be useful for allowing things not affected by a particular set of rules to remain unchanged. The second rule also matches to anything, leaves the root unchanged, and rewrites the children. This can be useful for traversing a tree rewriting everything that matches a particular rule. These two rules demonstrate the application of both Transformations, the rules on bindings, look ups, cuts, rewrites, and references to sequence variables. 6 Specifying Systems of Rules It is very often useful to divide up the rewriting of a tree into different phases. The rewriting system makes this possible by allowing the specification of different passes of rules. Each pass is applied in ascending numerical order. All possible rewriting is done with the given pass before proceeding to the next pass. In addition, all rewriting caused by the affixing of a to a particular symbol takes place in the same pass as the rule in which the symbol appears. Passes are specified as follows: <rule> ::= <pass> <pattern> => <result> ; <pass> ; <pass> ::= ( <natural-number> ) <natural-number> ::= any whole number greater than or equal to 0 A pass may appear on the same line as a rule at the beginning of the line, or it may appear on a line by itself. A rule belongs to the pass that appears on the same line. Note, however, that a rule may appear without a pass. If no pass appears on the same line, a rule belongs to the nearest pass appearing above it. Every rule must belong to a pass. Applying a system of rules to a tree works as follows: In the lowest numbered pass, the textually first rule whose pattern matches is applied. Its result is generated and returned as the rewritten form of the input tree. If no rules match, the pass fails and no rewritten version is generated. When the pass is complete, the next pass in ascending order is applied. Note that it is also possible to specify that a single pass be used or to specify an alternate order in which to apply passes, but the default is to apply them all in order from the lowest to the highest. 7

8 7 The Complete Grammar <rule> ::= <pass> <pattern> => <result> ; <pattern> => <result> ; <pass> ; <pass> ::= ( <natural-number> ) <pattern> ::= <tree-variable> = <tree-pattern> ( <pattern-children> ) <tree-variable> ::= <ident> <tree-pattern> ::= <label> <label> - <index> - <index> <pattern-children> ::= <tree-variable> =... <result> ::= <ident> <tree-variable>$ <tree-variable> <tree-variable>\ <ident> ( <result-children> ) <tree-variable>\( <result-children> ) <result-children> ::= ɛ <result>, <result-children> <label> ::= <ident> <index> ::= <ident> <ident> ::= Any sequence of alphabetic and numeric characters and hyphen. An ident can contain at most one hyphen <natural-number> ::= any whole number greater than or equal to 0 8