A Calculus for Language Transformations

Below we show the $\mathcal{L}\textendash\textsf{Tr}$ syntax for language definitions, which reflects the operational semantics style of defining languages. Sets are accommodated with lists.

$cname\in\textsc{CatName},{X}\in\textsc{Meta-Var},opname\in\textsc{OpName},predname\in\textsc{PredName}$

We assume a set of category names CatName, a set of meta-variables Meta-Var, a set of constructor operator names OpName, and a set of predicate names PredName. We assume that these sets are pairwise disjoint. OpName contains elements such as $\to$ and $\lambda$ (elements do not have to necessarily be (string) names). PredName contains elements such as $\vdash$ and $\longrightarrow$. To facilitate the modeling of our calculus, we assume that terms and formulae are defined in abstract syntax tree fashion. Here this means that they always have a top level constructor applied to a list of terms. $\mathcal{L}\textendash\textsf{Tr}$ also provides syntax to specify unary binding $({z})t$ and capture-avoiding substitution $t[t/{z}]$. Therefore, $\mathcal{L}\textendash\textsf{Tr}$ is tailored for static scoping rather than dynamic scoping. Lists can be built as usual with the ${\mathtt{nil}}$ and $\mathtt{cons}$ operator. We sometimes use the shorthand $[o_{1},\ldots o_{n}]$ for the corresponding series of $\mathtt{{\mathtt{cons}}}$ applications ended with ${\mathtt{nil}}$.

To make an example, the typing rule for function application and the $\beta$-reduction rules are written as follows. ($app$ is the top-level operator name for function application).

Below we show the rest of the syntax of $\mathcal{L}\textendash\textsf{Tr}$.
$x\in\textsc{Var},str\in\textsc{String},\{\mathit{self},\mathit{premises},\mathit{conclusion}\}\subseteq\textsc{Var}$

Programmers write expressions to specify transformations. At run-time, an expression will be executed with a language definition. Evaluating an expression may modify the current language definition.

Design Principles: We strive to offer well-crafted operations that map well with the language manipulations that are frequent in adding features to languages or switching semantics styles. There are three features that we can point out which exemplify our approach the most: 1) The ability to program parts of rules, premises and grammars, 2) selectors ${e}[p]:\;e$, and 3) the $\mathtt{uniquefy}$ operation. Below, we shall the describe the syntax for transformations, and place some emphasis in motivating these three operations.
Basic Data Types: $\mathcal{L}\textendash\textsf{Tr}$ has strings and has lists with typical operators for extracting their head and tail, as well as for concatenating them ($@$). $\mathcal{L}\textendash\textsf{Tr}$ also has maps (key-value). In $\mathtt{map}(e_{1},e_{2})$, $e_{1}$ and $e_{2}$ are lists. The first element of $e_{1}$ is the key for the first element of $e_{2}$, and so on for the rest of elements. Such a representation fits better our language transformations examples, as we shall see in Section 3. Operation $e_{1}(e_{2})$ queries a map, where $e_{1}$ is a map and $e_{2}$ is a key, and $\mathtt{mapKeys}\;e$ returns the list of keys of the map $e$. Maps are convenient in $\mathcal{L}\textendash\textsf{Tr}$ to specify information that is not expressible in the language definition. For example, we can use maps to store information about whether some type argument is covariant or contravariant, or to store information about the input-output mode of the arguments of relations. Section 3 shows that we use maps in this way extensively. $\mathcal{L}\textendash\textsf{Tr}$ also has options ($\mathtt{just}$, $\mathtt{nothing}$, and $\mathtt{get}$). We include options because they are frequently used in combination with the selector operator described below. Programmers can refer to grammar categories (cname) in positions where a list is expected. When cname is used the corresponding list of grammar items is retrieved.
Grammar Instructions: $cname\;{X}::=e$ is essentially a grammar production. With this instruction, the current grammar is augmented with this production. $cname\;{X}::=\ldots\;e$ (notice the dots) adds the terms in $e$ to an existing production. $\mathtt{getRules}$ and $\mathtt{setRules}\;e$ retrieve and set the current list of rules, respectively.
Selectors: ${e_{1}}[p]:\;e_{2}$ is the selector operator. This operation selects one by one the elements of the list $e_{1}$ that satisfy the pattern $p$ and executes the body $e_{2}$ for each of them. This operation returns a list that collects the result of each iteration. Selectors are useful for selecting elements of a language with great precision, and applying manipulations to them. To make an example, suppose that the variable prems contains the premises of a rule and that we wanted to invert the direction of all subtyping premises in it. The operation ${prems}[T_{1}<:T_{2}]:\;\mathtt{just}\;T_{2}<:T_{1}$ does just that. Notice that the body of a selector is an option. This is because it is common for some iteration to return no values ($\mathtt{nothing}$). The examples in Section 3 show this aspect. Since options are commonly used in the context of selector iterations, we have designed our selector operation to automatically handle them. That is, $\mathtt{nothing}$s are automatically removed, and the selector above returns the list of new subtyping premises rather than a list of options. The selector ${e(\mathtt{keep})}[p]:\;e$ works like an ordinary selector except that it also returns the elements that failed the pattern-matching.
Uniquefy: When transforming languages it is often necessary to assign distinct variables. The example of algorithmic subtyping in the introduction is archetypal. $\mathcal{L}\textendash\textsf{Tr}$ accommodates this operation as primitive with $\mathtt{uniquefy}$.
$\mathtt{uniquefy}(e_{1},e_{2},str)\Rightarrow(x,y):e_{3}$ takes in input a list of formulae $e_{1}$, a map $e_{2}$, and a string $str$ (we shall discuss $x$, $y$, and $e_{3}$ shortly). This operation modifies the formulae $e_{2}$ to use different variable names when a variable is mentioned more than once. However, not every variable is subject to the replacement. Only the variables that appear in some specific positions are targeted. The map $e_{2}$ and the string $str$ contain the information to identify these positions. $e_{2}$ maps operator names and predicate names to a list that contains a label (as a string) for each of their arguments. For example, the map $m=\{\vdash\;\mapsto[``{in}",``{in}",``{out}"]\}$ says that $\Gamma$ and $e$ are inputs in a formula $\Gamma\vdash e:T$, and that $T$ is the output. Similarly, the map $\{\to\;\mapsto[``{contravariant}",``{covariant}""]\}$ says that $T_{1}$ is contravariant and $T_{2}$ is covariant in $T_{1}\to T_{2}$. The string $str$ specifies a label. $\mathcal{L}\textendash\textsf{Tr}$ inspects the formulae in $e_{1}$ and their terms. Arguments that correspond to the label according to the map then receive a new variable. To make an example, if $\mathit{lf}$ is the list of premises of (t-app) and $m$ is defined as above (input-output modes), the operation $\mathtt{uniquefy}(\mathit{lf},m,``{out}")\Rightarrow(x,y):e_{3}$ creates the premises of (t-app’) shown in the introduction. Furthermore, the computation continues with the expression $e_{3}$ in which $x$ is bound to these premises and $y$ is bound to a map that summarizes the changes made by $\mathtt{uniquefy}$. This latter map associates every variable $X$ to the list of new variables that $\mathtt{uniquefy}$ has used to replace $X$. For example, since $\mathtt{uniquefy}$ created the premises of (t-app’) by replacing $T_{1}$ in two different positions with $T_{11}$ and $T_{12}$, the map $\{T_{1}\mapsto[T_{11},T_{12}]\}$ is passed to $e_{3}$ as $y$. Section 3 will show two examples that make use of $\mathtt{uniquefy}$.
Control Flow: $\mathcal{L}\textendash\textsf{Tr}$ includes the if-then-else statement with typical guards. $\mathcal{L}\textendash\textsf{Tr}$ also has the sequence operation ; (and $\mathtt{skip}$) to execute language transformations one after another. $e_{1};_{\text{r}}e_{2}$, instead, executes sequences of transformations on rules. After $e_{1}$ evaluates to a rule, $e_{2}$ makes use of that rule as the subject of its transformations.
Programming Rules, Premises, and Terms: In $\mathcal{L}\textendash\textsf{Tr}$ a programmer can write $\mathcal{L}\textendash\textsf{Tr}$ terms ($\hat{t}$), $\mathcal{L}\textendash\textsf{Tr}$ formulae ($\hat{f}$), and $\mathcal{L}\textendash\textsf{Tr}$ rules ($\hat{r}$) in expressions. These differ from the terms, formulae and rules of language definitions in that they can contain arbitrary expressions, such as if-then-else statements, at any position. This is a useful feature as it provides a declarative way to create rules, premises, or terms. To make an example with rule creation, we can write

where prems is the list of premises from above, and $f$ is a formula. As we can see, using expressions above the horizontal line is a convinient way to compute the premises of a rule.
Other Operations: The operation $\mathtt{fold}\;predname\;e$ creates a list of formulae that interleaves $predname$ to any two subsequent elements of the list $e$. To make an example, the operation $\mathtt{fold}\;=\;[T_{1},T_{2},T_{3},T_{4}]$ generates the list of formulae $[T_{1}=T_{2},T_{2}=T_{3},T_{3}=T_{4}]$. $\mathtt{vars}(e)$ returns the list of the meta-variables in $e$. $\mathtt{newVar}$ returns a meta-variable that has not been previously used. The tick operator $e\texttt{'}$ gives a prime ^′ to the meta-variables of $e_{1}$ (${X}$ becomes ${X^{\prime}}$). $\mathtt{vars}$ and the tick operator also work on lists of terms.
Variables and Substitution: Some variables have a special treatment in $\mathcal{L}\textendash\textsf{Tr}$. We can refer to the value that a selector iterates over with the variable $\mathit{self}$. If we are in a context that manipulates a rule, we can also refer to the premises and conclusion with variables $\mathit{premises}$ and $\mathit{conclusion}$. We use the notation $e[v/x]$ to denote the capture-avoiding substitution. $\theta$ ranges over finite sequences of substitutions denoted with $[v_{1}/x_{1},\ldots,v_{n}/x_{n}]$. $e[v_{1}/x_{2},v_{1}/x_{2},\ldots,v_{n}/x_{n}]$ means $((e[v_{1}/x_{1}])[v_{2}/x_{2}])\ldots[v_{n}/x_{n}]$. We omit the definition of substitution because it is standard, for the most part. The only aspect that differs from standard substitution is that we do not substitute $\mathit{self}$, $\mathit{premises}$ and $\mathit{conclusion}$ in those contexts that will be set at run-time ($;_{\textsf{r}}$, and selector body). For example, $(e_{1};_{\textsf{r}}e_{2})[v/\mathcal{X}]\equiv(e_{1}[v/\mathcal{X}]);_{\textsf{r}}e_{2}$, where $\mathcal{X}\in\{\mathit{self},\mathit{premises},\mathit{conclusion}\}$.

In this section we show a small-step operational semantics for $\mathcal{L}\textendash\textsf{Tr}$. A configuration is denoted with $V;\mathcal{L};e$, where $e$ is an expression, $\mathcal{L}$ is the language subject of the transformation, and $V$ is the set of meta-variables that have been generated by $\mathtt{newVar}$. Calls to $\mathtt{newVar}$ make sure not to produce name clashes.

The main reduction relation is $V;\mathcal{L};e\longrightarrow V^{\prime};\mathcal{L}^{\prime};e^{\prime}$, defined as follows. Evaluation contexts $E$ are straightforward and can be found in Appendix LABEL:evaluationcontexts.

This relation relies on a step $V;\mathcal{L};e\longrightarrow_{\mathtt{@}}V^{\prime};\mathcal{L}^{\prime};e^{\prime}$, which concretely performs the step. Since a transformation may insert ill-formed elements such as $\vdash T\;T$ or $\to\;e\;e$ in the language, we also rely on a notion of type checking for language definitions $\vdash\mathcal{L}^{\prime}$ decided by the language designer. For example, our implementation of $\mathcal{L}\textendash\textsf{Tr}$ compiles languages to $\lambda$-prolog and detects ill-formed languages at each step, but the logic of Coq, Agda, Isabelle could be used as well. Our type soundness theorem works regardless of the definition of $\vdash\mathcal{L}^{\prime}$.

Fig. 1 shows the reduction relation $V;\mathcal{L};e\longrightarrow_{\mathtt{@}}V^{\prime};\mathcal{L}^{\prime};e^{\prime}$. We show the most relevant rules. The rest of the rules can be found in Appendix LABEL:app:operational. (r-cname-ok) and (r-cname-fail) handle the encounter of a category name. We retrieve the corresponding list of terms from the grammar or throw an error if the production does not exist. (r-getRules) retrieves the list of rules of the current language, and (r-setRules) updates this list. (r-new-syntax) replaces the grammar with a new one that contains the new production. The meta-operation $G\backslash cname$ in that rule removes the production with category name $cname$ from $G$ (definition is straightforward and omitted). The position of $cname$ in $(cname\;{X}::=v)$ is not an evaluation context, therefore (r-cname-ok) will not replace that name. (r-add-syntax-ok) takes a step to the instruction for adding new syntax. The production to be added includes both old and new grammar terms. (r-add-syntax-fail) throws an error when the category name does not exist in the grammar, or the meta-variable does not match. (r-rule-seq) applies when the first expression has evaluated, and starts the evaluation of the second expression. (Evaluation context $E;e$ evaluates the first expression) (r-rule-comp) applies when the first expression has evaluated to a rule, and starts the evaluation of the second expression where $\theta_{\textsf{rule}}^{(v)}$ sets this rule as the current rule. Rules (r-selector-*) define the behavior of a selector. (r-selector-cons-ok) and (r-selector-cons-fail) make use of the meta-operation $\mathit{match}(v_{1},p)=\theta$. If this operation succeeds it returns the substitutions $\theta$ with the associations computed during pattern-matching. The definition of $\mathit{match}$ is standard and is omitted. The body is evaluated with these substitutions and with $\mathit{self}$ instantiated with the element selected. If the element selected is a rule, then the body is instantiated with $\theta_{\textsf{rule}}^{(v)}$ to refer to that rule as the current rule. The body of the selector always returns an option type. However, $\mathit{cons}^{*}$ is defined as: $\mathit{cons}^{*}\;{e_{1}}\;{e_{2}}\equiv\mathtt{if}\;(\mathtt{isNothing}\;e_{1})\;\mathtt{then}\;e_{2}\;\mathtt{else}\;\mathtt{cons}\;(\mathtt{get}\;e_{1})\;e_{2}$. Therefore, $\mathtt{nothing}$s are discarded, and values wrapped in $\mathtt{just}$s are unwrapped. (r-newvar) returns a new meta-variable and augments $V$ with it. Meta-variables are chosen among those that are not in the language, have not previously been generated by $\mathtt{newVar}$, and are not in the range of $\mathit{tick}$. This meta-operation is used by the tick operator to give a prime to meta-variables. r-newvar avoids clashes with these variables, too. (r-uniquefy-ok) and (r-uniquefy-fail) define the semantics for $\mathtt{uniquefy}$. They rely on the meta-operation $\mathit{uniquefy}_{\textsf{r}}(\mathit{lf},v,str,\mathtt{map}([],[]))$, which takes the list of formulae $\mathit{lf}$, the map $v$, the string $str$, and an empty map to start computing the result map. The definition of $\mathit{uniquefy}_{\textsf{r}}$ is mostly a recursive traversal of list of formuale and terms, and we omit that. It can be found in Appendix LABEL:uniquefy. This function can succeed and return a pair $(\mathit{lf}^{\prime},v_{2})$ where $\mathit{lf}^{\prime}$ is the modified list of formulae and $v_{2}$ maps meta-variables to the new meta-variables that have replaced it. $\mathit{uniquefy}_{\textsf{r}}$ can also fail. This may happen when, for example, a map such as $\{\to\;\mapsto``contra"\}$ is passed when $\to$ requires two arguments.