TRALE-EXTENSION:Signature Input Format

The input to the signate is one or more files containing information about a type hierarchy and the appropriateness conditions. Syntactically, a type hierarchy (or a fragment of it) is everything between the key word type_hierarchy and a period (.) each being the sole contents of an otherwise blank line. The first hierarchy, which may be the only one, must always begin with the type bot as the first word in the first informative line following type_hierarchy. (Of course there may be empty lines or comment lines lying between them.) The following lines consist of regularly indented lines each containing one type and optionally its appropriateness conditions. Here is a small example:

 
type_hierarchy 
bot
  s1 f:t1 
    s4 f:t4
  s2 f:t2
    s4
  s3 f:t3
    s4

  t1
    t4 
  t2
    t4
  t3
    t4
.

In general, each nonempty line consists of three parts:

$$\mbox{{\bf Indentation} {\bf Type} [{\bf Features}]}$$

with:

Indentation

consists of a number of spaces. We strongly suggest to use spaces, not tabs, since tabs are always considered to be equivalent to 8 spaces and this won't necessarily be what you see in your editor.^2.2 The subtypes to each type are listed below that type at a consistent level of increased indentation just as headings and subheadings are indented in an outline. So, if a type $t$ occurs at indentation level $I$, then there must be a positive $n$ such that all of the subtypes of $t$ occur at indentation level $I + n$. For each type, a different indentation level $n$ may be chosen for the subtypes, though in general, it will be preferable to chose an indentation level of 3 or 4 spaces and use that level consistently.^2.3

Type

is syntactically a term. It is the name of the type to be specified in the current line. Each informative line must contain at least a type name. A type may never occur twice as the subtype of one and the same supertype. It can, however, occur as a subtype of two different supertypes, i.e., for multiple inheritance. In this case the type should be proceeded with an ampersand (&).^2.4 A type name must always start with a lower case letter.

Features

consists of a possibly empty number of terms of the form feat:val each two separated by white space. feat is the name of a feature and val is the name of the type appropriate for this feature. As with the types, a feature name must always start with a lower case letter. If a feature is specified for a type, all its subtypes inherit this feature without any need for the user to say so explicitly. But he still can, if he wants. There is also a case of downward inheritance. If all the subtypes of a type share a feature, this feature will be introduced on the common supertype. The type appropriate for this feature at the supertype must then be the disjunction of all the types appropriate for the feature on the subtypes. Often, though, such a disjunction of types may be expressed as a semantically equivalent single type.

If the þ is divided into several parts, the additional information is hooked into the first, root hierarchy in the following way. Each part consists of a type where to hook the information into and its subtypes specified in just the same manner as in the first hierarchy part. Therefore the format looks like

type_hierarchy
Type
Indentation Type [Features]
...
Indentation Type [Features]
.

The first line after type_hierarchy consists of a single type, the type to which the following additional hierarchy should be linked. Thus this type must have occurred before. Since the type is used as a hook, no feature specifications are allowed here. The following lines are type specification lines obeying the rules explained above. All types of the first indentation level are regarded as new subtypes of the type to be hooked up to. Re-specifying an identical subtype of one and the same type results in a syntax error even if the second entry specifies features non-existing on the first entry. To give an example, here is the same type hierarchy as above specified in three pieces:

type_hierarchy
bot        
  s1 f:t1 
  s2 f:t2
  s3 f:t3
    s4

  t1
    t4 
  t2
    t4
  t3
    t4
.

... % some other stuff

type_hierarchy
s1
    s4 f:t4
.

... % some more stuff

type_hierarchy
s2
    s4
.

Finally since each type should be specified only once, cases of multiple inheritance need a special key word to signal to the compiler that the re-occurrence of this type is indeed intended. The key word is the & (ampersand) which may be placed in front of the type name when the type multiply inherits. It is left to the user where he wishes to place the &, that means, it is immaterial, whether the & is placed in front of all or some appearances of the type, or whether at the first appearance or at later ones. It is recommended that the & is used, but this is not mandatory.