The Input Module

As mentioned above, the input module carries out the lexical and syntactic analysis (at least in part) of all input statements, and a full semantic analysis of all statements other than action or definition statements. A large part of this module was extracted from the APT IV Translator and, naturally, uses the same production method for both lexical and syntactic analysis. Thus, in a similar way to that described in section 2.3, the first part of the production table controls the lexical

64

-analysis on a character-by-character basis, while the second (and larger) part controls the syntactic (and semantic) analysis. The major difference between the M ILDAPT Input Module and the APT IV Translator concerns the treatment of action and definition statements.

In APT IV a sequence of items of the form

"geometric surface type"/"identifier or name, etc.", or, more succinctly

g/<v+t+n+i+i'>,

is recognised as a partially completed geometric statement and causes the item after the / to be transferred to an argument stack and the c o m m a -’amoved, before processing continues with the lexical input of the next item. This should lead to either

g/<v+t+n+i+i'>,

if the next argument is not the last one, or to g/<v+t+n+i+i ' H

if it is the last, or to g/<v+t+n+i+i '>)

if this is a nested definition. The process is repeated as many times as necessary until the last argument has been identified, at which point processing is transferred to a separate part of the Translator which uses another set of productions to identify the particular geometric definition and then to produce appropriate I.L.

In a similar way, a sequence of items of the form

"procedure'Videntifier or name, etc.", or more succinctly

p/<v+t+n+i+i'>,

will have its arguments successively transferred to the argument stack.

Unlike the geometric statement, however, a further production-based analysis is not then required.

Procedure statements in APT IV are either motion statements w h i c h start with one of a limited number of major words (e.g. GOLFT, GORGT, GOTO, etc.) or post-processor statements which are to be passed to the (machine- tool-dependent) post-processor program via the CLTAPE. The format of the arguments in motion statements is the same for most major words, and the analysis is therefore based on an initial examination of the first (major) word. If this word is not a recognised motion command then it is assumed to be a post-processor command, and is treated accordingly.

In MILDAPT the Input Module does not know about the syntax of any geometric or motion statements, but merely recognises them as being definition or action statements. Although the initial processing is the same as in APT IV, therefore, once the arguments have all been recognised and transferred to the argument stack they are simply output (together with the major word) to the file of I.L. commands for later analysis.

This partial analysis has a number of implications for the classes allocated to all recognised items, and hence for the productions themselves. In APT IV the various geometric and procedure names m a y be used either for that purpose or, for example, as the names of surfaces or other "variables". Initially all known APT geometric words are allocated a conditional geometric class, therefore, and the sequence

<=+(>ig/

(where ig means "conditional geometric surface") causes the class of that particular word to be changed to geometric (surface). Once the statement has been reduced to the form

<v+.i+ig+iG+ip+t>=g/<v+t+n+i+i '>— {

then, as described in section 2.3, the statement is fully analysed and the class of the item on the left of the equals sign is changed to variable.

In a similar fashion the sequence hip</+-j + >>

causes the class of the item before the / to be changed from conditional procedure to procedure.

- 66

In MILDAPT, however, it is not possible to have a list of all possible geometric major words (with initial classes of conditional geometric) since the whole purpose of the processor is to allow the easy addition (or deletion) of definition or action statements. Thus it is perfectly acceptable to have a statement of the form

S1 = NEWSUR/"list of arguments"

which will lead to the sequence

<=+(>i/ ....

(where i means identifier, or simply a name with no prior class). This is presumably acceptable and will be processed by a subsequent MILDAPT module and so MILDAPT allocates a new implied geometric class (gi) to the word.

Subsequently the sequence

<v+vi+i+ig+iG+ip+t>=gi/<v+vi+t+n+i+i'>— |

will cause the item on the left of the equals sign to be assigned the class implied variable (vi).

In a similar way a sequence of the form K < / + - U , >

will cause the initial item to be assigned the class implied procedure (pi).

The items w h i c h constitute an implied geometric definition or an implied procedure call are then incorporated in one of two new types of I.L. command - provisional geometric (PROGEO) and provisional procedure (PROPRO).

The remainder of the Input module is fairly straightforward and follows the APT IV pattern quite closely. It had been the intention to incorporate the full processing of arithmetic and control statements into the Input module, but in the initial (and, as it turned out, the only) version these wer e converted to APT IV-style I.L. commands and then executed by a "mini-module" which followed the Input module.

The output from the Input module is thus a file of I.L. commands of a similar nature to those produced by APT IV, together with the Name Table

containing all the names and symbols used in the part-program. This I.L.

file is then passed to the first Geometric module to carry out further analysis.

3-3 The (Geometric) Definition Modules

The prototype MILDAPT system was based on the premise that each geometric (or definition) module would ignore any I.L. commands that it did not recognise and would process only those that it was designed to deal with. Thus any I.L. commands other than PROGEO c o m m a n d s are copied directly to the output (I.L.) file.

When a PROGEO command is encountered the subsequent items in the I.L.

record are copied onto a stack. This stack is now in almost exactly the same form as the argument stack in the Input module before the output of the PROGEO I.L. command, and also in the same form as the argument stack in APT IV immediately before the secondary (geometric) production processing discussed above. It was, therefore, relatively straightforward to utilise a modified version of the corresponding part of the APT IV Translator to process this stack.

If this processing (which uses a further set of production tables which are kept within the module) fails to find a matching definition then the PROGEO command is copied to the output I.L. file for recognition (presumably) by a subsequent definition module. However, if a matching definition is found then an appropriate subroutine is called to effect the definition, and to create the canonical form of the surface being defined.

At the same time the class of the major word is changed (if necessary) from implied geometric (gi) to geometric (g), and that of the surface name from implied variable (vi) to variable (v).

The result of processing the complete I.L. file by a single geometric module is thus an I.L. file with some PROGEO commands omitted, a modified Name Table, and a table of Canonical Forms.

68

-After all the geometric modules have been loaded and executed there should be no PROGEO commands remaining, and all implied geometric or implied variable classes should have been changed to geometric or variable.