Abbreviatory variables

 

The default mechanism of DATR provides for generalisation across sets of atoms by means of path extension and is the preferred mechanism to use in the majority of cases. However, when one wants to transduce atoms in the path domain to atoms in the value domain (see Section 6.3, below), it is extremely convenient to be able to make use of abbreviatory variables over finite sets of atoms. This is achieved by declaring DATR variables whose use constitutes a kind of macro: they can always be eliminated by replacing the equations in which they occur with larger sets of equations that spell out each value of the variables. Conventionally, variable names begin with the $ character and are declared in one of the following three ways:

    # vars $Var1: Range1 Range2 ... .
    # vars $Var2: Range1 Range2 ... - RangeA RangeB ... .
    # vars $Var3.

Here, the first case declares a variable $Var1 that ranges over the values Range1, Range2 ..., where each RangeN is either an atom or a variable name, the second case declares $Var2 to range over the same range, but excluding values in RangeA RangeB ..., and the third declares $Var3 to range over the full (finite) set of atoms in the language. For example:

    # vars $letters: a b c d e f g h i j k l m n o p q r s t u v w x y z.
    # vars $vowels: a e i o u.
    # vars $consonants: $letters - $vowels.
    # vars $not_z: $letters - z.

    # vars $odd: 1 3 5 7 9.
    # vars $even: 0 2 6 4 8.
    # vars $digit: $odd $even.

Caution has to be exercised in the use of DATR variables for two reasons. One is that their use makes it hard to spot multiple conflicting definitions:

    # vars $vowel: a e i o u.
    DIPTHONG:
        <e> == e i <>
        <$vowel> == $vowel e <>.

Here, <e> appears on the left hand side of two conflicting definitions. Exactly what happens to such an improper description in practice depends on the implementation and usages of this kind can be the source of hard to locate bugs (See also Section 3.1.5, below.).

The other reason is that one can fall into the trap of using variables to express generalisations that would be better expressed using the path extension mechanism. Here is a very blatant example:

    # vars $number: singular plural.
    NOUNX:
        <third $number> == <second $number>.

This would almost certainly be better expressed as:

    NOUNX:
        <third> == <second>.

The following example is a variant on the same theme:

    # vars $number: singular plural.
    NOUNY:
        <$number third> == <$number second>.

which suggests, not a real need for the use of DATR variables, but rather an inappropriate choice of attribute order in the design of the description.