Boolean logic

 We can, if we wish, use parameters in evaluable paths that resolve to true or false. We can then define standard truth tables over DATR paths:

    Boolean:
        <> == false
        <or> == true
        <if> == true
        <not false> == true
        <and true true> == true
        <if true false> == false
        <or false false> == false.

This node defines the standard truth tables for all the familiar operators and connectives of the propositional calculus expressed in Polish rather than infix order (we can, of course, use the same technique to define many-valued logics if we wish). Notice, in particular, how the DATR default mechanism completes most of the truth table rows without explicit listing. The definability of the propositional calculus may appear, at first sight, to be a curiosity, one which has no relevance to real-life lexical representation. But that is not so. Consider a hypothetical language in which personal proper names have one of two genders, masculine or feminine. Instead of the gender being wholly determined by the sex of the referent, the gender is determined partly by sex and partly by the phonology. Examples of this general type are quite common in the world's languages. In our hypothetical example, the proper name will have feminine gender either if it ends in a consonant and denotes a female or if it ends in a stop consonant but does not denote a female. We can encode this situation in DATR as follows:

    Personal_name:
        <> == Boolean
        <ends_in_consonant> == "<ends_in_stop>"
        <gender_is_feminine> ==
                  <or <and "<female_referent>" "<ends_in_consonant>">
                      <and <not "<female_referent>"> "<ends_in_stop>">>.

Note that complex expressions require path embedding. Thus, for example, the well-formed negation of a conditional is <not <if .. ..>> rather than <not if .. ..>.

We can now list some example lexical entries for personal proper names. For the sake of simplicity, we assume that the truth values of <ends_in_consonant> and <ends_in_stop> are just stipulated in the entries, and indeed the second definition in Personal_name means that <ends_in_stop> implies <ends_in_consonant>. But if the entries represented the phonology of the words in DATR also, then these predicates could be defined on the basis of the feature composition of the stem-final segment. As a number of researchers have shown, the highly defaulty character of lexical phonology and morphophonology makes DATR a very suitable medium of representation.

    Taruz:
        <> == Personal_name
        <female_referent> == true
        <ends_in_consonant> == true.
    Turat:
        <> == Personal_name
        <female_referent> == true
        <ends_in_stop> == true.
    Tarud:
        <> == Personal_name
        <ends_in_stop> == true.
    Turas:
        <> == Personal_name
        <ends_in_consonant> == true.

Note that both Turas and Tarud turn out not to denote females, given the general false default in Boolean. The genders of all four names can now be obtained as theorems:

    Taruz: <gender_is_feminine> = true.
    Turat: <gender_is_feminine> = true.
    Tarud: <gender_is_feminine> = true.
    Turas: <gender_is_feminine> = false.

It is straightforward to add extra DATR code so as to derive <gender> = feminine when <gender_is_feminine> is true and <gender> = masculine when <gender_is_feminine> is false, or conversely.