The intention is to develop a set of optional but standard DATR functions that can be invoked, rather than defined, by a DATR description if the user wishes. For some of these functions, the advantages are purely those of efficiency, convenience, neatness, and avoidance of variables. For others, the standard library function does something that is beyond the powers of pure DATR, like breaking an atom into its component characters. The former class are presented below with canonical DATR definitions to indicate the intended semantics, whilst the latter are presented only with a prose gloss of their meaning and one or more examples of their use.
It is anticipated that all the proposed standard library functions will be defined in the implementation language rather than in DATR itself. This has the (potential) advantage of eliminating variable name clashes. Clearly one can also create and maintain libraries of DATR functions that are written in DATR itself but such libraries are not our concern in this document.
In the Sussex DATR implementation, each extant standard library function is kept in a separate file (with a predictable name) in a directory called ./useslib. Many have a one-line definition. Thus, for example, the Qnode library function is defined in the file ./useslib/Qnode.pl and this file contains exactly one line of Prolog:
'Qnode'([N|P],GN,GP,V) :- datr_qnode(QN,QP), datr_call([N,QP,N,QP,V]).
Before we review the standard library functions, we need to consider DATR directives, however.
