PL_TDF Definition
- 1. Introduction
- 2. Notation
- 3. The Language
- 4. First-class SORT expansions
- 5. Control structure and local declarations
© , , , The TenDRA Project.
© DERA.
First published .
Revision History
kate | Moved out examples to the source tree. Moved out usage to tpl. | |
kate | Moved out tpl as a standalone tool. | |
kate | The -V argument for tpl is swapped with -v. | |
kate | Moved out tpl to form the start of the ANDFutils collection of programs. | |
asmodai | Rename pl to tpl, to keep from clashing with some other programs out there. | |
DERA | pl 5.0; TenDRA 4.1.2 release. |
1. Introduction
PL_TDF is a language in the lineage of Wirth's PL360 and its later derivatives. The basic idea in PL360 was to give one an assembler in which one could express all of the order-code of the IBM 360 while still preserving the logical structure of the program using familiar programming constructs. If one had to produce a program at the code level, this approach was much preferable to writing flat
assembly code using a traditional assembler, as anyone who has used both can testify.
In the TDF machine
the problem is not lack of structure at its assembly
level, but rather too much of it; one loses the sense of a TDF program because of its deeply nested structure. Also the naming conventions of TDF are designed to make them tractable to machine manipulation, rather than human reading and writing. However, the approach is basically the same. PL_TDF provides shorthand notations for the commonly occuring control structures and operations while still allowing one to use the standard TDF constructors which, in turn, may have shorthand notations for their parameters. The naming is always done by identifiers where the sort of the name is determined by its declaration, or by context.
The TDF derived from PL_TDF is guaranteed to be SORT correct; however, there is no SHAPE checking, so one can still make illegal TDF.
2. Notation
2.1. Syntax description
Words enclosed in angle brackets, < >, form non-terminal symbols. Other symbols and words stand for themselves as terminal symbols. An expansion of a non-terminal is indicated using ::= with its expansion given as a sequence (possibly empty) of terminals and non-terminals. For example:
<Exp> ::= * <ident>
is a possible expansion of an EXP SORT. If the word for the non-terminal starts with a capital letter then it will be totally described by a set of such expansions; otherwise the expansion of the non-terminal will be given by other methods in the text.
The post-fix -Opt on a non terminal is an abreviation allowing an empty expansion. For example:
<Access>-Opt
is equivalent to the use of another non-terminal <AccessOption> whose expansions are:
<AccessOption> ::= <AccessOption> ::= <Access>
The post-fix -List on a non terminal is an abreviation for lists of objects seperated by the ,-symbol. For example:
<Exp>-List
is equivalent to the use of another non-terminal <ExpList> whose expansions are:
<ExpList> ::= <Exp> <ExpList> ::= <ExpList> , <Exp>
Both of these post-fix notations are also used with sequences of terminals and non-terminals within the angle brackets with the same kind of expansion. In these cases, the expansion within the angle brackets form an anonymous non-terminal.
2.2. Lexical Units
The terminal symbols ( ), [ ], and { } always occur as parenthetic pairs and never form part of other terminal symbols.
The terminal symbols , ; and : are similarly terminators for other terminal symbols.
White space is a terminator for other terminal symbols but is otherwise ignored except in strings.
All other terminal symbols are sequences of ACSII symbols not including the above. These are divided into seven classes: keywords, TDF constructors, operators, <integer_denotation>s, <floating_denotation>s, <string>s and <ident>s.
The keywords and operators are expressed directly in the syntax description. The TDF constructors are those given in the TDF specification which have first-class SORTs as parameters and results.
An <integer_denotatation> allows one to express an integer in any base less than 16, with the default being 10.
<integer_denotation> ::= <digit> <integer_denotation> ::= <integer_denotation> <digit> <integer_denotation> ::= <base> <integer_denotation> <base> ::= <integer_denotation> r
Examples are 31, 16r1f, 8r37, 2r11111 - all giving the same value.
A <floating_denotation> is an <integer_denotation> followed by the . symbol and a sequence of digits. The radix of the <floating_denotation> is given by the base of its component <integer_denotation>
A <string> is the same as a C string - any sequence of characters within " ". The same C conventions hold for \ within strings for single characters.
A <character> is an string character within ` `. The same \ conventions hold.
An <ident> is any other sequence of characters. They will be used to form names for TAGs, TOKENs, AL_TAGs and LABELs.
2.3. Pre-processing
At the moment there is only one pre-processing directive. A line starting with #include will textually include the following file (named within string quotes), using the same path conventions as C.
Comments may be included in the text using the /* ... */ notation; this differs slightly from the C convention in that comments may be nested.
3. The Language
- 3.1. Semantics
- 3.2. Program
- 3.3. Tokdec
- 3.4. Tokdef
- 3.5. Tagdec
- 3.6. Tagdef
- 3.7. Altagdef
- 3.8. Structdef
- 3.9. Procdef
3.1. Semantics
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>:
<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
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> :
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>
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.
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.
The principle of "no use before declaration" also applies to <ident> names given to TAGs.
3.2. Program
The root expansion of a PL_TDF program is given by <Program>:
<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>
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.
A <Program> will produce a single TDF CAPSULE.
3.3. Tokdec
A <Tokdec> introduces an <ident> as a TOKEN:
<Tokdec> ::= Tokdec <ident><Signature>: [ <TokDecPar>-List-Opt ] <ResultSort> <ResultSort> ::= <Sortname> <TokDecPar> ::= <Sortname> <TokDecPar> ::= TOKEN [ <TokDecPar>-List-Opt ] <ResultSort> <Signature> ::= <String>-Opt
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>.
3.4. Tokdef
A <Tokdef> defines an <ident> as a TOKEN; this <ident> may have previously been introduced by a <Tokdec>:
<Tokdef> ::= Tokdef <ident><Signature> = <Tok_Defn> <Tok_Defn> ::= [ <TokDefPar>-List-Opt ] <ResultSort> <result_sort> <TokDefPar> ::= <ident> : <TokDecPar> <Signature> ::= <String>-Opt
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.
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:
x: TOKEN[ LABEL ]EXP
then x[L] is expanded as:
exp_apply_token( token_apply_token(x, ()), L)
<Tok_defn> also occurs in an expansion of <Token>, as a parameter of a token application.
3.5. Tagdec
A <Tagdec> introduces an <ident> as a TAG:
<Tagdec> ::= <DecType> <ident> <Signature> <Access>-Opt : <Shape> <DecType> ::= Vardec <DecType> ::= Iddec <DecType> ::= Commondec <Signature> ::= <String>-Opt
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.
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.
3.6. Tagdef
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.
<Tagdef> ::= Var <ident><Signature> < : <Shape> >-Opt < = <Exp>>-Opt
Produces a make_var_tagdef.
<Tagdef> ::= Common <ident> <Signature>< : <Shape> >-Opt < = <Exp> >-Opt
Produces a common_tagdef.
<Tagdef> ::= Let <ident><Signature> < : <Shape> >-Opt = <Exp>
Produces a make_id_tagdef.
<Tagdef> ::= String <ident> <Variety>-Opt =<string>
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:
String format = "Result = %d\n"
the tag <ident>, format, could be used straightforwardly as the first parameter of printf, for example.
3.7. Altagdef
An <Altagdef> defines an <ident> as an AL_TAG:
<Altagdef> ::= Al_tagdef <ident> = <Alignment>
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>.
3.8. Structdef
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:
<Structdef> ::= Struct <Structname> ( <Field>-List ) <Structname> ::= <ident> <Field> ::= <Fieldname> : <Shape> <Fieldname> ::= <ident>
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).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:
Struct Complex (re: Double, im: Double)
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.
3.9. Procdef
A <Procdef> defines a TAG to be a procedure; it is simply an abreviation of a an Iddec <Tagdef>:
<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> <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
A <Procdef> produces a TAGDEF in a tagdef UNIT and and, possibly, a TAGDEC in a tagdef UNIT.
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 section 3.3).
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>.
4. First-class SORT expansions
- 4.1. Access
- 4.2. Al_tag
- 4.3. Alignment
- 4.4. Bitfield_variety
- 4.5. Bool
- 4.6. Error_treatment
- 4.7. Exp
- 4.8. ExpTerm
- 4.9. Floating_variety
- 4.10. Label
- 4.11. Nat
- 4.12. Ntest
- 4.13. Rounding_mode
- 4.14. Shape
- 4.15. Signed_Nat
- 4.16. String
- 4.17. Tag
- 4.18. Token
- 4.19. Transfer_mode
- 4.20. Variety
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.
Those first-class sorts which include the _cond constructions denote them in the same way:
<Shape> ::= SHAPE ? ( <Exp>, <Shape>, <Shape> )
This produces a shape_cond with the obvious parameters.
Each constructor for <Shape> with parameters which are first-class sorts can be expanded:
<Shape> ::= <shape_constructor> < ( <constructor_param>-List ) >-Opt
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>.
Any <ident> which is declared to be a <shape_token> by a TOKDEF or TOKDEC can be expanded:
<Shape> ::= <shape_token> < [ <token_param>-List ] >-Opt
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>.
4.1. Access
<Access> ::= ACCESS ? ( <Exp> , <Access> , <Access> ) <Access> ::= <access_constructor> < ( <constructor_param>-List ) >-Opt <Access> ::= <access_token> < [ <token_param>-List ] >-Opt
There are no expansions of <Access> other than the standard ones.
4.2. Al_tag
<Al_tag> ::= <al_tag_token> < [ <token_param>-List ] >-Opt
The standard token expansion.
<Al_tag> ::= <ident>
Any <ident> found as an expansion of <Al_tag> will be declared as the name for an AL_TAG.
4.3. Alignment
<Alignment> ::= ALIGNMENT ? ( <Exp> , <Alignment> , <Alignment> ) <Alignment> ::= <alignment_constructor> < ( <constructor_param>-List ) >-Opt <Alignment> ::= <alignment_token> < [ <token_param>-List ] >-Opt
The standard expansions.
<Alignment> ::= <Al_tag>
This results in an obtain_al_tag of the AL_TAG.
<Alignment> ::= ( <Alignment>-List-Opt )
The <Alignment>s in the <Alignment>-List are united using unite_alignments. The empty option results in the top ALIGNMENT.
4.4. Bitfield_variety
<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
The standard expansions.
<Bitfield_variety> ::= <BfSign>-Opt <Nat> <BfSign> ::= <Bool> <BfSign> ::= Signed <BfSign> ::= Unsigned
This expands to bfvar_bits. The empty default on the sign is Signed.
4.5. Bool
<Bool> ::= BOOL ? ( <Exp> , <Bool>, <Bool>) <Bool> ::= <bool_constructor> < ( <constructor_param>-List ) >-Opt <Bool> ::= <bool_token> < [ <token_param>-List ] >-Opt
There are no expansions of <Bool> other than the standard ones.
4.6. Error_treatment
<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
The standard expansions.
<Error_treatment> ::= <Label>
This gives an error_jump to the label.
<Error_treatment> ::= [ <Error_code>-List] <Error_code> ::= overflow <Error_code> ::= nil_access <Error_code> ::= stack_overflow
Produces trap with the <Error_code>s as arguments.
4.7. Exp
<Exp> ::= <ExpTerm> <Exp> ::= <ExpTerm> <BinaryOp> <ExpTerm>
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.
<BinaryOp> | TDF constructor | <BinaryOp> | TDF constructor | |
---|---|---|---|---|
And | and | Or | or | |
Xor | xor | *+. | add_to_ptr | |
*-* | subtract_ptrs | .* | offset_mult | |
.+. | offset_add | .-. | offset_subtract | |
./ | offset_div_by_int | ./. | offset_div | |
.max. | offset_max | % | rem2 | |
%1 | rem1 | * | mult | |
+ | plus | - | minus | |
/ | div2 | /1 | div1 | |
<< | shift_left | >> | shift_right | |
F* | floating_mult | F+ | floating_plus | |
F- | floating_minus | F/ | floating_div | |
= | assign | – | – |
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
The further expansions of <Exp> are all <ExpTerm>s.
4.8. ExpTerm
<ExpTerm> ::= EXP ? ( <Exp> , <Exp>, <Exp>) <ExpTerm> ::= <exp_constructor> < ( <constructor_param>-List ) >-Opt <ExpTerm> ::= <exp_token> < [ <token_param>-List ] >-Opt
The standard expansions.
<ExpTerm> ::= <ClosedExp>
For <ClosedExp>, see section 3.3.
<ExpTerm> ::= ( <Exp> ) <ExpTerm> ::= - ( <Exp> )
The negate constructor.
<ExpTerm> ::= Sizeof ( <Shape> )
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.
<ExpTerm> ::= <Tag>
This produces an obtain_tag.
<ExpTerm> ::= * <ident>
The <ident> must have been declared as a variable TAG and the construction produces a contents operation with its declared SHAPE.
<ExpTerm> ::= * ( <Shape> ) <ExpTerm>
This produces a contents operation with the given <Shape>.
<ExpTerm> ::= <Assertion>
For <Assertion>, see section 3.3.1
<ExpTerm> ::= Case <Exp> ( <RangeDest>-List ) <RangeDest> ::= <Signed_Nat> < : <Signed_Nat> >-Opt -> <Label>
This produces a case operation.
<ExpTerm> ::= Cons [ <Exp> ] ( < <Offset> : <Exp> >-List ) <Offset> ::= <Exp>
This produces a make_compound with the [ <Exp> ] as the size and fields given by < <Offset> : <Exp> >-List.
<ExpTerm> ::= [ <Variety> ] <ExpTerm>
This produces a change_variety with a wrap error_treatment.
<ExpTerm> ::= <Signed_Nat> ( <Variety> )
This produces a make_int of the <Signed_Nat> with the given variety.
<ExpTerm> ::= <floating_denotation> < E <Signed_Nat> >-Opt <Rounding_Mode>-Opt <ExpTerm> ::= - <floating_denotation> < E <Signed_Nat> >-Opt <Rounding_Mode>-Opt
Produces a make_floating.
<ExpTerm> ::= <ProcVal> [ <Shape> ] ( <Exp>-List-Opt < Varpar <Exp> >-Opt) <ProcVal> ::= <Tag> <ProcVal> ::= ( <Exp> )
Produces an apply_proc with the given parameters returning the given <Shape>.
<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>
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>.
<Exp> ::= <ProcVal> Tail_call [ <Act_Callees>-Opt ]
Produces a tail_call with the callee parameters given and same caller parameters as those of the calling procedure.
<ExpTerm> ::= Proc <Proc_defn>
Produces a make_proc. For <Proc_defn>, see section 3.1.7
<ExpTerm> ::= <String> ( <Variety> )
Produces a make_nof_int of the given variety.
<ExpTerm> ::= # <String>
This produces a TDF fail_installer; this construction is useful for narrowing down SHAPE errors detected by the translator.
4.9. Floating_variety
<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
The standard constructions.
<Floating_variety> ::= Float
An IEEE 32 bit floating variety.
<Floating_variety> ::= Double
An IEEE 64 bit floating variety.
4.10. Label
<Label> ::= <label_token> < [ <token_param>-List ] >-Opt
The standard token application.
<Label> ::= <ident>
The <ident> will be declared as a LABEL, whose scope is the current procedure.
4.11. Nat
<Nat> ::= NAT ? ( <Exp> , <Nat>, <Nat>) <Nat> ::= <nat_constructor> < ( <constructor_param>-List ) >-Opt <Nat> ::= <nat_token> < [ <token_param>-List ] >-Opt
The standard expansions.
<Nat> ::= <integer_denotation>
Produces a make_nat on the integer
<Nat> ::= <character>
Produces a make_nat on the ASCII value of the character.
4.12. Ntest
<Ntest> ::= NTEST ? ( <Exp> , <Ntest>, <Ntest>) <Ntest> ::= <ntest_constructor> < ( <constructor_param>-List ) >-Opt <Ntest> ::= <ntest_token> < [ <token_param>-List ] >-Opt
The standard expansions.
<Ntest> ::= !<
Produces not_less_than.
<Ntest> ::= !<=
Produces not_less_than_or_equal.
<Ntest> ::= !=
Produces not_equal.
<Ntest> ::= !>
Produces not_greater_than.
<Ntest> ::= !>=
Produces not_greater_than_or_equal.
<Ntest> ::= !Comparable
Produces not_comparable.
<Ntest> ::= <
Produces less_than.
<Ntest> ::= <=
Produces less_than_or_equal.
<Ntest> ::= ==
Produces equal.
<Ntest> ::= >
Produces greater_than.
<Ntest> ::= >=
Produces greater_than_or_equal.
4.13. Rounding_mode
<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
There are no constructions for <Rounding_mode> other than the standard ones.
4.14. Shape
<Shape> ::= SHAPE ? ( <Exp> , <Shape>, <Shape>) <Shape> ::= <shape_constructor> < ( <constructor_param>-List ) >-Opt <Shape> ::= <shape_token> < [ <token_param>-List ] >-Opt
The standard expansions.
<Shape> ::= Float
The shape for an IEEE 32 bit float.
<Shape> ::= Double
The shape for an IEEE 64 bit float.
<Shape> ::= <Sign>-Opt Int <Sign> ::= Signed <Sign> ::= Unsigned
The shape for a 32 bit signed or unsigned integer. The default is signed.
<Shape> ::= <Sign>-Opt Long
The shape for a 32 bit signed or unsigned integer.
<Shape> ::= <Sign>-Opt Short
The shape for a 16 bit signed or unsigned integer.
<Shape> ::= <Sign>-Opt Char
The shape for a 8 bit signed or unsigned integer.
<Shape> ::= Ptr <Shape>
The SHAPE pointer(alignment(<Shape>)).
4.15. Signed_Nat
<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
The standard expansions.
<Signed_Nat> ::= <integer_denotation> <Signed_Nat> ::= - <integer_denotation>
This produces a make_signed_nat on the integer value.
<Signed_Nat> ::= <character> <Signed_Nat> ::= - <character>
This produces a make_signed_nat on the ASCII value of the character.
<Signed_Nat> ::= LINE
This produces a make_signed_nat on the current line number of the file being compiled - useful for writing test programs.
<Signed_Nat> ::= + <Nat> <Signed_Nat> ::= - <Nat>
This produces an appropriately signed <Signed_Nat> from a <Nat>.
4.16. String
<String> ::= STRING? ( <Exp> , <String>, <String>) <String> ::= <string_constructor> < ( <constructor_param>-List ) >-Opt <String> ::= <string_token> < [ <token_param>-List ] >-Opt
The standard expansions
<String> ::= <string>
Produces a make_string.
4.17. Tag
<Tag> ::= <tag_token> < [ <token_param>-List ] >-Opt
The standard token application.
<Tag> ::= <ident>
This gives an obtain_tag; the <ident> must been declared as a TAG either globally or locally.
4.18. Token
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.
<Token> ::= <ident>
The <ident> must have been declarered by a <Tokdec> or <Tokdec> or is a formal parameter of TOKEN.
<Token> ::= Use <Tok_Defn>
This produces a use_tokdef. For <Tok_Defn> see section 3.1.2. 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.
4.19. Transfer_mode
<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
There are no expansions for <Transfer_mode> other than the standard expansions.
4.20. Variety
<Variety> ::= VARIETY ? ( <Exp> , <Variety>, <Variety>) <Variety> ::= <variety_constructor> < ( <constructor_param>-List ) >-Opt <Variety> ::= <variety_token> < [ <token_param>-List ] >-Opt
The standard expansions.
<Variety> ::= <Signed_Nat> : <Signed_Nat>
This produces var_limits.
<Variety> ::= <Sign>-Opt Int <Variety> ::= <Sign>-Opt Long <Variety> ::= <Sign>-Opt Short <Variety> ::= <Sign>-Opt Char
This produces the variety of the appropriate integer shape.
5. Control structure and local declarations
The control and declaration structure is given by <ClosedExp>:
<ClosedExp> ::= { <ExpSeq> } <ExpSeq> ::= <Exp>-Opt <ExpSeq> ::= <ExpSeq> ; <Exp>-Opt
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.
<ClosedExp> ::= <ConditionalExp> <ClosedExp> ::= <RepeatExp> <ClosedExp> ::= <LabelledExp> <ClosedExp> ::= <Local_Defn>
The effect of these, together with the expansion of <Assertion> is given below.
5.1. ConditionalExp and Assertion
<ConditionalExp> ::= ? { <ExpSeq> | <LabelSetting>-Opt <ExpSeq> } <LabelSetting> ::= : <Label> :
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.
<Assertion> ::= <Query> ( <Exp> <Ntest> <Exp> <FailDest>-Opt ) <Query> ::= ?
The assertion will be translated as an integer_test
<Query> ::= F?
The assertion will be translated as a floating_test with a wrap error_treatment.
<Query> ::= *?
The assertion will be translated as a pointer_test.
<Query> ::=.?
The assertion will be translated as an offset_test.
<Query> ::= P?
The assertion will be translated as a proc_test.
<FailDest> ::= | <Label>
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:
?{ ?(a >= b); a | b }
This is equivalent to:
?{ ?(a >= b | L ); a | :L: b }
without the hassle of having to invent the LABEL name, L.
5.2. RepeatExp
<RepeatExp> ::= Rep <Starter>-Opt { <LabelSetting>-Opt <ExpSeq> } <Starter> = ( <ExpSeq> )
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.
5.3. LabelledExp
<LabelledExp> ::= Labelled { <ExpSeq> <Places> } <Places> ::= <Place> <Places> ::= <Places> <Place> <Place> ::= | : <Label> : <ExpSeq>
This produces a TDF labelled with the obvious parameters. The scope of any LABEL <idents> introduced by the <Label>s is the <LabelledExp>.
5.4. Local_Defn
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.
<Local_Defn> ::= Var <ident> <Access>-Opt <VarInit> <ClosedExp> <VarInit> ::= = <Exp>
This <Local_Defn> produces a TDF variable with the obvious parameters.
<Local_Defn> ::= Var <ident> <Access>-Opt : <Shape> <VarInit>-Opt <ClosedExp>
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 section 3.2.7).
<Local_Defn> ::= Let <ident> <Access>-Opt = <Exp> <ClosedExp>
This produces a TDF identify with the obvious parameters.