4. Outer level syntax

  1. 4.1. Included files
  2. 4.2. Internal and external names
  3. 4.3. Token declarations
  4. 4.4. Token definitions
  5. 4.5. Alignment tag declarations
  6. 4.6. Alignment tag definitions
  7. 4.7. Tag declarations
  8. 4.8. Tag definitions

At the outer level tnc is expecting a sequence of constructs of the following forms:

4.1. Included files

Included files may be of three types—text, TDF capsule or TDF library. For TDF capsules and libraries there are two include modes. The first just decodes the given capsule or set of capsules. The second scans through them to extract token declaration information. These declarations appear in the output file only if they are used elsewhere.

The syntax for an included text file is:

( include string )

where string is a string giving the pathname of the file to be included. tnc applies read to this sub-file before continuing with the present file.

Similarly, the syntaxes for included TDF capsules and libraries are:

( code string )
( lib string )

respectively. tnc applies decode to this capsule or set of capsules (provided this mode is available) before continuing with the present file.

The syntaxes for extracting the token declaration information from a TDF capsule or library are:

( use_code string )
( use_lib string )

Again, these rely on the decode mode being available.

4.2. Internal and external names

All tokens, tags and alignment tags have an internal name, namely the associated identifier, but this name does not necessarily appear in the corresponding TDF capsule. There must firstly be an associated declaration or definition at the outer level - tags internal to a piece of TDF do not have external names. Even then we may not wish this name to appear at the outer level, because it is local to this file and is not required for linking purposes. Alternatively we may wish a different external name to be associated with it in the TDF capsule.

As an example of how tnc allows for this, consider token declarations (although similar remarks apply to token definitions, alignment tag definitions etc.). The basic form of the token declaration is:

( make_tokdec token_id ... )

This creates a token with both internal and external names equal to token_id. Alternatively:

( local make_tokdec token_id ... )

creates a token with internal name token_id but no external name. This allows the creation of tokens local to the current file. Again:

( make_tokdec ( string_extern string ) token_id ... )

creates a token with internal name token_id and external name given by the string string. For example, to create a token whose external name is not a valid identifier, it would be necessary to use this construct. Finally:

( make_tokdec ( unique_extern string1 ... stringn ) token_id ... )

creates a token with internal name token_id and external name given by the unique name consisting of the strings string1, ..., stringn.

The local quantifier should be used consistently on all declarations and definitions of the token, tag or alignment tag. The alternative external name should only be given on the first occasion however. Thereafter the object is identified by its internal name.

4.3. Token declarations

The basic form of a token declaration is:

( make_tokdec token_id ( arg1 ... argn ) res )

where the token token_id is declared to take argument sorts arg1, ..., argn and deliver the result sort res. These sorts are given by their sort names, al_tag, alignment, bitfield_variety etc. For a token with no arguments the declaration may be given in the form:

( make_tokdec token_id res )

A token may be declared any number of times, provided the declarations are consistent.

This basic declaration may be modified in the ways outlined above to specify the external token name.

4.4. Token definitions

The basic form of a token definition is:

( make_tokdef token_id ( arg1 id1 ... argn idn ) res def )

where the token token_id is defined to take formal arguments id1, ..., idn of sorts arg1, ..., argn respectively and have the value def, which is a construct of sort res. The scope of the tokens id1, ..., idn is def.

For a token with no arguments the definition may be given in the form:

( make_tokdef token_id res def )

A token may be defined more than once. All definitions must be consistent with any previous declarations and definitions (the renaming of formal arguments is allowed however).

This basic definition may be modified in the ways outlined above to specify the external token name.

4.5. Alignment tag declarations

The basic form of an alignment tag declaration is:

( make_al_tagdec al_tag_id )

where the alignment tag al_tag_id is declared to exist.

This basic declaration may be modified in the ways outlined above to specify the external alignment tag name.

4.6. Alignment tag definitions

The basic form of an alignment tag definition is:

( make_al_tagdef al_tag_id def )

where the alignment tag al_tag_id is defined to be def, which is a construct of sort alignment. An alignment tag may be declared or defined more than once, provided the definitions are consistent.

This basic definition may be modified in the ways outlined above to specify the external alignment tag name.

4.7. Tag declarations

The basic forms of a tag declaration are:

( make_id_tagdec tag_id info dec )
( make_var_tagdec tag_id info dec )
( common_tagdec tag_id info dec )

where the tag tag_id is declared to be an identity, variable or common tag with access information info, which is an optional construct of sort access, and shape dec, which is a construct of sort shape. A tag may be declared more than once, provided all declarations and definitions are consistent (including agreement of whether the tag is an identity, a variable or common).

These basic declarations may be modified in the ways outlined above to specify the external tag name.

4.8. Tag definitions

The basic forms of a tag definition are:

( make_id_tagdef tag_id def )
( make_var_tagdef tag_id info def )
( common_tagdef tag_id info def )

where the tag tag_id is defined to be an identity, variable or common tag with value def, which is a construct of sort exp. Non-identity tag definitions also have an optional access construct, info. A tag must have been declared before it is defined, but may be defined any number of times. All declarations and definitions must be consistent (except that common tags may be defined inconsistently) and agree on whether the tag is an identity, a variable, or common.

These basic definitions may be modified in the ways outlined above to specify the external tag name.