Blame | Last modification | View Log | RSS feed
<!-- Crown Copyright (c) 1998 -->
<HTML>
<HEAD>
<TITLE>PL_TDF Definition</TITLE>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000FF" VLINK="#400080" ALINK="#FF0000">
<A NAME=S6>
<H1>PL_TDF Definition</H1>
<H3>January 1998</H3>
<A HREF="pl5.html"><IMG SRC="../images/next.gif" ALT="next section">
</A> <A HREF="pl3.html">
<IMG SRC="../images/prev.gif" ALT="previous section"></A>
<A HREF="pl1.html"><IMG SRC="../images/top.gif" ALT="current document"></A>
<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="#S7"><B>3.1 </B> - Program</A><DD>
<DL>
<DT><A HREF="#S8"><B>3.1.1 </B> - Tokdec</A><DD>
<DT><A HREF="#S9"><B>3.1.2 </B> - Tokdef</A><DD>
<DT><A HREF="#S10"><B>3.1.3 </B> - Tagdec</A><DD>
<DT><A HREF="#S11"><B>3.1.4 </B> - Tagdef</A><DD>
<DT><A HREF="#S12"><B>3.1.5 </B> - Altagdef</A><DD>
<DT><A HREF="#S13"><B>3.1.6 </B> - Structdef</A><DD>
<DT><A HREF="#S14"><B>3.1.7 </B> - Procdef</A><DD>
</DL>
<DT><A HREF="#S15"><B>3.2 </B> - First-class SORT expansions</A><DD>
<DL>
<DT><A HREF="#S16"><B>3.2.1 </B> - Access</A><DD>
<DT><A HREF="#S17"><B>3.2.2 </B> - Al_tag</A><DD>
<DT><A HREF="#S18"><B>3.2.3 </B> - Alignment</A><DD>
<DT><A HREF="#S19"><B>3.2.4 </B> - Bitfield_variety</A><DD>
<DT><A HREF="#S20"><B>3.2.5 </B> - Bool</A><DD>
<DT><A HREF="#S21"><B>3.2.6 </B> - Error_treatment</A><DD>
<DT><A HREF="#S22"><B>3.2.7 </B> - Exp</A><DD>
<DT><A HREF="#S23"><B>3.2.7.1 </B> - ExpTerm</A><DD>
<DT><A HREF="#S24"><B>3.2.8 </B> - Floating_variety</A><DD>
<DT><A HREF="#S25"><B>3.2.9 </B> - Label</A><DD>
<DT><A HREF="#S26"><B>3.2.10 </B> - Nat</A><DD>
<DT><A HREF="#S27"><B>3.2.11 </B> - Ntest</A><DD>
<DT><A HREF="#S28"><B>3.2.12 </B> - Rounding_mode</A><DD>
<DT><A HREF="#S29"><B>3.2.13 </B> - Shape</A><DD>
<DT><A HREF="#S30"><B>3.2.14 </B> - Signed_Nat</A><DD>
<DT><A HREF="#S31"><B>3.2.15 </B> - String</A><DD>
<DT><A HREF="#S32"><B>3.2.16 </B> - Tag</A><DD>
<DT><A HREF="#S33"><B>3.2.17 </B> - Token</A><DD>
<DT><A HREF="#S34"><B>3.2.18 </B> - Transfer_mode</A><DD>
<DT><A HREF="#S35"><B>3.2.19 </B> - Variety</A><DD>
</DL>
<DT><A HREF="#S36"><B>3.3 </B> - Control structure and local declarations</A>
<DD>
<DL>
<DT><A HREF="#S37"><B>3.3.1 </B> - ConditionalExp and Assertion</A><DD>
<DT><A HREF="#S38"><B>3.3.2 </B> - RepeatExp</A><DD>
<DT><A HREF="#S39"><B>3.3.3 </B> - LabelledExp</A><DD>
<DT><A HREF="#S40"><B>3.3.4 </B> - Local_Defn</A><DD>
</DL>
</DL>
<HR>
<H1>3 The Language</H1>
The basic philosophy of PL_TDF is to provide the "glue"
constructors of TDF automatically, while still allowing the programmer
to use the significant constructors in their most general form. By
"glue" constructors, I mean those like make_link, make_group
etc. which are there to provide tedious, but vital, constructions
concerned with linking and naming. The "significant" constructors
really come in two groups, depending on their resulting SORTs. There
are those SORTs like TOKDEC, whose SORTs are purely syntactic and
can't be used as results of token applications or _cond constructions.
On the other hand, the first-class SORTs, like EXP, can be used in
those situations and generally have a much richer set of constructors.
These first-class SORTs are precisely those which have SORTNAMEs.
These SORTNAMEs appear in PL_TDF as expansions of <Sortname>:
<PRE>
<Sortname> ::= ACCESS
<Sortname> ::= AL_TAG
<Sortname> ::= ALIGNMENT
<Sortname> ::= BITFIELD_VARIETY
<Sortname> ::= BOOL
<Sortname> ::= ERROR_TREATMENT
<Sortname> ::= EXP
<Sortname> ::= FLOATING_VARIETY
<Sortname> ::= LABEL
<Sortname> ::= NAT
<Sortname> ::= NTEST
<Sortname> ::= ROUNDING_MODE
<Sortname> ::= SHAPE
<Sortname> ::= SIGNED_NAT
<Sortname> ::= STRING
<Sortname> ::= TAG
<Sortname> ::= TRANSFER_MODE
<Sortname> ::= VARIETY
</PRE>
All of the significant constructors are expanded by non-terminals
with names related to their resulting SORT e.g. all EXPs are expanded
by <Exp> and all TOKDECs are expanded by <Tokdec>. Any
first-class SORT can be expanded by using the constructor names given
in the TDF specification, provided that the parameter SORTs are also
first-class. For example, the following are all valid expansions of
<Exp> :
<PRE>
make_top
return(E) where E is an expansion of <Exp>
goto(L) where L is an expansion of <Label>
assign(E1, E2) where E1 and E2 are expansions of <Exp>
</PRE>
Any such use of TDF constructors will be checked for the SORT-correctness
of their parameters. I will denote such a constructor as an <exp_constructor>;
similarly for all the other first-class sorts.<P>
Any of the first-class sorts may also be expanded by a token application.
Tokens in PL_TDF are given <ident> names by <Tokdef> or
<Tokdec> which must occur before their use in applications.
In applications, these names will be denoted by <exp_token>,
<shape_token> etc. , depending on the result sort of their introduction.
<P>
The principle of "no use before declaration" also applies
to <ident> names given to TAGs. <P>
<A NAME=S7>
<HR><H2>3.1. Program</H2>
The root expansion of a PL_TDF program is given by <Program>:
<PRE>
<Program> ::= <ElementList> Keep ( <Item>-List-Opt )
<ElementList> ::= <Element> ;
<ElementList> ::= <Element> ; <ElementList>
<Element> ::= <Tokdec>
<Element> ::= <Tokdef>
<Element> ::= <Tagdec>
<Element> ::= <Tagdef>
<Element> ::= <Altagdef>
<Element> ::= <Structdef>
<Element> ::= <Procdef>
<Item> ::= <tag>
<Item> ::= <token>
<item> ::= <altag>
</PRE>
A <Program> consists of a list of definitions and declarations
giving meaning to various <ident>s, as TAGs, TOKENs and AL_TAGs.
The <Item>-List-Opt indicates which of these names will be externally
available via CAPSULE_LINKs; in addition any other names which are
declared but not defined will also be linked externally.<P>
A <Program> will produce a single TDF CAPSULE.<P>
<A NAME=S8>
<H3>3.1.1. Tokdec</H3>
A <Tokdec> introduces an <ident> as a TOKEN:
<PRE>
<Tokdec> ::= Tokdec <ident><Signature>: [ <TokDecPar>-List-Opt ] <ResultSort>
<ResultSort> ::= <Sortname>
<TokDecPar> ::= <Sortname>
<TokDecPar> ::= TOKEN [ <TokDecPar>-List-Opt ] <ResultSort>
<Signature> ::= <String>-Opt
</PRE>
This produces a TOKDEC in a tokdec UNIT of the CAPSULE. Further uses
of the introduced <ident> will be treated as a <x-token>
where x is given by the <ResultSort>.<P>
<A NAME=S9>
<H3>3.1.2. <A NAME=3>Tokdef</H3>
A <Tokdef> defines an <ident> as a TOKEN; this <ident>
may have previously been introduced by a <Tokdec>:
<PRE>
<Tokdef> ::= Tokdef <ident><Signature> = <Tok_Defn>
<Tok_Defn> ::= [ <TokDefPar>-List-Opt ] <ResultSort> <result_sort>
<TokDefPar> ::= <ident> : <TokDecPar>
<Signature> ::= <String>-Opt
</PRE>
This produces a TOKDEF in a tokdef UNIT of the CAPSULE. The expansion
of <result_sort> depends on <ResultSort>, e.g. if <ResultSort>
is EXP then <result_sort> ::= <Exp> and so on.<P>
Each of the <ident>s in the <TokDefPar>s will be names
for tokens whose scope is <result_sort>. A use of such a name
within its scope will be expanded as a parameterless token application
of the appropriate sort given by its <TokDecPar>. Note that
this is still true if the <TokDecPar> is a TOKEN - if a <TokDefPar>
is:
<PRE>
x: TOKEN[ LABEL ]EXP
</PRE>
then x[L] is expanded as:
<PRE>
exp_apply_token( token_apply_token(x, ()), L)
</PRE>
<Tok_defn> also occurs in an expansion of <Token>, as
a parameter of a token application.<P>
<A NAME=S10>
<H3>3.1.3. Tagdec</H3>
A <Tagdec> introduces an <ident> as a TAG:
<PRE>
<Tagdec> ::= <DecType> <ident> <Signature> <Access>-Opt : <Shape>
<DecType> ::= Vardec
<DecType> ::= Iddec
<DecType> ::= Commondec
<Signature> ::= <String>-Opt
</PRE>
This produces a TAGDEC in a tagdec UNIT of the CAPSULE, using a make_id_tagdec
for the Iddec option, a make_var_tagdec for the Vardec option and
a common_tagdec for the Commondec option. <P>
The <Shape>s in both <Tagdec>s and <Tagdef>s will
produce SHAPE TOKENs in a tagdef UNIT; these may be applied in various
shorthand operations on TAG <ident>s.<P>
<A NAME=S11>
<H3>3.1.4. Tagdef</H3>
A <Tagdef> defines an <ident> as a TAG. This <ident>
may have previously been introduced by a <Tagdec>; if it has
not the < : <Shape> >-Opt below must not be empty and
a TAGDEC will be produced for it.<P>
<PRE>
<Tagdef> ::= Var <ident><Signature> < : <Shape> >-Opt < = <Exp>>-Opt
</PRE>
Produces a make_var_tagdef.<P>
<PRE>
<Tagdef> ::= Common <ident> <Signature>< : <Shape> >-Opt < = <Exp> >-Opt
</PRE>
Produces a common_tagdef.<P>
<PRE>
<Tagdef> ::= Let <ident><Signature> < : <Shape> >-Opt = <Exp>
</PRE>
Produces a make_id_tagdef.<P>
<PRE>
<Tagdef> ::= String <ident> <Variety>-Opt =<string>
</PRE>
This is a shorthand for producing names which have the properties
of C strings. The <Variety>-Opt gives the variety of the characters
with the string, an empty option giving unsigned chars. The TDF produced
is a make_var_tagdef initialised by a make_nof_int. This means that
given a String definition:
<PRE>
String format = "Result = %d\n"
</PRE>
the tag <ident>, format, could be used straightforwardly as
the first parameter of printf - see <A HREF="pl5.html#0">Section 4
(Example PL_TDF programs)</A>.<P>
<A NAME=S12>
<H3>3.1.5. Altagdef</H3>
An <Altagdef> defines an <ident> as an AL_TAG:
<PRE>
<Altagdef> ::= Al_tagdef <ident> = <Alignment>
</PRE>
This produces an AL_TAGDEF in an al_tagdef UNIT of the CAPSULE. The
<ident> concerned can be previously used in as an expansion
of <Alignment>.<P>
<A NAME=S13>
<H3>3.1.6. Structdef</H3>
A <Structdef> defines a TOKEN for a structure SHAPE, together
with two TOKENs for each field of the structure to allow easy access
to the offsets and contents of the field:
<PRE>
<Structdef> ::= Struct <Structname> ( <Field>-List )
<Structname> ::= <ident>
<Field> ::= <Fieldname> : <Shape>
<Fieldname> ::= <ident>
</PRE>
This produces a TOKDEF in a tokdef UNIT defining <Structname>
as a SHAPE token whose expansion is an EXP OFFSET(a1,a2) where the
OFFSET is the size of the structure with standard TDF padding and
offset addition of the component SHAPEs and sizes (note that this
may not correspond precisely with C sizes).<P>
<P>
</BODY>
Each <Fieldname> will produce two TOKENs. The first is named
by <Fieldname> itself and is a [EXP]EXP which gives the value
of the field of its structure parameter. The second is named by prefixing
<Fieldname> by the.-symbol and is an [ ]EXP giving the OFFSET
of the field from the start of the structure. Thus given:
<PRE>
Struct Complex (re: Double, im: Double)
</PRE>
Complex is a TOKEN for a SHAPE defining two Doubles; re[E] and im[E]
will extract the components of E where E is an EXP of shape Complex;
.re and.im give EXP OFFSETs of the the two fields from the start of
the structure.<P>
<A NAME=S14>
<H3>3.1.7. <A NAME=12>Procdef</H3>
A <Procdef> defines a TAG to be a procedure; it is simply an
abreviation of a an Iddec <Tagdef>:
<PRE>
<Procdef> ::= Proc <ident> = <Proc_Defn>
<Proc_Defn> ::= <Simple_Proc>
<Proc_Defn> ::= <General_Proc>
<Simple_Proc> ::= <Shape> ( <TagShAcc>-List-Opt <VarIntro>-Opt ) <ClosedExp>
<TagShAcc> ::= <Parametername> <Access>-Opt : <Shape>
<Parametername> ::= <ident>
<VarIntro> ::= Varpar <Varparname> : <Alignment>
<Varparname> ::= <ident>
</PRE>
<P>
<PRE>
<General_Proc> ::= General <Shape> ( <For_Callers>; <For_Callees>) <ProcProps>-Opt <ClosedExp>
<For_Callers> ::= <TagShAcc>-List-Opt <...>-Opt
<For_Callees> ::= <TagShAcc>-List-Opt <...>-Opt
<ProcProps> ::= <untidy>-Opt <check_stack>-Opt
</PRE>
A <Procdef> produces a TAGDEF in a tagdef UNIT and and, possibly,
a TAGDEC in a tagdef UNIT. <P>
A <Simple_Proc> produces a make_proc with the obvious operands.
The scope of the tag names introduced by <Parametername> and
<Varparname> is the <ClosedExp> (see <A HREF="#86">section
3.3</A>).<P>
A <General_Proc> produces a make_general_proc with formal caller
parameters given by <For_callers> and the formal callee parameters
given by <For_callees>; in both cases the <...> option
says that the procedure can be called with a variable number of parameters.
The scope of the tag names are the same as for <Simple_Proc>.<P>
<P>
<A NAME=S15>
<HR><H2>3.2. First-class SORT expansions</H2>
All of the first-class sorts have similar expansions for native TDF
constructions and for token applications. I shall take <Shape>
as the paradigm sort and allow the reader to conjugate the following
for the the other sorts.<P>
Those first-class sorts which include the _cond constructions denote
them in the same way:
<PRE>
<Shape> ::= SHAPE ? ( <Exp>, <Shape>, <Shape> )
</PRE>
This produces a shape_cond with the obvious parameters.<P>
Each constructor for <Shape> with parameters which are first-class
sorts can be expanded:
<PRE>
<Shape> ::= <shape_constructor> < ( <constructor_param>-List ) >-Opt
</PRE>
Each <constructor_param> will be the first_class SORT expansion,
required by the <shape_constructor> as in the TDF specification
eg the constructor, pointer, requires a <constructor_param>
::= <Alignment>.<P>
Any <ident> which is declared to be a <shape_token> by
a TOKDEF or TOKDEC can be expanded:
<PRE>
<Shape> ::= <shape_token> < [ <token_param>-List ] >-Opt
</PRE>
This will produce a shape_apply_token with the appropriate parameters.
Each <token_param> will be the first-class SORT expansion required
by the SORT given by the <TokDecPar> of the TOKDEF or TOKDEC
which introduced <shape_token>.<P>
<A NAME=S16>
<H3>3.2.1. Access</H3>
<PRE>
<Access> ::= ACCESS ? ( <Exp> , <Access> , <Access> )
<Access> ::= <access_constructor> < ( <constructor_param>-List ) >-Opt
<Access> ::= <access_token> < [ <token_param>-List ] >-Opt
</PRE>
There are no expansions of <Access> other than the standard
ones.<P>
<A NAME=S17>
<H3>3.2.2. Al_tag</H3>
<PRE>
<Al_tag> ::= <al_tag_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard token expansion.<P>
<PRE>
<Al_tag> ::= <ident>
</PRE>
Any <ident> found as an expansion of <Al_tag> will be
declared as the name for an AL_TAG.<P>
<A NAME=S18>
<H3>3.2.3. Alignment</H3>
<PRE>
<Alignment> ::= ALIGNMENT ? ( <Exp> , <Alignment> , <Alignment> )
<Alignment> ::= <alignment_constructor> < ( <constructor_param>-List ) >-Opt
<Alignment> ::= <alignment_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard expansions.<P>
<PRE>
<Alignment> ::= <Al_tag>
</PRE>
This results in an obtain_al_tag of the AL_TAG.<P>
<PRE>
<Alignment> ::= ( <Alignment>-List-Opt )
</PRE>
The <Alignment>s in the <Alignment>-List are united using
unite_alignments. The empty option results in the top ALIGNMENT.<P>
<A NAME=S19>
<H3>3.2.4. Bitfield_variety</H3>
<PRE>
<Bitfield_variety> ::= BITFIELD_VARIETY ? ( <Exp> , <Bitfield_variety>, <Bitfield_variety>)
<Bitfield_variety> ::= <bitfield_variety_constructor> < ( <constructor_param>-List ) >-Opt
<Bitfield_variety> ::= <bitfield_variety__token> < [ <token_param>-List ] >-Opt
</PRE>
The standard expansions.<P>
<PRE>
<Bitfield_variety> ::= <BfSign>-Opt <Nat>
<BfSign> ::= <Bool>
<BfSign> ::= Signed
<BfSign> ::= Unsigned
</PRE>
This expands to bfvar_bits. The empty default on the sign is Signed.<P>
<A NAME=S20>
<H3>3.2.5. Bool</H3>
<PRE>
<Bool> ::= BOOL ? ( <Exp> , <Bool>, <Bool>)
<Bool> ::= <bool_constructor> < ( <constructor_param>-List ) >-Opt
<Bool> ::= <bool_token> < [ <token_param>-List ] >-Opt
</PRE>
There are no expansions of <Bool> other than the standard ones.<P>
<A NAME=S21>
<H3>3.2.6. Error_treatment</H3>
<PRE>
<Error_treatment> ::= ERROR_TREATMENT ?
( <Exp> , <Error_treatment>, <Error_treatment>)
<Error_treatment> ::= <error_treatment_constructor> < ( <constructor_param>-List ) >-Opt
<Error_treatment> ::= <error_treatment__token> < [ <token_param>-List ] >-Opt
</PRE>
The standard expansions.<P>
<PRE>
<Error_treatment> ::= <Label>
</PRE>
This gives an error_jump to the label.<P>
<P>
<PRE>
<Error_treatment> ::= [ <Error_code>-List]
<Error_code> ::= overflow
<Error_code> ::= nil_access
<Error_code> ::= stack_overflow
</PRE>
Produces trap with the <Error_code>s as arguments.<P>
<A NAME=S22>
<H3>3.2.7. <A NAME=26>Exp</H3>
<PRE>
<Exp> ::= <ExpTerm>
<Exp> ::= <ExpTerm> <BinaryOp> <ExpTerm>
</PRE>
The <BinaryOp>s include the arithmetic, offset, logical operators
and assignment and are given in table 1. In this expansion, any error_treatments
are taken to be wrap.
<P>
<CENTER>
<IMG SRC="table1.gif">
</CENTER>
<P>
The names like *+. (i.e. add_to_ptr) do have a certain logic; the
* indicates that the left operand must be a pointer expression and
the. that the other is an offset<P>
The further expansions of <Exp> are all <ExpTerm>s<P>
<A NAME=S23>
<H4>3.2.7.1. ExpTerm</H4>
<PRE>
<ExpTerm> ::= EXP ? ( <Exp> , <Exp>, <Exp>)
<ExpTerm> ::= <exp_constructor> < ( <constructor_param>-List ) >-Opt
<ExpTerm> ::= <exp_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard expansions.<P>
<P>
<PRE>
<ExpTerm> ::= <ClosedExp>
</PRE>
For <ClosedExp>, see <A HREF="#86">section 3.3</A>.<P>
<P>
<PRE>
<ExpTerm> ::= ( <Exp> )
<ExpTerm> ::= - ( <Exp> )
</PRE>
The negate constructor.<P>
<P>
<PRE>
<ExpTerm> ::= Sizeof ( <Shape> )
</PRE>
This produces the EXP OFFSET for an index multiplier for arrays of
<Shape>. It is the shape_offset of <Shape> padded up to
its alignment.<P>
<P>
<PRE>
<ExpTerm> ::= <Tag>
</PRE>
This produces an obtain_tag.<P>
<P>
<PRE>
<ExpTerm> ::= * <ident>
</PRE>
The <ident> must have been declared as a variable TAG and the
construction produces a contents operation with its declared SHAPE.<P>
<P>
<PRE>
<ExpTerm> ::= * ( <Shape> ) <ExpTerm>
</PRE>
This produces a contents operation with the given <Shape>.<P>
<P>
<PRE>
<ExpTerm> ::= <Assertion>
</PRE>
For <Assertion>, see <A HREF="#89">section 3.3.1</A><P>
<P>
<PRE>
<ExpTerm> ::= Case <Exp> ( <RangeDest>-List )
<RangeDest> ::= <Signed_Nat> < : <Signed_Nat> >-Opt -> <Label>
</PRE>
This produces a case operation.<P>
<P>
<PRE>
<ExpTerm> ::= Cons [ <Exp> ] ( < <Offset> : <Exp> >-List )
<Offset> ::= <Exp>
</PRE>
This produces a make_compound with the [ <Exp> ] as the size
and fields given by < <Offset> : <Exp> >-List.<P>
<P>
<PRE>
<ExpTerm> ::= [ <Variety> ] <ExpTerm>
</PRE>
This produces a change_variety with a wrap error_treatment.
<P>
<P>
<PRE>
<ExpTerm> ::= <Signed_Nat> ( <Variety> )
</PRE>
This produces a make_int of the <Signed_Nat> with the given
variety.<P>
<P>
<PRE>
<ExpTerm> ::= <floating_denotation> < E <Signed_Nat> >-Opt <Rounding_Mode>-Opt
<ExpTerm> ::= - <floating_denotation> < E <Signed_Nat> >-Opt <Rounding_Mode>-Opt
</PRE>
Produces a make_floating.<P>
<P>
<PRE>
<ExpTerm> ::= <ProcVal> [ <Shape> ] ( <Exp>-List-Opt < Varpar <Exp> >-Opt)
<ProcVal> ::= <Tag>
<ProcVal> ::= ( <Exp> )
</PRE>
Produces an apply_proc with the given parameters returning the given
<Shape>. <P>
<P>
<PRE>
<ExpTerm> ::= <ProcVal> [ <Shape> ]
[ <Act_Callers>-Opt ; <Act_Callees>-Opt <; <Postlude>>-Opt ]
<ProcProps>-Opt
<Act_Callers> ::= <<Exp> <: <ident>>-Opt>-List <...>-Opt
<Act_Callees> ::= <Exp>-List <...>-Opt
<Act_Callees> ::= Dynamic ( <Exp> , <Exp> ) <...>-Opt
<Act_Callees> ::= Same
<Postlude> ::= <Exp>
</PRE>
Produces an apply_general_proc with the actual caller parameters given
by <Act_Callers> and the calle parameters given by <Act_Callees>;
the <...> option indicates that the procedure is expecting a
variable number of parameters. Any <ident>s introduced in <Act_Callers>
are in scope in <Postlude>.<P>
<P>
<PRE>
<Exp> ::= <ProcVal> Tail_call [ <Act_Callees>-Opt ]
</PRE>
Produces a tail_call with the callee parameters given and same caller
parameters as those of the calling procedure.<P>
<P>
<P>
<PRE>
<ExpTerm> ::= Proc <Proc_defn>
</PRE>
Produces a make_proc. For <Proc_defn>, see
<A HREF="#12">section 3.1.7</A><P>
<P>
<PRE>
<ExpTerm> ::= <String> ( <Variety> )
</PRE>
Produces a make_nof_int of the given variety.<P>
<P>
<PRE>
<ExpTerm> ::= # <String>
</PRE>
This produces a TDF fail_installer; this construction is useful for
narrowing down SHAPE errors detected by the translator.<P>
<A NAME=S24>
<H3>3.2.8. Floating_variety</H3>
<PRE>
<Floating_variety> ::= FLOATING_VARIETY ?
( <Exp> , <Floating_variety>, <Floating_variety>)
<Floating_variety> ::= <floating_variety_constructor> < ( <constructor_param>-List ) >-Opt
<Floating_variety> ::= <floating_variety__token> < [ <token_param>-List ] >-Opt
</PRE>
The standard constructions.<P>
<PRE>
<Floating_variety> ::= Float
</PRE>
An IEEE 32 bit floating variety.<P>
<PRE>
<Floating_variety> ::= Double
</PRE>
An IEEE 64 bit floating variety.<P>
<A NAME=S25>
<H3>3.2.9. Label</H3>
<PRE>
<Label> ::= <label_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard token application.<P>
<PRE>
<Label> ::= <ident>
</PRE>
The <ident> will be declared as a LABEL, whose scope is the
current procedure.<P>
<A NAME=S26>
<H3>3.2.10. Nat</H3>
<PRE>
<Nat> ::= NAT ? ( <Exp> , <Nat>, <Nat>)
<Nat> ::= <nat_constructor> < ( <constructor_param>-List ) >-Opt
<Nat> ::= <nat_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard expansions.<P>
<PRE>
<Nat> ::= <integer_denotation>
</PRE>
Produces a make_nat on the integer<P>
<PRE>
<Nat> ::= <character>
</PRE>
Produces a make_nat on the ASCII value of the character.<P>
<A NAME=S27>
<H3>3.2.11. Ntest</H3>
<PRE>
<Ntest> ::= NTEST ? ( <Exp> , <Ntest>, <Ntest>)
<Ntest> ::= <ntest_constructor> < ( <constructor_param>-List ) >-Opt
<Ntest> ::= <ntest_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard expansions.<P>
<PRE>
<Ntest> ::= !<
</PRE>
Produces not_less_than.<P>
<PRE>
<Ntest> ::= !<=
</PRE>
Produces not_less_than_or_equal.<P>
<PRE>
<Ntest> ::= !=
</PRE>
Produces not_equal.<P>
<PRE>
<Ntest> ::= !>
</PRE>
Produces not_greater_than.<P>
<PRE>
<Ntest> ::= !>=
</PRE>
Produces not_greater_than_or_equal.<P>
<PRE>
<Ntest> ::= !Comparable
</PRE>
Produces not_comparable.<P>
<PRE>
<Ntest> ::= <
</PRE>
Produces less_than.<P>
<PRE>
<Ntest> ::= <=
</PRE>
Produces less_than_or_equal.<P>
<PRE>
<Ntest> ::= ==
</PRE>
Produces equal.<P>
<PRE>
<Ntest> ::= >
</PRE>
Produces greater_than.<P>
<PRE>
<Ntest> ::= >=
</PRE>
Produces greater_than_or_equal.<P>
<P>
<A NAME=S28>
<H3>3.2.12. Rounding_mode</H3>
<PRE>
<Rounding_mode> ::= ROUNDING_MODE?
( <Exp> , <Rounding_mode>, <Rounding_mode>)
<Rounding_mode> ::= <ntest_constructor> < ( <constructor_param>-List ) >-Opt
<Rounding_mode> ::= <ntest_token> < [ <token_param>-List ] >-Opt
</PRE>
There are no constructions for <Rounding_mode> other than the
standard ones.<P>
<A NAME=S29>
<H3>3.2.13. Shape</H3>
<PRE>
<Shape> ::= SHAPE ? ( <Exp> , <Shape>, <Shape>)
<Shape> ::= <shape_constructor> < ( <constructor_param>-List ) >-Opt
<Shape> ::= <shape_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard expansions.<P>
<PRE>
<Shape> ::= Float
</PRE>
The shape for an IEEE 32 bit float.<P>
<PRE>
<Shape> ::= Double
</PRE>
The shape for an IEEE 64 bit float.<P>
<PRE>
<Shape> ::= <Sign>-Opt Int
<Sign> ::= Signed
<Sign> ::= Unsigned
</PRE>
The shape for a 32 bit signed or unsigned integer. The default is
signed.<P>
<PRE>
<Shape> ::= <Sign>-Opt Long
</PRE>
The shape for a 32 bit signed or unsigned integer.<P>
<PRE>
<Shape> ::= <Sign>-Opt Short
</PRE>
The shape for a 16 bit signed or unsigned integer.<P>
<PRE>
<Shape> ::= <Sign>-Opt Char
</PRE>
The shape for a 8 bit signed or unsigned integer.<P>
<PRE>
<Shape> ::= Ptr <Shape>
</PRE>
The SHAPE pointer(alignment(<Shape>)).<P>
<A NAME=S30>
<H3>3.2.14. Signed_Nat</H3>
<PRE>
<Signed_Nat> ::= SIGNED_NAT ? ( <Exp> , <Signed_Nat>, <Signed_Nat>)
<Signed_Nat> ::= <signed_nat_constructor> < ( <constructor_param>-List ) >-Opt
<Signed_Nat> ::= <signed_nat_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard expansions.<P>
<PRE>
<Signed_Nat> ::= <integer_denotation>
<Signed_Nat> ::= - <integer_denotation>
</PRE>
This produces a make_signed_nat on the integer value.<P>
<PRE>
<Signed_Nat> ::= <character>
<Signed_Nat> ::= - <character>
</PRE>
This produces a make_signed_nat on the ASCII value of the character.<P>
<P>
<PRE>
<Signed_Nat> ::= LINE
</PRE>
This produces a make_signed_nat on the current line number of the
file being compiled - useful for writing test programs.<P>
<PRE>
<Signed_Nat> ::= + <Nat>
<Signed_Nat> ::= - <Nat>
</PRE>
This produces an appropriately signed <Signed_Nat> from a <Nat>.
<P>
<A NAME=S31>
<H3>3.2.15. String</H3>
<PRE>
<String> ::= STRING? ( <Exp> , <String>, <String>)
<String> ::= <string_constructor> < ( <constructor_param>-List ) >-Opt
<String> ::= <string_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard expansions<P>
<PRE>
<String> ::= <string>
</PRE>
Produces a make_string.<P>
<P>
<A NAME=S32>
<H3>3.2.16. Tag</H3>
<PRE>
<Tag> ::= <tag_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard token application.<P>
<PRE>
<Tag> ::= <ident>
</PRE>
This gives an obtain_tag; the <ident> must been declared as
a TAG either globally or locally.<P>
<A NAME=S33>
<H3>3.2.17. Token</H3>
TOKEN is rather a limited first-class sort. There is no explicit construction
given for token_apply_token, since the only place where it can occur
is in an expansion of a token parameter of another token; here it
is produced implicitly. The only place where <Token> is expanded
is in an actual TOKEN parameter of a token application; other uses
(e.g. as in <shape_token>) are always <ident>s.<P>
<PRE>
<Token> ::= <ident>
</PRE>
The <ident> must have been declarered by a <Tokdec> or
<Tokdec> or is a formal parameter of TOKEN.<P>
<PRE>
<Token> ::= Use <Tok_Defn>
</PRE>
This produces a use_tokdef. For <Tok_Defn> see <A HREF="#3">section
3.1.2</A>. The critical use of this construction is to provide an
actual TOKEN parameter to a token application where the <Tok_Defn>
contains uses of tags or labels local to a procedure.<P>
<A NAME=S34>
<H3>3.2.18. Transfer_mode</H3>
<PRE>
<Transfer_mode> ::= TRANSFER_MODE ? ( <Exp> , <Transfer_mode>, <Transfer_mode>)
<Transfer_mode> ::= <transfer_mode_constructor> < ( <constructor_param>-List ) >-Opt
<Transfer_mode> ::= <transfer_mode_token> < [ <token_param>-List ] >-Opt
</PRE>
There are no expansions for <Transfer_mode> other than the standard
expansions.<P>
<A NAME=S35>
<H3>3.2.19. Variety</H3>
<PRE>
<Variety> ::= VARIETY ? ( <Exp> , <Variety>, <Variety>)
<Variety> ::= <variety_constructor> < ( <constructor_param>-List ) >-Opt
<Variety> ::= <variety_token> < [ <token_param>-List ] >-Opt
</PRE>
The standard expansions.<P>
<PRE>
<Variety> ::= <Signed_Nat> : <Signed_Nat>
</PRE>
This produces var_limits.<P>
<PRE>
<Variety> ::= <Sign>-Opt Int
<Variety> ::= <Sign>-Opt Long
<Variety> ::= <Sign>-Opt Short
<Variety> ::= <Sign>-Opt Char
</PRE>
This produces the variety of the appropriate integer shape.<P>
<A NAME=S36>
<HR><H2>3.3. <A NAME=86>Control structure and local declarations</H2>
The control and declaration structure is given by <ClosedExp>:
<PRE>
<ClosedExp> ::= { <ExpSeq> }
<ExpSeq> ::= <Exp>-Opt
<ExpSeq> ::= <ExpSeq> ; <Exp>-Opt
</PRE>
This produces a TDF sequence if there is more than one <Exp>-Opt;
if there is only one it is simply the production for <Exp>-Opt;
any empty <Exp>-Opt produce make_top.
<P>
<PRE>
<ClosedExp> ::= <ConditionalExp>
<ClosedExp> ::= <RepeatExp>
<ClosedExp> ::= <LabelledExp>
<ClosedExp> ::= <Local_Defn>
</PRE>
The effect of these, together with the expansion of <Assertion>
is given below.<P>
<A NAME=S37>
<H3>3.3.1. <A NAME=89>ConditionalExp and Assertion</H3>
<PRE>
<ConditionalExp> ::= ? { <ExpSeq> | <LabelSetting>-Opt <ExpSeq> }
<LabelSetting> ::= : <Label> :
</PRE>
This produces a TDF conditional. The scope of a LABEL <ident>
which may be introduced by <Label> is the first <ExpSeq>.
A branch to the second half of the conditional will usually be made
by the failure of an <Assertion> ( ie a TDF _test) in the first
half.<P>
<PRE>
<Assertion> ::= <Query> ( <Exp> <Ntest> <Exp> <FailDest>-Opt )
<Query> ::= ?
</PRE>
The assertion will be translated as an integer_test<P>
<PRE>
<Query> ::= F?
</PRE>
The assertion will be translated as a floating_test</A>
with a wrap error_treatment.<P>
<PRE>
<Query> ::= *?
</PRE>
The assertion will be translated as a pointer_test</A>.<P>
<PRE>
<Query> ::=.?
</PRE>
The assertion will be translated as an offset_test</A>.<P>
<PRE>
<Query> ::= P?
</PRE>
The assertion will be translated as a proc_test</A>.<P>
<PRE>
<FailDest> ::= | <Label>
</PRE>
The <Assertion> will produce the appropriate _test on its component
<Exp>s. If the test fails, then control will pass to the <FailDest>-Opt.
If <FailDest>-Opt is not empty, this is the <Label>. Otherwise,
the <Assertion> must be in the immediate context of a <ConditionalExp>
or <RepeatExp> with an empty <LabelSetting>-Opt; in which
case this is treated as an anonymous label and control passes to there.
For example, the following <Conditional> delivers the maximum
of two integers:
<PRE>
?{ ?(a >= b); a | b }
</PRE>
This is equivalent to:
<PRE>
?{ ?(a >= b | L ); a | :L: b }
</PRE>
without the hassle of having to invent the LABEL name, L.<P>
<A NAME=S38>
<H3>3.3.2. RepeatExp</H3>
<PRE>
<RepeatExp> ::= Rep <Starter>-Opt { <LabelSetting>-Opt <ExpSeq> }
<Starter> = ( <ExpSeq> )
</PRE>
This produces a TDF repeat. The loop will usually repeat by an <Assertion>
failing to the <LabelSetting>-Opt; an empty <LabelSetting>-Opt
will follow the same conventions as one in a <Conditional>.
An empty <Starter>-Opt will produce make_top.<P>
<A NAME=S39>
<H3>3.3.3. LabelledExp</H3>
<PRE>
<LabelledExp> ::= Labelled { <ExpSeq> <Places> }
<Places> ::= <Place>
<Places> ::= <Places> <Place>
<Place> ::= | : <Label> : <ExpSeq>
</PRE>
This produces a TDF labelled with the obvious parameters. The scope
of any LABEL <idents> introduced by the <Label>s is the
<LabelledExp>.<P>
<A NAME=S40>
<H3>3.3.4. Local_Defn</H3>
A <Local_Defn> introduces an <ident> as a TAG for the
scope of the component <ClosedExp>. Any containing an <Access>
visible is also available globally - however it will only make sense
in the constructor env_offset.<P>
<PRE>
<Local_Defn> ::= Var <ident> <Access>-Opt <VarInit> <ClosedExp>
<VarInit> ::= = <Exp>
</PRE>
This <Local_Defn> produces a TDF variable with the obvious parameters.
<P>
<PRE>
<Local_Defn> ::= Var <ident> <Access>-Opt : <Shape> <VarInit>-Opt <ClosedExp>
</PRE>
Also a TDF variable. An empty <VarInit>-Opt gives make_value(<Shape>)
as the initialisation to the variable. Using this form of variable
definition also has the advantage of allowing one to use the simple
form of the contents operation ( * in <A HREF="#26">section 3.2.7
</A>).<P>
<PRE>
<Local_Defn> ::= Let <ident> <Access>-Opt = <Exp> <ClosedExp>
</PRE>
This produces a TDF identify with the obvious parameters.<P>
<HR>
<P><I>Part of the <A HREF="../index.html">TenDRA Web</A>.<BR>Crown
Copyright © 1998.</I></P>
</HTML>