FLECS: USER'S MANUAL University of Oregon Editi on (Modified for CARTS) This manu al corresponds to version 22 of Flecs. (Revised Octobe r 1, 1975) Author: Terry Beyer A ddress: Computing Center University of Oregon Eugene, Oregon 97403 Telephone: (503) 686 -4416 Published by: Department of Computer Science University of Oregon Neither the author nor the University of Oregon shall be li- able for any direct or indirect, inci dental, consequential, or specific damages of any kind or from any cause w hatsoever arising out of or in any way connected with the use or performan ce of the Flecs system or its documentation. This manual is i n the public domain and may be altered or reproduced without the explic it permission of the author. Please communicate any errors, ambiguities, or omissions to the author. ACKNOWLEDGEMENTS The a uthor is indebted to many people for assistance of one form or another d uring the course of this project. Mike Dunlap, Kevin McCoy, and Peter Mou lton deserve special thanks for many helpful and fruitful discussion s, suggestions, and encourage- ments. I am grateful to my wife, Kathleen , who assisted in many ways including shielding me from the harsh reality of JCL and 360 Assembly Language. Text preparation was adroitly accompli shed by Marva VanNatta, Allyene Tom, Diane Lane, and Kathleen Beyer. This project was initiated while the author was working under a grant provided by the Office of Scientific and Scholarly Research of t he Graduate School at the University of Oregon. Work on the projec t has also been supported in part by the De- partment of Computer Science and by the Computing Center of the University of Oregon FLECS U SER'S MANUAL 1.0 INTRODUCTION Fortran contains four bas ic mechanisms for controlling pro- gram flow: CALL/RETURN, IF, DO, and v arious forms of the GO TO. Flecs is a language extension of Fortran which has addition- al control mechanisms. These mechanisms make it eas ier to write Fortran by eliminating much of the clerical detail associ ated with constructing Fortran programs. Flecs is also easier to read and comprehend than Fortran. This manual is intended to be a bri ef but complete introduc- tion to Flecs. It is not intended to be a p rimer on Flecs or structured programming. The reader is assumed to be a k nowledge- able Fortran programmer. For programmers to whom tr ansportability of their programs is a concern, it should be noted that t he Flecs translator source code is in the public domain and is made freely available. The translator was written with transportability in mind an d requires little effort to move from one machine to another. Those inte r- ested in moving Flecs to another machine or in having their own copy of Flecs should contact the author. The manner of implementat ion of Flecs is that of a prepro- cessor which translates Flecs prog rams into Fortran programs. The resulting Fortran program is then processe d in the usual way. The translator also produces a nicely formatted lis ting of the Flecs program which graphically presents the control structu res used. 2.0 RETENTION OF FORTRAN FEATURES The Fle cs translator examines each statement in the Flecs program to see if i t is an EXTENDED STATEMENT (a statement valid in Flecs but not in Fortran) . If it is recognized as an extended statement, the translator generat es the corresponding Fortran statements. If, however, the statement is n ot recognized as an extended statement, the translator assumes it must be a Fortran statement and passes it through unaltered. Thus THE FLECS S YSTEM DOES NOT RESTRICT THE USE OF FORTRAN STATEMENTS, it simply pro- vides a set of additional statements which may be used. In par- ticu lar, GO TOs, arithmatic IFs, CALLs, arithmetic statement functions, a nd any other Fortran statements, compiler dependent or otherwise, may be used in a Flecs program. FLECS USER'S MANUAL PAGE 2 3.0 CORRELATION OF FLECS AND FORTRAN SOURCES One difficulty of preprocessor systems like Flecs is that er ror messages which come from the Fortran compiler must be re- lated back to the original Flecs source program. This difficulty is reduced by al lowing the placement of LINE NUMBERS (not to be confused with Fortran stat ement numbers) on Flecs source state- ments. These line numbers then a ppear on the listing and in the Fortran source. When an error message is produced by either the Flecs translator or the Fortran compiler, it w ill include the line number of the offending Flecs source statement, mak ing it easy to locate on the listing. If the programmer choo ses not to supply line numbers, the translator will assign sequential numbers and place them on the listing and in the Fortran source. Thus, e rrors from the com- piler may still be related to the Flecs program. Details of line numbering are machine dependent and are gi ven in section 10. On most card oriented systems, the line numbers ma y be placed in collumns 76-80 of each card. Other sys- tems may have spec ial provisions for line numbers. The beginning Flecs programmer sho uld discover and make spe- cial note of the details of the mechanisms by which Fortran com- piler error messages may be traced back to the Flecs l isting on the system being used. 4.0 STRUCTURED STATEMENTS A basic notion of Flecs is that of the STRUCTURED STATEMENT whic h consists of a CONTROL PHRASE and its SCOPE. Fortran has two structur ed statements, the logical IF and the DO. The fol- lowing examples illu strate this terminology: ::= ::= ::= , ::= <(X .EQ. Y)> ::= DO 30 I=1,N >control phrase A(I) = B(I)+C >scope >structured statement L(I)=I-K(I) 30 CONTINUE Note that each structured statement consists of a c ontrol phrase FLECS USER'S MANUAL PAGE 3 which controls the execution of a set of one or more sta tements called its scope. Also note that each control phrase consists of a KEYWORD plus some additional information called the SPECIFICA- TI ON. A statement which does not consist of a control phrase and a scope is said to be a SIMPLE STATEMENT. Examples of simple statements are ass ignment statements, subroutine CALLs, arithmat- ic IFs, and GO TOs. The problem with the Fortran logical IF statement is that its s cope may contain only a single simple statement. This res- triction is el iminated in the case of the DO, but at the cost of clerical detail (havi ng to stop thinking about the problem while a statement number is invented ). Note also that the IF specifi- cation is enclosed in parentheses wh ile the DO specification is not. In Flecs there is a uniform convention for writing control phrases and indicating their scopes. To write a structured statement, the keyword is placed on a line beginn ing in collumn 7 followed by its specification enclosed in parentheses. T he rema- inder of the line is left blank. The statements comprising the scope are placed on successive lines. The end of the scope is i ndicated by a FIN statement. This creates a MULTI-LINE STRUC- TURED STA TEMENT. Examples of multi-line structured statements: IF (X . EQ. Y) . U = V+W . R = S+T ...FIN DO (I = 1,N) . A(I) = B(I)+C . C = C*2.14 - 3.14 ...FIN Note: the statement number has been eliminated from the DO spec- ification since it is no longer necessary, the end of the loop being sp ecified by the FIN. Nesting of structured statements is permitted to a ny depth. FLECS USER'S MANUAL PA GE 4 Example of nested structured statements: IF (X .EQ. Y) . U = V+W . DO (I = 1,N) . . A(I) = B(I)+C . . C = C*2.14 - 3.14 . ...FIN . R = S+T ...FIN When the scope of a control phrase consists of a single SIM - PLE statement, it may be placed on the same line as the control phrase and the FIN may be dispensed with. This creates a ONE-LINE STRUCTURED STATEMENT. Examples of one-line structured statements: IF(X .EQ. Y) U = V+W DO (I = 1,N) A(I) = B(I)+C Since each control phrase must begin on a new line, it is not po ssible to have a one-line structured statement whose scope consists of a s tructured statement. Example of an invalid construction: IF ( X .EQ. Y) DO (I = 1,N) A(I) = B(I)+C To achieve the above desired effec t, the IF must be written in a multi-line form. Example of a vali d construction: IF (X .EQ. Y) . DO (I = 1,N) A(I) = B(I)+C ...FIN In addition to IF and DO, Flecs provides sever al useful structured statements not available in Fortran. After a bri ef excursion into the subject of indentation, we will present these additional structures. 5.0 INDENTATION, LINES AND THE LISTING In the examples of multi-line structured statements above, the stat ements in the scope were indented and an "L" shaped line was drawn connect ing the keyword of the control phrase to the matching FIN. The resu lting graphic effect helps to reveal the structure of the program. The ru les for using indentation and FINs are quite simple and uniform. The control phrase of a FLECS USER'S MANUAL PAGE 5 multi-line structured statement always causes in dentation of the statements that follow. Nothing else causes indent ation. A level of indentation (i. e. a scope) is always terminated wit h a FIN. Nothing else terminates a level of indentation. Whe n writing a Flecs program on paper the programmer should adopt the inde ntation and line drawing conventions shown below. When preparing a Flecs s ource program in machine readable form, however, each statement shoul d begin in collumn 7. When the Flecs translator produces the listing, i t will reintroduce the correct indentation and produce the correspondi ng lines. If the programmer attempts to introduce his own indentation wit h the use of leading blanks, the program will be translated correctly, bu t the resulting listing will be improperly indented. Example of in dentation: 1. Program as written on paper by programmer IF (X .EQ. Y) . U=V+W . DO (I=1, N) . . A(I)=B(I)+C . . C=C*2.14-3.14 . ...FIN . R=S+T ....FIN 2. Program as entered into computer IF (X.EQ.Y) U = V+W DO (I = 1,N) A(I) = B(I)+ C C = C*2.14-3.14 FIN 3. Program as listed by Flecs translator. IF (X.EQ.Y) . U = V+W . DO (I = 1,N) . . A(I) = B(I)+C . . C = C*2.14-3.14 . ...FIN . R = S+T ...FIN The correctly indented listi ng is a tremendous aid in read- ing and working with programs. Except for the dots and spaces used for indentation, the lines are listed exactl y as they appear in the source program. That is, the internal spacing of collumns 7-72 is preserved. There is seldom any need to refer to a stra- ight listing of the unindented source. FLECS USER'S MANUAL PAGE 6 Comment lines are trea ted in the following way on the list- ing to prevent interruption of the dotted lines indicating scope. A comment line which contains only blanks i n collumns 2 through 6 will be listed with collumns 7 through 72 i ndented at the then-current level of indentation as if the line were an e xecut- able statement. If, however one or more non-blank characters ap- pear in collumns 2 through 6 of a comment card, it will be listed wit hout indentation. Blank lines may be inserted in the source and will be treated as empty comments. 6.0 CONTROL STRUCTURES The co mplete set of control structures provided by Flecs is given below. The symbol l is used to indicate a logical expres- sion. The symbol s is used to indicate a scope of one or more statements. Some statements, as indicated below, do not have a one-line construction. 6.1 Decision Structures Decision structures are structured statements which co ntrol the execution of their scopes on the basis of a logical expres- sion or test. 6.1.1 IF Description: the IF statement c auses a logical expression to be evaluated. If the value is true, t he scope is executed once and control passes to the next statement. If th e value is false, control passes directly to the next statement without exe- cution of the scope. General Form: IF (l) s Examples: IF (X.EQ.Y) U = V+W IF (T.GT.0 .AND. S.LT.R) . I = I+1 . Z= 0.1 ...FIN 6.1.2 UNLESS Description: "UNLESS (l)" is functionally equivalent to "IF( .NOT.(l))", but is more convenient in some contexts. General Form: FLECS USER'S MANUAL PAGE 7 UNLESS (l) s Examples: UNLESS (X.NE.Y) U = V+W UNLESS (T.LE.0 .OR. S.GE.R) . I = I+1 . Z = 0.1 ...FIN 6.1.3 WHEN...ELSE Description: The WHEN...ELSE st atements correspond to the IF...THEN...ELSE statements of ALGOL, PL/ 1, PASCAL, etc. In Flecs, both the WHEN and the ELSE act as structured statements although only the WHEN has a specification. The ELSE state ment must immediately follow the scope of the when. The specifier of the WHEN is evaluated and exactly one of the two scopes is exe- cuted . The scope of the WHEN statement is executed if the ex- pression is true and the scope of the ELSE statement is executed if the expression is false. In either case, control then passes to the next statement followi ng the ELSE statement. General Form: WHEN (l) s1 ELS E s2 Examples: WHEN (X.EQ.Y) U = V+W ELSE U = V-W WHEN (X.EQ.Y) . U = V+W . T = T+1.5 ...FIN ELSE U = V-W WHEN (X.EQ.Y) U = V+W ELSE . U = V-W . T = T+1.5 ...FIN WHEN (X.EQ.Y) . U = V+W . T = T-1.5 ...FIN ELSE . U = V-W . T = T+1.5 FLECS USER'S MANUAL PAGE 8 ...FIN Note: WHEN and ELSE al ways come as a pair of statements, never separately. Either the WHEN o r the ELSE or both may assume the multi-line form. ELSE is considered to be a control phrase, hence cannot be placed on the same line as the WHEN. Thus: "WHEN (l) s1 ELSE s2 " is NOT valid. 6.1.4 CONDITIONAL Description: The CONDITIONAL statement is based on the LISP con ditional. A list of logical expressions is evaluated one by one until t he first expression to be true is encountered. The scope correspondin g to that expression is executed, and control then passes to the first st atement following the CONDITIONAL. If all expressions are false, no scop e is executed. (See, however, the note about OTHERWISE below.) Ge neral Form: CONDITIONAL . (l1) s1 . (l2) s2 . . . . . . . (ln) sn ...FIN Example s: CONDITIONAL . (X.LT.-5.0) U = U+W . (X.LE.1.0) U = U+W+Z . (X.LE.10.5) U = U-Z ...FIN CONDITIONA L . (A.EQ.B) Z = 1.0 . (A.LE.C) . . Y = 2.0 . . Z = 3.4 . ...FIN . (A.GT.C .AND. A.LT.B) Z = 6.2 . (OTHERWISE) Z = 0.0 ...FIN Notes: The CONDI TIONAL itself does not possess a one-line form. However, each "(li) si " is treated as a structured state- ment and may be in one-line or multi-l ine form. FLECS USER'S MANUAL PA GE 9 The reserved word OTHERWISE represents a catchall conditio n. that is, "(OTHERWISE) sn " is equivalent to "(.TRUE.) sn " in a CONDITIONAL statement. 6.1.5 SELECT Description: the SELE CT statement is similar to the CONDI- TIONAL but is more specialized. It allows an expression to be tested for equality to each expression in a list of expressions. When the first matching expression is encountered, a correspond- ing scope is executed and the SELECT statement terminates . In the description below, e, e1,...en represent arbitrary but compa- tible expressions. Any type of expression (integer, real, com- ple x,...) is allowed as long as the underlying Fortran system al- lows such e xpressions to be compared with an .EQ. or .NE. operator. G eneral Form: SELECT (e) . (e1) s1 . (e2) s2 . . . . . . . (en) sn ...FIN Example : SELECT (OPCODE(PC)) . (JUMP) PC = AD . (ADD) . . A = A+B . . PC = PC+1 . ...FIN . (SK IP) PC = PC+2 . (STOP) CALL STOPCD ...FIN Note s: As in the case of CONDITIONAL, at most one of the si will be executed. The catchall OTHERWISE may also be used in a SELECT state- ment. Thus "(OTHERWISE) sn " is equivalent to "(e) sn " within a "SELECT (e)" statement. The expression "e" is reevaluated for each compari son in the list, thus lengthy, time consuming, or irreproducible expressio ns should be precomputed, assigned to a variable, and the variable used in the specification portion of the SELECT statement. FLECS USER' S MANUAL PAGE 10 6.2 LOOP Stru ctures The structured statements described below all have a scope which is executed a variable number of times depending on speci- f ied conditions. Of the five loops presented the most useful are the DO, WHILE, and and REPEAT UNTIL loops. To avoid confusion, the REPE - AT WHILE and UNTIL loops should initially be ignored. 6.2.1 DO Description: the Flecs DO loop is functionally identical to t he Fortran DO loop. The only differences are syntactic. In the Flecs DO loop, the statement number is omitted from the DO state- ment, the increm entation parameters are enclosed in parentheses, and the scope is indicate d by either the one-line or multi-line convention. The symbol i rep resents any legal incrementation specification. General Form: DO (i) s Examples: DO (I = 1,N) A(I) = 0.0 DO (J = 3,K,3) . B(J) = B(J-1)*B(J-2) . C(J) = SIN(B(J)) ...FIN 6.2.2 WHILE Description: the WHILE loop cause s its scope to be repeat- edly executed while a specified condition is tr ue. The condition is checked prior to the first execution of the scope, t hus if the condition is initially false the scope will not be executed at all. General Form: WHILE (l) s FLECS USER'S MANUAL PAGE 11 Examples: WHILE (X.LT.A(I)) I = I+1 WHILE (P.NE.0) . VAL(P) = VAL(P)+1 . P = LINK(P) ...FIN 6.2.3 REPEAT WHILE Description: By using the REPEAT verb, the test can be log- ic ally moved to the end of the loop. The REPEAT WHILE loop causes its scope to be repeatedly executed while a specified con- dition remains t rue. The condition is not checked until after the first execution of the scope. Thus the scope will always be executed at least once and the condition indicates under what conditions the scope is to be repeated. N ote: "REPEAT WHILE(l)" is functionally equivalent to "REPEAT UNTIL(.NOT.( l))". General Form: REPEAT WHILE (l) s Examples: REPEAT WHILE(N.EQ.M(I)) I = I+1 REPEAT WHILE (LINK(Q).NE.0) . R = LINK(Q) . LINK(Q) = P . P = Q . Q = R ...FIN 6.2.4 UNTIL Description: The UNTIL loop ca uses its scope to be repeat- edly executed until a specified condition be comes true. The con- dition is checked prior to the first execution of th e scope, thus if the condition is initially true, the scope will not be ex ecut- ed at all. Note that "UNTIL (l)" is functionally equivalent to "WHILE (.NOT.(l))". General Form: UNTIL (l) s FLECS USER'S MANUAL PAGE 12 Ex amples: UNTIL (X.EQ.A(I)) I = I+1 UNTIL (P.EQ.0) . VAL(P) = VAL(P)+1 . P = LINK(P) ...FIN 6.2.5 REP EAT UNTIL Description: By using the REPEAT verb, the test can be l og- ically moved to the end of the loop. The REPEAT UNTIL loop cau- ese its scope to be repeatedly executed until a specified condi- tion becomes true. The condition is not checked until after the first executio n of the scope. Thus the scope will always be exe- cuted at least once and the condition indicates under what cir- cumstances the REPETITION of t he scope is to be terminated. General Form: REPEAT UNTIL (l) s Examples: REPEAT UNTIL (N.EQ.M(I)) I = I+1 REPEA T UNTIL (LINK(Q).EQ.0) . R = LINK(Q) . LINK(Q) = P . P = Q . Q = R ...FIN 7.0 INTERNAL PROCEDURES In Flecs a sequence of statements may be declared an INTER- NAL PROCEDURE and given a name. The procedure may then be in- voked from an y point in the program by simply giving its name. PROCEDURE NAMES m ay be any string of letters, digits, and hyphens (i.e. minus signs) b eginning with a letter and contain- ing at least one hyphen. Internal bla nks are not allowed. The only restriction on the length of a name is that it may not be continued onto a second line. FLECS USER'S MA NUAL PAGE 13 Examples of valid internal procedure names: INITIALIZE-ARRAYS GIVE-WARNING SORT-INTO-DESCENDING-ORDER INITIATE-PHASE-3 A PRO CEDURE DECLARATION consists of the keyword "TO" fol- lowed by the proce dure name and its scope. The set of statements comprising the procedure i s called its scope. If the scope con- sists of a single simple stateme nt it may be placed on the same line as the "TO" and procedure name, other wise the statements of the scope are placed on the following lines and te rminated with a FIN statement. These rules are analogous to the rules for form- ing the scope of a structured statement. General Form of p rocedure declaration: TO procedure-name Examples of procedure declarations: TO RESET-POINTER P = 0 TO DO-NOTHING CONTIN UE TO SUMMARIZE-FILE . INITIALIZE-SUMMARY . OPEN- FILE . REPEAT UNTIL (EOF) . . ATTEMPT-TO-READ-RECORD . . WHEN (EOF) CLOSE-FILE . . ELSE UPDATE-SUMMARY . .. .FIN . OUTPUT-SUMMARY ...FIN An INTERNAL PROCEDU RE REFERENCE is a procedure name appear- ing where an executable stateme nt would be expected. In fact an internal procedure reference is an exec utable simple statement and thus may be used in the scope of a structure d statement as in the last example above. When control reaches a procedur e refer- ence during execution of a Flecs program, a return address i s saved and control is transferred to the first statement in the scope of the procedure. When control reaches the end of the scope, c ontrol is transferred back to the statement logically following the pr ocedure reference. A typical Flecs program or subprogram consists o f a sequence of Fortran declarations (e.g. INTEGER, DIMENSION, COMMON, e tc.) followed by a sequence of executable statements called the body of the program followed by the Flecs internal procedure declara- FL ECS USER'S MANUAL PAGE 14 tion s, if any, and finally the END statement. Here is a complete (but u ninteresting) Flecs program which illustrates the placement of the proce dure declarations. 0010 C INTERACTIVE PROGRAM FOR PDP-11 TO COMPUTE X**2 . 0020 C 0 IS USED AS A SENTINEL VALUE TO TERMINATE EXECUTION. 0030 REAL X,XSQ 0040 REPEAT UNTIL (X.EQ.0) 00 50 . GET-A-VALUE-OF-X 0060 . IF (X.NE.0) 0070 . . COMPUTE-RESULT 0080 . . TYPE-R ESULT 0090 . ...FIN 0100 ...FIN 0 110 CALL EXIT ---------------------------------------- ------ 0120 TO GET-A-VALUE-OF-X 0130 . TYPE 10 0140 10 . FORMAT (' X = ',$) 0150 . ACCEPT 20,X 0160 20 . FORMAT (F) 0170 ...FIN ---------------------------------------------- 0180 TO COMPUTE-RESULT XSQ = X*X ---------------------------- ------------------ 0190 TO TYPE-RESULT 0200 . TYPE 30, XSQ 0210 30 . FORMAT(' X-SQUARED = ',F7.2) 0220 ...FIN 0230 END FLECS USER' S MANUAL PAGE 15 Notes concern ing internal procedures: 1. All internal procedure declarations must be placed at the end of the program just prior to the END statement. The appearence of the first "TO" statement terminates the body of the progra m. The translator expects to see nothing but procedure declarations form that point on. 2. The order of the declarations is not important. Alphabetical by name is an excellent order for programs with a large num ber of procedures. 3. Procedure declarations may not be nested. In other words, the scope of a procedure may not contain a procedure de claration. It may of course contain executable procedure references. 4. Any procedure may contain references to any other procedures (excl uding itself). 5. Dynamic recursion of procedure referencing is not per mitted. 6. All program variables within a main or subprogram are globa l and are accessable to the statements in all procedures declared within that same main or sub program. 7. There is no formal mechanism f or defining or passing parame- ters to an internal procedure. When param eter passing is needed, the Fortran function or subroutine subprogram mec hanism may be used or the programmer may invent his own parameter passin g meth- ods using the global nature of variables over internal proce- dures. 8. The Flecs translator separates procedure declarations o n the listing by dashed lines as shown in the preceding example. FLECS USER'S MANUAL PAGE 16 8 .0 RESTRICTIONS AND NOTES If Flecs were implemented by a nice in telligent compiler this section would be much shorter. Currently, howeve r, Flecs is implemented by a sturdy but naive translator. Thus the Fl ecs programmer must observe the following restrictions. 1. Flecs must invent many statement numbers in creating the For- tran program. It does so by beginning with a large number (usu- ally 99999) and generating successively smaller numbers as it needs them. Do not use a number which will be generated by the translator. A good rule of thumb is to AVOID USING 5 DIGIT STATEMENT NUMBERS. 2. The Flecs translato r must generate integer variable names. It does so by using names of th e form "Innnnn" where nnnnn is a 5 digit number related to a generated sta tement number. DO NOT USE VARIABLES OF THE FORM Innnnn AND AVOID CAUS ING THEM TO BE DE- CLARED OTHER THAN INTEGERS. For example, the declarati on "IMPLI- CIT REAL (A-Z)"" leads to trouble. Try "IMPLICIT REAL (A-H,J-Z )" instead. 3. The translator does not recognize continuation lin es in the source file. Thus Fortran statements may be continued since the statement and its continuations will be passed through the trans- lator without alteration (see section 2.). However, AN EXTENDED FLECS STATEMENT WHICH REQUIRES TRANSLATION MAY NOT BE CONTINUED. The reasons on e might wish to continue a Flecs statement are: 1) It is a structured sta tement or procedure declaration with a one statement scope too long to fi t on a line; 2) it contains an ex- cessively long specification portion; or 3) both of the above. Problem 1 can be avoided by going to t he multi-line form. Frequently problem 2 can be avoided when the specifica tion is an expression (logical or otherwise) by assigning the expression to a variable in a preceding statement and then using the variable as the specification. 4. BLANKS ARE MEANINGFUL SEPARATORS IN FLECS ST ATEMENTS: DO NOT PUT THEM IN DUMB PLACES like the middle of identifie rs or key words and DO use them to separate distinct words like REPEAT an d UNTIL. 5. Let Flecs indent the listing. START ALL STATEMENTS IN COL- LUMN 7 and the listing will always reveal the true structure of the program (as understood by the translator, of course). 6. As far as the translator is concerned, FORMAT statements are executable For tran statements since Flecs doesn't recognize them as extended Flecs state ments. Thus ONLY PLACE FORMAT STATEMENTS WHERE AN EXECUTABLE FORTRAN STATEMENT WOULD BE ACCEPTABLE. Do not put them between the end of a WHEN statement and the begin- ning of an ELSE statement. Do not put them bet ween procedure de- clarations. FLECS USER'S MANUAL PAGE 17 Incorrect examples: C orrect examples: WHEN (FLAG) WRITE(3,30) WHEN (FLAG) 30 FORMAT(7H TITLE:) . WRITE(3,30) ELSE LINE = LIN E+1 30 . FORMAT(7H TITLE:) ...FIN ELSE LINE = LINE+1 TO WRITE-HEADER TO WRITE-HEADER . PAGE = PAGE+1 . PAGE = PAGE+1 . WRITE (3,40)H,PAGE . WRITE(3,40)H,PAGE ...FIN 40 . FORMAT(70A1,I3) 40 FORMAT(70A1,I3) ...FIN 7. The translator, being simple-minded, recognizes extended Flecs statements by the process of scanning the first identifi er on the line. If the identifier is one of the Flecs keywords IF, WHEN, UNLESS, FIN, etc., the line is assumed to be a Flecs state- ment an d is treated as such. Thus the FLECS KEYWORDS ARE RES- ERVED AND MAY N OT BE USED AS VARIABLE NAMES. In case of necessi- ty, a variable name, li ke WHEN, may be slipped past the transla- tor by embedding a blank withi n it. Thus "WH EN" will look like "WH" followed by "EN" to the translator which is blank sensitive, but like "WHEN" to the compiler which ignores b lanks. 8. In scanning a parenthesized specification, the translator scans from left to right to find the parenthesis which matches t he initial left parenthesis of the specification. The transla- tor, howe ver, is ignorant of Fortran syntax including the concept of Hollerith cons tants and will treat Hollerith parentheses as syntactic parentheses. Thus, AVOID PLACING HOLLERITH CONSTANTS CONTAINING UNBALANCED PARENTHESES WHITHIN SPECIFICATIONS. If ne- cessary, assign such constants to a varia ble, using a DATA or as- signment statement, and place the variable in the specification. Incorrect example: Correct example IF (J.EQ.'(') LP = '(' IF(J.EQ.LP) 9. The Flecs translator will not supply the stateme nts necessary to cause appropriate termination of main and sub-programs. Thus it is NECESSARY TO INCLUDE THE APPROPRIATE RETURN, STOP, OR CALL EXIT STATEMENTS PRIOR TO THE FIRST INTERNAL PROCEDURE DECLARA- TION . Failure to do so will result in control entering the scope of the first procedure after elaving the body of the program. Do not place such state ments between the procedure declaration and the END statement. 9 .0 ERRORS This section provides a framework for understanding the error handling mechanisms of version 22 of the Flecs Translator. FLECS USER'S MANUAL PAGE 18 The system described below is at an early point in evolution, but has p roven to be quite workable. The Flecs translator examines a Flecs p rogram on a line by line basis. As each line is encountered it is first subjected to a limited SYNTAX analysis followed by a CONTEXT analysis. E rrors may be detected during either of these analyses. It is also pos- sible to errors to go undetected by the translator. 9.1 Syntax Error s When a syntax error is detected by the translator, it IG- NORES THE STATEMENT. On the Flecs listing the line number of the statem ent is overprinted with -'s to indicate that the statement has been ign ored. The nature of the syntax error is given in a message on the followi ng line. The fact that a statement has been ignored may, of cours e, cause some context errors in later statements. For example, the control phrase "WHEN (X(I).LT.(3+4)" has a missing right paren- thesis. This statement will be ignored, causing as a minimum the following ELSE to be out of context. The programmer should of course be aware of suc h effects. More is said about them in the next section. 9.2 Conte xt Errors If a statement successfully passes the syntax analysis, it is checked to see if it is in the appropriate context within the program. For example an ELSE must appear following a WHEN and nowher e else. If an ELSE does not appear at the appropriate point or if it appears at some other point, then a context error has occurred. A freq uent source of context error in the initial stages of developement of a pr ogram comes from miscounting the number of FIN's needed at some point i n the program. Whith the exception of excess FIN's which do not ma tch any preceding control phrase and are ignored (as indicated by over- printing the line number), all context errors are treated with a u niform strategy. When an out-of-context source statement is en- countered , the translator generates a "STATEMENT(S) NEEDED" mes- sage. It then invents and processes a sequence of statements which, if they had been i ncluded at that point in the program. would have placed the original so urce statement in a correct con- text. A message is given for each such s tatement invented. The original source statement is then processed in t he newly created context. By inventing statements the transl ator is not trying to patch up the program so that it will run correc tly, it is simply trying to adjust the local context so that the origina l source statement and the statements which follow would be acceptable o n a context basis. As in the case of context errors generated by FLECS USER'S MANUAL PAGE 19 ignoring a syntactically incorrect statement, such an adjustment of cont ext frequently causes further context errors later on. This is called PROPAGATION OF CONTEXT ERRORS. One nice feature of the context adju stment strategy is that context errors cannot propagate past a recognizab le procedure de- claration. This is because the "TO" declaration is in context only at indententation level 0. Thus to place it in context, the translator must invent enough statements to terminate all open c ontrol structures which precede the "TO". The programmer who modulariz es his program into a collection of relatively short internal procedur es, limits the potential for propagation of con- text errors. 9.3 Undetected Errors The Flecs translator is ignorant of most details of Fortran syntax. Thus most Fortran syntax errors will be detected by the Fortran compiler not the Flecs translator. In addition there are two major classes of Flecs errors which will be caught by the compil er and not the translator. The first class of undetected errors involve misspelled Flecs keywords. A misspelled keyword will not be r ecognized by the translator. The line on which it occurs will be assumed to be a Fortran statement and will be passed unaltered to the com- piler which will no doubt object to it. For example a common error is to spell UNTIL with two L's. Such statements are passed to the compil er, which then produces an error message. The fact that an intended c ontrol phrase was not recognized frequently causes a later context error since a level of indentation will not be triggered. The se cond class of undetected errors involves unbalanced parentheses. (See also note 8 in section 8.0.) When scanning a parenthesized specification , the translator is looking for a matching right parenthesis. If t he matching parenthesis is en- countered before the end of the line the re mainder of the line is scanned. If the remainder is blank or consists of a recognizable internal procedure reference, all is well. If neither o f the above two cases hold, the remainder of the line is ASSUMED (with- out checking) to be a simple Fortran statement which is passed to the Compiler. Of course, this assumption may be wrong. Thus the statement: "WHEN (X.LT.A(I)+Z)) X = 0" is broken into keyword "W HEN" specification "(X.LT.A(I)+Z" Fortran statement ") X = 0" FLECS USER'S MANUAL PAGE 20 Needless to say the compiler will object to ") X = 0" as a state- ment. Programmers on batch oriented systems have less difficulty with undected errors due to the practice of running the program t hrough both the translator and the compiler each time a run is submitted . The compiler errors usually point out any errors un- dected by the tra nslator. Programmers on timesharing systems tend to have a bit mo re difficulty since an undetected error in one line may trigger a context error in a much later line. Noticing the context error, the pro grammer does not proceed with compilation and hence is not warned by the c ompiler of the genuine cause of the error. One indication of the true source of the error may be an indentation failure at the corresponding po int in the listing. 9.4 Other Errors The translator detects a variety of other errors such as multiply defined, or undefined pr ocedure references. The error messages are self-explanatory. (Really and truly!) FLECS USER'S MANUAL PAGE 21 Appendix 1: CARTS Notes Flecs was written primarily in Flecs, with the I/O routines written in MACRO. The Fortran sources produ ced by the translator are the basis for the Flecs distribution. There are two sets of sources distributed; a single program about 2000 lines long ('SC' which will only compile on an IBM or DEC 10), and its asso- ciated subroutine module; and the same large program broken into 3 sm aller modules ('M', 'A', 'L'). The Flecs subroutines may be used for c haracter I/O but are inefficient and slow. The MACRO subroutines are much faster and should be used exclusively. Note that not all subroutines wer e rewritten in MACRO, and 'FSUB' con- tains those modules not rewritten. A DOS-11 version of the I/O routines is also included with the distribut ion. The indirect command files will assemble, compile and task- build Flecs without any further modification (FLE.CMD requires the indirect MCR utility). Flecs is about 27KW in size, but can be made s maller through overlaying. For maximum throughput, Flecs should be lef t non-overlayed if possible. The MACRO rou- tines were written to run under RSX-11D V6B/IAS (a simple patch was made). There does not seem to be any reason why Flecs will not run on an RSX-11M system (version 3.0 o r later). As a final test of the Flecs translator, and to get a sam ple of Flecs output, pass Flecs source files (.FLX) through the translator and verify that the resulting Fortran program matches the pr ogram supplied with the distribution package. Flecs accepts standard RSX command lines of the format: MCR>FLE OUTFILE.FTN,LISTFILE.FLL=INFILE .FLX FLECS USER'S MANUAL PAGE 22 Appendix 2: References Available Documentation Concer ning Flecs (As of December 1974) Beyer, T., Flecs Users Manual (University of Oregon Edition) Contains a concise descripti on of the flecs extension of Fortran and of the details necessary to running a Flecs pro- gram on the PDP-10 or the IBM S/360 at Orego n. Beyer, t., Flecs: System Modification Guide Contains in formation of interest to anyone who wishes to in- stall or adapt the Flecs system to a new machine or operat- ing system. Also of intere st to those who wish to improve the efficiency of the system by rewriting portions of the system in assembly language. FLECS USER'S MANUAL PAGE 23 INDEX 1.0 INTRODUCTION . . . . . 1 2.0 RETENTION OF FEATURES . 1 3.0 CORRELATION OF SOURCES . 2 4.0 STRUCTURED STATEMENTS . 2 5 .0 INDENTATION . . . . . . 4 6.0 CONTROL STRUCTURES . . 6 6.1 Dec ision Structures . . 6 6.1.1 IF . . . . . . . . . 6 6.1.2 UNLESS . . . . . . . 6 6.1.3 WHEN...ELSE . . . . . 7 6.1.4 CONDITIONAL . . . . . 8 6.1.5 SELECT . . . . . . . 9 6.2 LOOP Structures . . . . 10 6.2.1 DO . . . . . . . . . 10 6.2.2 WHILE . . . . . . . . 10 6.2.3 REPEAT WHILE . . . . 11 6.2.4 UNTIL . . . . . . . . 11 6.2.5 REPEAT UNTIL . . . . 12 7.0 INTERNAL PROCEDURES . . 12 8.0 REST RICTIONS AND NOTES . 16 9.0 ERRORS . . . . . . . . 17 9.1 Syntax Errors . . . . . 18 9.2 Context Errors . . . . 18 9.3 Undetected E rrors . . . 19 9.4 Other Errors . . . . . 20 Appendix 1: CARTS No tes . . 21 Appendix 2: References . . 22