This post is number 7 in a sequence of 7. Click here to get to the beginning.
The ‘<on>’ and ‘<no>’ symbols
The ‘<on>’ and ‘<no>’ symbols are used to begin and end the definition of a type or field script or annotation as shown in the example annotation and script definitions below. The first two definitions show an example type annotation and type script, the second two show an example field annotation and field script. The text that immediately follows the <on> symbol defines the script or annotation name and must begin with the ‘$’ character and be on the same line as the symbol, the actual body of the script/annotation begins at the start of the following line and ends at the trailing <no> symbol.
The ‘script’ keyword
The ‘script’ keyword is used to declare a script associated with a type or type field. Script names must be ASCII alphanumeric sequences starting with the ‘$’ character and containing no spaces. If the text following the ‘script’ keyword and before the ‘<on>’ symbol that delimits the start of the script body, contains just a valid type name, then the script applies to that type (and through type inheritance to all descendent types – unless overridden). This is known as a “type script”. If on the other hand the text between the ‘script’ keyword and the ‘<on>’ symbol contains a type name followed by a ‘.’ separated field path within that type, then the definition is a “field script” and applies to the specified field and to the same field in any descendant type (unless overridden).
To override a type or field script in any descendant type, one simply declares a new type or field script associated with the descendent type. Scripts themselves will be more fully discussed in later posts.
The ‘annotation’ keyword
The ‘annotation’ keyword is used to declare an annotation associated with a type or type field. Annotation names must be ASCII alphanumeric sequences starting with the ‘$’ character and containing no spaces. If the text following the ‘annotation’ keyword and before the ‘<on>’ symbol that delimits the start of the annotation body, contains just a valid type name, then the annotation applies to that type (and through type inheritance to all descendent types – unless overridden). This is known as a “type annotation”. If on the other hand the text between the ‘annotation’ keyword and the ‘<on>’ symbol contains a type name followed by a ‘.’ separated field path within that type (as in the second two examples in the listing above), then the definition is a “field annotation” and applies to the specified field and to the same field in any descendant type (unless overridden).
To override a type or field annotation in any descendant type, one simply declares a new type or field annotation associated with the descendent type. Annotations themselves will be more fully discussed in later posts.
Designating external type DBs
Carmot allows the typedef keyword to be followed by a character constant designating the type database within which the defined type can be found (see later post). This feature is intended to allow forward declarations from an earlier type DB to a later one as in the following example:
typedef ‘K’ struct SourceQuery; // Query types are defined in K.DEF
Creating forward declarations between type DBs in this manner should be avoided wherever possible since it may potentially cause problems in the type dependencies, however providing the type usage within the referring type DB is restricted to indirect references to the type, this syntax can be used to overcome rare but unavoidable references to downstream types across distinct type DBs. There is no need to designate the type DB for any type declared in an earlier type DB since it is already known at the time any downstream type DB is compiled by Carmot.