Blame | Last modification | View Log | RSS feed
<!-- Crown Copyright (c) 1998 -->
<HTML>
<!-- Generated by ramify version 1.1 -->
<HEAD>
<TITLE>
TDF Notation Compiler
</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<H1>TDF Notation Compiler</H1>
<H3>January 1998</H3>
<IMG SRC="../images/no_next.gif" ALT="next section">
<IMG SRC="../images/no_prev.gif" ALT="previous section">
<IMG SRC="../images/no_top.gif" ALT="current document">
<A HREF="../index.html"><IMG SRC="../images/home.gif" ALT="TenDRA home page">
</A>
<IMG SRC="../images/no_index.gif" ALT="document index"><P>
<HR>
<DL>
<DT><A HREF="#S1"><B>1</B> - Introduction</A><DD>
<DT><A HREF="#S2"><B>2</B> - Input classes</A><DD>
<DL>
<DT><A HREF="#S21"><B>2.1</B> - Delimiters</A><DD>
<DT><A HREF="#S22"><B>2.2</B> - White space</A><DD>
<DT><A HREF="#S23"><B>2.3</B> - Comments</A><DD>
<DT><A HREF="#S24"><B>2.4</B> - Identifiers</A><DD>
<DT><A HREF="#S25"><B>2.5</B> - Numbers</A><DD>
<DT><A HREF="#S26"><B>2.6</B> - Strings</A><DD>
<DT><A HREF="#S27"><B>2.7</B> - Blanks</A><DD>
<DT><A HREF="#S28"><B>2.8</B> - Bars</A><DD>
</DL>
<DT><A HREF="#S3"><B>3</B> - Input syntax</A><DD>
<DL>
<DT><A HREF="#S31"><B>3.1</B> - Basic syntax</A><DD>
<DT><A HREF="#S32"><B>3.2</B> - Sorts</A><DD>
<DT><A HREF="#S33"><B>3.3</B> - Numbers and strings</A><DD>
<DT><A HREF="#S34"><B>3.4</B> - Tokens, tags, alignment tags and labels</A><DD>
<DT><A HREF="#S35"><B>3.5</B> - Outer level syntax</A><DD>
<DT><A HREF="#S36"><B>3.6</B> - Included files</A><DD>
<DT><A HREF="#S37"><B>3.7</B> - Internal and external names</A><DD>
<DT><A HREF="#S38"><B>3.8</B> - Token declarations</A><DD>
<DT><A HREF="#S39"><B>3.9</B> - Token definitions</A><DD>
<DT><A HREF="#S310"><B>3.10</B> - Alignment tag declarations</A><DD>
<DT><A HREF="#S311"><B>3.11</B> - Alignment tag definitions</A><DD>
<DT><A HREF="#S312"><B>3.12</B> - Tag declarations</A><DD>
<DT><A HREF="#S313"><B>3.13</B> - Tag definitions</A><DD>
</DL>
<DT><A HREF="#S4"><B>4</B> - Shape checking</A><DD>
<DT><A HREF="#S5"><B>5</B> - Remarks</A><DD>
<DT><A HREF="#S6"><B>6</B> - Limitations</A><DD>
<DT><A HREF="#S7"><B>7</B> - Manual Page for tnc</A><DD>
</DL>
<HR>
<H2><A NAME=S1>1. Introduction</A></H2>
<P>
The TDF notation compiler, <CODE>tnc</CODE>, is a tool for translating
TDF capsules to and from text. This paper gives a brief introduction
to how to use this utility and the syntax of the textual form of TDF.
The version here described is that supporting version 3.1 of the TDF
specification.
<P>
<CODE>tnc</CODE> has four modes, two input modes and two output modes.
These are as follows:
<UL>
<LI><B>decode</B> - translate an input TDF capsule into the <CODE>tnc</CODE>
internal representation,
<LI><B>read</B> - translate an input text file into the internal representation,
<LI><B>encode</B> - translate the internal representation into an
output TDF capsule,
<LI><B>write</B> - translate the internal representation into an output
text file.
</UL>
<P>
Due to the modular nature of the program it is possible to form versions
of <CODE>tnc</CODE> in which not all the modes are available. Passing
the <B>-version</B> flag to <CODE>tnc</CODE> causes it to report which
modes it has implemented.
<P>
Any application of <CODE>tnc</CODE> consists of the composite of an
input mode and an output mode. The default action is <B>read</B>-<B>encode</B>,
i.e. translate an input test file into an output TDF capsule. Other
modes may be specified by passing the following command line options
to <CODE>tnc</CODE>:
<UL>
<LI><B>-decode</B> or <B>-d</B>,
<LI><B>-read</B> or <B>-r</B>,
<LI><B>-encode</B> or <B>-e</B>,
<LI><B>-write</B> or <B>-w</B>.
</UL>
<P>
The only other really useful action is <B>decode</B>-<B>write</B>,
i.e. translate an input TDF capsule into an output text file. This
may also be specified by the <B>-print</B> or <B>-p</B> option. The
actions <B>decode</B>-<B>encode</B> and <B>read</B>-<B>write</B> are
not precise identities, they do however give equivalent input and
output files.
<P>
In addition, the <B>decode</B> mode may be modified to accept a TDF
library as input rather than a TDF capsule by passing the addition
flag:
<UL>
<LI><B>-lib</B> or <B>-l</B>,
</UL>
<P>
to <CODE>tnc</CODE>.
<P>
The overall syntax for <CODE>tnc</CODE> is as follows:
<PRE>
tnc [ options ... ] input_file [ output_file ]
</PRE>
If the output file is not specified, the standard output is used.
<P>
<HR>
<H2><A NAME=S2>2. Input classes</A></H2>
<P>
The rest of this paper is concerned with the form required of the
input text file. The input can be divided into eight classes.
<H3><A NAME=S21>2.1. Delimiters</A></H3>
<P>
The characters <CODE>(</CODE> and <CODE>)</CODE> are used as delimiters
to impose a syntactic structure on the input.
<H3><A NAME=S22>2.2. White space</A></H3>
<P>
White space comprises sequences of space, tab and newline characters,
together with comments (see below). It is not significant to the output
(TDF notation is completely free-form), and serves only to separate
syntactic units. Every identifier, number etc. must be terminated
by a white space or a delimiter.
<H3><A NAME=S23>2.3. Comments</A></H3>
<P>
Comments may be inserted in the input at any point. They begin with
a <CODE>#</CODE> character and run to the end of the line.
<H3><A NAME=S24>2.4. Identifiers</A></H3>
<P>
An identifier consists of any sequence of characters drawn from the
following set: upper case letters, lower case letters, decimal digits,
underscore (<CODE>_</CODE>), dot (<CODE>.</CODE>), and tilde (<CODE>~</CODE>),
which does not begin with a decimal digit. <CODE>tnc</CODE> generates
names beginning with double tilde (<CODE>~~</CODE>) for unnamed objects
when in <B>decode</B> mode, so the use of such identifiers is not
recommended.
<H3><A NAME=S25>2.5. Numbers</A></H3>
<P>
Numbers can be given in octal (prefixed by <CODE>0</CODE>), decimal,
or hexadecimal (prefixed by <CODE>0x</CODE> or <CODE>0X</CODE>). Both
upper and lower case letters can be used for hex digits. A number
can be preceded by any number of <CODE>+</CODE> or <CODE>-</CODE>
signs.
<H3><A NAME=S26>2.6. Strings</A></H3>
<P>
A string consists of a sequence of characters enclosed in double quotes
(<CODE>"</CODE>). The following escape sequences are recognised:
<UL>
<LI><CODE>\n</CODE> represents a newline character,
<LI><CODE>\t</CODE> represents a tab character,
<LI><CODE>\xxx</CODE>, where <CODE>xxx</CODE> consists of three octal
digits, represents the character with ASCII code <CODE>xxx</CODE>.
</UL>
<P>
Newlines are not allowed in strings unless they are escaped. For all
other escaped characters, <CODE>\x</CODE> represents <CODE>x</CODE>.
<H3><A NAME=S27>2.7. Blanks</A></H3>
<P>
A single minus character (<CODE>-</CODE>) has a special meaning. It
may be used to indicate the absence of an optional argument or optional
group of arguments.
<H3><A NAME=S28>2.8. Bars</A></H3>
<P>
A single vertical bar (<CODE>|</CODE>) has a special meaning. It may
be used to indicate the end of a sequence of repeated arguments.
<P>
<HR>
<H2><A NAME=S3>3. Input syntax</A></H2>
<H3><A NAME=S31>3.1. Basic syntax</A></H3>
<P>
The basic input syntax is very simple. A construct consists of an
identifier followed by a list of arguments, all enclosed in brackets
in a Lisp-like fashion. Each argument can be an identifier, a number,
a string, a blank, a bar, or another construct. There are further
restrictions on this basic syntax, described below.
<PRE>
construct : ( identifier arglist )
argument : construct
| identifier
| number
| string
| blank
| bar
arglist : (empty)
| argument arglist
</PRE>
<P>
The construct <CODE>( identifier )</CODE>, with an empty argument
list, is equivalent to the identifier argument <CODE>identifier</CODE>.
The two may be used interchangeably.
<H3><A NAME=S32>3.2. Sorts</A></H3>
<P>
Except at the outermost level, which forms a special case discussed
below, every construct and argument has an associated sort. This is
one of the basic TDF sorts: <CODE>access</CODE>, <CODE>al_tag</CODE>,
<CODE>alignment</CODE>, <CODE>bitfield_variety</CODE>, <CODE>bool</CODE>,
<CODE>callees</CODE>, <CODE>error_code</CODE>, <CODE>error_treatment</CODE>,
<CODE>exp</CODE>, <CODE>floating_variety</CODE>, <CODE>label</CODE>,
<CODE>nat</CODE>, <CODE>ntest</CODE>, <CODE>procprops</CODE>, <CODE>rounding_mode
</CODE>, <CODE>shape</CODE>, <CODE>signed_nat</CODE>, <CODE>string</CODE>,
<CODE>tag</CODE>, <CODE>transfer_mode</CODE>, <CODE>variety</CODE>,
<CODE>tdfint</CODE> or <CODE>tdfstring</CODE>.
<P>
Ignoring for the moment the shorthands discussed below, the ways of
creating constructs of sort <CODE>exp</CODE> say, correspond to the
TDF constructs delivering an <CODE>exp</CODE>. For example, <CODE>contents
</CODE> takes a <CODE>shape</CODE> and an <CODE>exp</CODE> and delivers
an <CODE>exp</CODE>. Thus:
<PRE>
( contents arg1 arg2 )
</PRE>
where <CODE>arg1</CODE> is an argument of sort <CODE>shape</CODE>
and <CODE>arg2</CODE> is an argument of sort <CODE>exp</CODE>, is
a sort-correct construct. Only constructs which are sort correct in
this sense are allowed.
<P>
As another example, because of the rule concerning constructs with
no arguments, both
<PRE>
( true )
</PRE>
and
<PRE>
false
</PRE>
are valid constructs of sort <CODE>bool</CODE>.
<P>
TDF constructs which take lists of arguments are easily dealt with.
For example:
<PRE>
( make_nof arg1 ... argn )
</PRE>
where <CODE>arg1</CODE>, ..., <CODE>argn</CODE> are all arguments
of sort <CODE>exp</CODE>, is valid. A vertical bar may be used to
indicate the end of a sequence of repeated arguments.
<P>
Optional arguments should be entered normally if they are present.
Their absence may be indicated by means of a blank (minus sign), or
by simply omitting the argument.
<P>
The vertical bar and blank should be used whenever the input is potentially
ambiguous. Particular care should be taken with <CODE>apply_proc</CODE>
(which is genuinely ambiguous) and <CODE>labelled</CODE>.
<P>
The TDF specification should be consulted for a full list of valid
TDF constructs and their argument sorts. Alternatively the <CODE>tnc</CODE>
help facility may be used. The command:
<PRE>
tnc -help cmd1 ... cmdn
</PRE>
prints sort information on the constructs or sorts <CODE>cmd1</CODE>,
..., <CODE>cmdn</CODE>. Alternatively:
<PRE>
tnc -help
</PRE>
prints this information for all constructs. (To obtain help on the
sort <CODE>alignment</CODE> as opposed to the construct <CODE>alignment</CODE>
use <CODE>alignment_sort</CODE>. This confusion cannot occur elsewhere.)
<H3><A NAME=S33>3.3. Numbers and strings</A></H3>
<P>
Numbers can occur in two contexts, as the argument to the TDF constructs
<CODE>make_nat</CODE> and <CODE>make_signed_nat</CODE>. In the former
case the number must be positive. The following shorthands are understood
by <CODE>tnc</CODE>:
<PRE>
number <I>for</I> ( make_nat number )
number <I>for</I> ( make_signed_nat number )
</PRE>
depending on whether a construct of sort <CODE>nat</CODE> or <CODE>signed_nat
</CODE> is expected.
<P>
Strings are nominally of sort <CODE>tdfstring</CODE>. They are taken
to be simple strings (8 bits per character). Multibyte strings (those
with other than 8 bits per character) may be represented by means
of the <CODE>multi_string</CODE> construct. This takes the form:
<PRE>
( multi_string b c1 ... cn )
</PRE>
where <CODE>b</CODE> is the number of bits per character and <CODE>c1</CODE>,
...,<CODE>cn</CODE> are the codes of the characters comprising the
string. These multibyte strings cannot be used as external names.
<P>
In addition, a simple (8 bit) string can be used as a shorthand for
a TDF construct of sort <CODE>string</CODE>, as follows:
<PRE>
string <I>for</I> ( make_string string )
</PRE>
<H3><A NAME=S34>3.4. Tokens, tags, alignment tags and labels</A></H3>
<P>
In TDF simple tokens, tags, alignment tags and labels are represented
by numbers which may, or may not, be associated with external names.
In <CODE>tnc</CODE> however they are represented by identifiers. This
brings the problem of scoping which does not occur in TDF. The rules
are that all tokens, tags, alignment tags and labels must be declared
before they are used. Externally defined objects have global scope,
and the scope of a formal argument in a token definition is the definition
body. For those constructs which introduce a local tag or label -
for example, <CODE>identify</CODE>, <CODE>make_proc</CODE>, <CODE>make_general_proc
</CODE> and <CODE>variable</CODE> for tags and <CODE>conditional</CODE>,
<CODE>labelled</CODE> and <CODE>repeat</CODE> for labels - the scope
of the object is as set out in the TDF specification.
<P>
The following shorthands are understood by <CODE>tnc</CODE>, according
to the argument sort expected:
<PRE>
tag_id <I>for</I> ( make_tag tag_id )
al_tag_id <I>for</I> ( make_al_tag al_tag_id )
label_id <I>for</I> ( make_label label_id )
</PRE>
<P>
The syntax for token applications is as follows:
<PRE>
( apply_construct ( token_id arg1 ... argn ) )
</PRE>
where <CODE>apply_construct</CODE> is the appropriate TDF token application
construct, for example, <CODE>exp_apply_token</CODE> for tokens declared
to deliver <CODE>exp</CODE>'s. The token arguments <CODE>arg1</CODE>,
..., <CODE>argn</CODE> must be of the sorts indicated in the token
declaration or definition. For tokens without any arguments the alternative
form:
<PRE>
( apply_construct token_id )
</PRE>
is allowed.
<P>
The token application above may be abbreviated to:
<PRE>
( token_id arg1 ... argn )
</PRE>
the result sort being known from the token declaration. This in turn
may be abbreviated to:
<PRE>
token_id
</PRE>
when there are no token arguments.
<P>
Care needs to be taken with these shorthands, as they can lead to
confusion, particularly when, due to optional arguments or lists of
arguments, <CODE>tnc</CODE> is not sure what sort is coming next.
The five categories of objects represented by identifiers - TDF constructs,
tokens, tags, alignment tags and labels - occupy separate name spaces,
but it is a good idea to try to avoid duplication of names.
<P>
By default all these shorthands are used by <CODE>tnc</CODE> in <B>write</B>
mode. If this causes problems, the <B>-V</B> flag should be passed
to <CODE>tnc</CODE>.
<P>
<HR>
<H2><A NAME=S35>3.5. Outer level syntax</A></H2>
<P>
At the outer level <CODE>tnc</CODE> is expecting a sequence of constructs
of the following forms:
<UL>
<LI>an included file,
<LI>a token declaration,
<LI>a token definition,
<LI>an alignment tag declaration,
<LI>an alignment tag definition,
<LI>a tag declaration,
<LI>a tag definition.
</UL>
<H3><A NAME=S36>3.6. Included files</A></H3>
<P>
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.
<P>
The syntax for an included text file is:
<PRE>
( include string )
</PRE>
where <CODE>string</CODE> is a string giving the pathname of the file
to be included. <CODE>tnc</CODE> applies <B>read</B> to this sub-file
before continuing with the present file.
<P>
Similarly, the syntaxes for included TDF capsules and libraries are:
<PRE>
( code string )
( lib string )
</PRE>
respectively. <CODE>tnc</CODE> applies <B>decode</B> to this capsule
or set of capsules (provided this mode is available) before continuing
with the present file.
<P>
The syntaxes for extracting the token declaration information from
a TDF capsule or library are:
<PRE>
( use_code string )
( use_lib string )
</PRE>
Again, these rely on the <B>decode</B> mode being available.
<H3><A NAME=S37>3.7. Internal and external names</A></H3>
<P>
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.
<P>
As an example of how <CODE>tnc</CODE> 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:
<PRE>
( make_tokdec token_id ... )
</PRE>
This creates a token with both internal and external names equal to
<CODE>token_id</CODE>. Alternatively:
<PRE>
( local make_tokdec token_id ... )
</PRE>
creates a token with internal name <CODE>token_id</CODE> but no external
name. This allows the creation of tokens local to the current file.
Again:
<PRE>
( make_tokdec ( string_extern string ) token_id ... )
</PRE>
creates a token with internal name <CODE>token_id</CODE> and external
name given by the string <CODE>string</CODE>. For example, to create
a token whose external name is not a valid identifier, it would be
necessary to use this construct. Finally:
<PRE>
( make_tokdec ( unique_extern string1 ... stringn ) token_id ... )
</PRE>
creates a token with internal name <CODE>token_id</CODE> and external
name given by the unique name consisting of the strings <CODE>string1</CODE>,
..., <CODE>stringn</CODE>.
<P>
The <CODE>local</CODE> 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.
<H3><A NAME=S38>3.8. Token declarations</A></H3>
<P>
The basic form of a token declaration is:
<PRE>
( make_tokdec token_id ( arg1 ... argn ) res )
</PRE>
where the token <CODE>token_id</CODE> is declared to take argument
sorts <CODE>arg1</CODE>, ..., <CODE>argn</CODE> and deliver the result
sort <CODE>res</CODE>. These sorts are given by their sort names,
<CODE>al_tag</CODE>, <CODE>alignment</CODE>, <CODE>bitfield_variety</CODE>
etc. For a token with no arguments the declaration may be given in
the form:
<PRE>
( make_tokdec token_id res )
</PRE>
A token may be declared any number of times, provided the declarations
are consistent.
<P>
This basic declaration may be modified in the ways outlined above
to specify the external token name.
<H3><A NAME=S39>3.9. Token definitions</A></H3>
<P>
The basic form of a token definition is:
<PRE>
( make_tokdef token_id ( arg1 id1 ... argn idn ) res def )
</PRE>
where the token <CODE>token_id</CODE> is defined to take formal arguments
<CODE>id1</CODE>, ..., <CODE>idn</CODE> of sorts <CODE>arg1</CODE>,
..., <CODE>argn</CODE> respectively and have the value <CODE>def</CODE>,
which is a construct of sort <CODE>res</CODE>. The scope of the tokens
<CODE>id1</CODE>, ..., <CODE>idn</CODE> is <CODE>def</CODE>.
<P>
For a token with no arguments the definition may be given in the form:
<PRE>
( make_tokdef token_id res def )
</PRE>
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).
<P>
This basic definition may be modified in the ways outlined above to
specify the external token name.
<H3><A NAME=S310>3.10. Alignment tag declarations</A></H3>
<P>
The basic form of an alignment tag declaration is:
<PRE>
( make_al_tagdec al_tag_id )
</PRE>
where the alignment tag <CODE>al_tag_id</CODE> is declared to exist.
<P>
This basic declaration may be modified in the ways outlined above
to specify the external alignment tag name.
<H3><A NAME=S311>3.11. Alignment tag definitions</A></H3>
<P>
The basic form of an alignment tag definition is:
<PRE>
( make_al_tagdef al_tag_id def )
</PRE>
where the alignment tag <CODE>al_tag_id</CODE> is defined to be <CODE>def</CODE>,
which is a construct of sort <CODE>alignment</CODE>. An alignment
tag may be declared or defined more than once, provided the definitions
are consistent.
<P>
This basic definition may be modified in the ways outlined above to
specify the external alignment tag name.
<H3><A NAME=S312>3.12. Tag declarations</A></H3>
<P>
The basic forms of a tag declaration are:
<PRE>
( make_id_tagdec tag_id info dec )
( make_var_tagdec tag_id info dec )
( common_tagdec tag_id info dec )
</PRE>
where the tag <CODE>tag_id</CODE> is declared to be an identity, variable
or common tag with access information <CODE>info</CODE>, which is
an optional construct of sort <CODE>access</CODE>, and shape <CODE>dec</CODE>,
which is a construct of sort <CODE>shape</CODE>. 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).
<P>
These basic declarations may be modified in the ways outlined above
to specify the external tag name.
<H3><A NAME=S313>3.13. Tag definitions</A></H3>
<P>
The basic forms of a tag definition are:
<PRE>
( make_id_tagdef tag_id def )
( make_var_tagdef tag_id info def )
( common_tagdef tag_id info def )
</PRE>
where the tag <CODE>tag_id</CODE> is defined to be an identity, variable
or common tag with value <CODE>def</CODE>, which is a construct of
sort <CODE>exp</CODE>. Non-identity tag definitions also have an optional
<CODE>access</CODE> construct, <CODE>info</CODE>. 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.
<P>
These basic definitions may be modified in the ways outlined above
to specify the external tag name.
<P>
<HR>
<H2><A NAME=S4>4. Shape checking</A></H2>
<P>
The input in <B>read</B> (and to a lesser extent <B>decode</B>) mode
is checked for shape correctness if the <B>-check</B> or <B>-c</B>
flag is passed to <CODE>tnc</CODE>. This is not guaranteed to pick
up all shape errors, but is better than nothing.
<P>
When in <B>write</B> mode the results of the shape checking may be
viewed by passing the <B>-cv</B> flag to <CODE>tnc</CODE>. Each expression
is associated with its shape by means of the:
<PRE>
( exp_with_shape exp shape ) -> exp
</PRE>
pseudo-construct. Unknown shapes are indicated by <CODE>....</CODE>
<P>
<HR>
<H2><A NAME=S5>5. Remarks</A></H2>
<P>
The target independent TDF capsules produced by the C -> TDF compiler,
<CODE>tcc</CODE>, do not contain declarations or definitions for all
the tokens they use. Thus <CODE>tnc</CODE> cannot fully decode them
as they stand. However the necessary token declaration information
may be made available to <CODE>tnc</CODE> by using the <B>use_lib</B>
construct. The commands:
<PRE>
( use_lib library )
( code capsule )
</PRE>
will decode the TDF capsule <CODE>capsule</CODE> which uses tokens
defined in the TDF library <CODE>library</CODE>.
<P>
<HR>
<H2><A NAME=S6>6. Limitations</A></H2>
<P>
The main limitations in the current version of <CODE>tnc</CODE> are
as follows:
<UL>
<LI>There is no error recovery,
<LI>There is no support for foreign sorts,
<LI>The support for tokenised tokens is limited and undocumented.
</UL>
<P>
In addition, far more of the checks (scopes, shape checking, checking
of consistency of declarations and definitions etc.) are implemented
for <B>read</B> mode rather than <B>decode</B> mode. To shape check
a TDF capsule, it will almost certainly be more effective to translate
it into text and check that.
<P>
Another limitation is that the scoping rules for local tags do not
allow such tags to be accessed outside their scopes using <CODE>env_offset
</CODE>.
<P>
<HR>
<H2><A NAME=S7>7. Manual Page for tnc</A></H2>
<P>
Here is the manual page for tnc.
<P>
<B>NAME</B>: <CODE>tnc</CODE> - TDF notation compiler
<P>
<B>SYNOPSIS</B>: <CODE>tnc [ options ] input-file [ output-file ]</CODE>
<P>
<B>DESCRIPTION</B>: <CODE>tnc</CODE> translates TDF capsules to and
from text. It has two input modes, <B>read</B> and <B>decode</B>.
In the first, which is default, <CODE>input-file</CODE> is a file
containing TDF text. In the second <CODE>input-file</CODE> is a TDF
capsule. There are also two output modes, <B>encode</B> and <B>write</B>.
In the first, which is default, a TDF capsule is written to <CODE>output-file
</CODE> (or the standard output if this argument is absent). In the
second, TDF text is written to <CODE>output-file</CODE>.
<P>
Combination of these modes give four actions: text to TDF (which is
default), TDF to text, text to text and TDF to TDF. The last two actions
are not precise identities, but they do give equivalent files.
<P>
The form of the TDF text format and more information about <CODE>tnc</CODE>
can be found in the document <I>The TDF Notation Compiler</I>.
<P>
<B>OPTIONS</B>:
<P>
<B>-c</B> or <B>-cv</B> or <B>-check</B>
Specifies that <CODE>tnc</CODE> should apply extra checks to <CODE>input-file
</CODE>. For example, simple shape checking is applied. These checks
are more efficient in <B>read</B> mode than in <B>decode</B> mode.
If the <B>-cv</B> option is used in <B>write</B> mode, all the information
gleaned from the shape checking appears in <CODE>output-file</CODE>.
<P>
<B>-d</B> or <B>-decode</B>
Specifies that <CODE>tnc</CODE> should be in <B>decode</B> mode. That
is, that <CODE>input-file</CODE> is a TDF capsule.
<P>
<B>-e</B> or <B>-encode</B>
Specifies that <CODE>tnc</CODE> should be in <B>encode</B> mode. That
is, that <CODE>output-file</CODE> is a TDF capsule.
<P>
<B>-help</B> <CODE>subject</CODE> ... Makes <CODE>tnc</CODE> print
its help message on the given subject(s). If no subject is given,
all the help messages are printed.
<P>
<B>-I</B><CODE>dir</CODE>
Adds the directory <CODE>dir</CODE> to the search path used by <CODE>tnc</CODE>
to find included files in <B>read</B> mode.
<P>
<B>-l</B> or <B>-lib</B>
In <B>decode</B> mode, specifies that <CODE>input-file</CODE> is not
a TDF capsule, but a TDF library. All the capsules comprising the
library are decoded.
<P>
<B>-o</B> <CODE>output-file</CODE>
Gives an alternative method of specifying the output file.
<P>
<B>-p</B> or <B>-print</B>
Specifies that <CODE>tnc</CODE> should be in <B>decode</B> and <B>write</B>
modes. That is, that <CODE>input-file</CODE> is a TDF capsule and
<CODE>output-file</CODE> should consist of TDF text. This option makes
<CODE>tnc</CODE> into a TDF pretty-printer.
<P>
<B>-q</B>
Specifies that <CODE>tnc</CODE> should not check duplicate tag declarations
etc for consistency, but should use the first declaration given.
<P>
<B>-r</B> or <B>-read</B>
Specifies that <CODE>tnc</CODE> should be in <B>read</B> mode. That
is, that <CODE>input-file</CODE> should consist of TDF text.
<P>
<B>-V</B>
In <B>write</B> mode, specifies that the output should be in the "verbose"
form, with no shorthand forms.
<P>
<B>-version</B>
Makes <CODE>tnc</CODE> print its version number.
<P>
<B>-w</B> or <B>-write</B>
Specifies that <CODE>tnc</CODE> should be in <B>write</B> mode. That
is, that <CODE>output-file</CODE> should consist of TDF text.
<P>
<B>SEE ALSO</B>: <I>tdf</I>(1tdf).
<P>
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright © 1998.</I></P>
</BODY>
</HTML>