The include directive does exactly what the name suggests: the text in the named files should be treated by an implementation exactly as if it appeared in the file that contains the include directive in the place where the directive appears. It needn't even contain well-formed DATR: it can contain code that only makes syntactic sense when it appears in the specified location. It is thus quite distinct from the load directive which provides separate compilation of self-contained coherent DATR fragments. A loaded file can thus always be included (though this may be inefficient) but the converse is not the case.
# include 'common.dtr'. # include 'common.dtr' 'datrtrix.dtr'. # include common. % .dtr suffix assumed # include common datrtrix. % .dtr suffixes assumed
The bool directive tells the implementation which two atoms are being used as the boolean values. If it is not used, then the default is 1, 0. The directive is necessary because the boolean library functions need to know which pair of values are in use.
# bool 1 0. # bool T F. # bool True False. # bool Good Bad.
The sort directive tells the implementation what sort order is relevant to the Sort and Mode library functions. It does two things: it specifies the relevant order and it specifies the relevant atom type. More on this below. Standard names for four useful sort orders are proposed below: abc is dictionary order; ascii is - well, you guess; boolean is a truth-precedes-falsity order on the boolean atoms (whatever they may be); and numeric is what you would expect (though if the implementation permits more than just the signed integers, then there is a typing issue lurking here).
# sort abc. # sort ascii. # sort boolean. # sort numeric.
One can imagine that implementations might wish to have names for other standard orders (though no other candidates occur to me as I write). And it is very likely that users will wish to be able to declare their own sort orders. The following syntax is proposed for such declarations:
# sort alpha beta gamma delta. # sort first second third fourth fifth. # sort excellent good adequate poor awful. # sort Solaris Linux Irix HP-UX OS/2 DOS NT MacOS Win98 Win95 'Win3.1'.
Note that the items in such an explicit sort declaration have to be atoms - if initial capital items are listed then the implementation needs to treat them as if they had been declared as atoms explicitly.
Sort declarations, though appealing, are arguably a bit of a luxury. Since a DATR fragment can only contain a single sort declaration (which thus applies globally), one can easily used a standard named sort (numeric, say) and then transduce from that into one's preferred set of atoms.
The Permute library function, described below, requires access to the random number generator in the implementation language. In order to get repeatable results from it, one needs to be able to pass the latter an explicit seed (though one should not be required to). Hence:
# seed 97. # seed 9713.
Standard library functions have to be explicitly invoked before they can be used. The simple syntax for such invocation is illustrated below:
# uses Idem Sum Ascii And.
However, if you wish to rename one or more of the standard library functions, then you can do so as follows:
# uses Idem:Copy Sum Ascii:ASCII And:utterly_bizarre_hybrid_conjunction.
In this example, the first and third standard library functions have been renamed as Copy and ASCII, respectively, and the fourth has been given a (rather long) name that begins with a lower case letter.
If one does not invoke a standard library function with the uses directive, then DATR will know nothing of it and the name can be used for a node defined howsoever you wish. Likewise, if you invoke a standard library function with the uses directive but give it your own preferred name, then DATR will know nothing of the former name and the latter can then be used to name a node that you define yourself.