+1\r
+ \r
+ \r
+ INSTITUTE OF INFORMATICS, UNIVERSITY OF WARSAW\r
+ \r
+ \r
+ \r
+ \r
+ REPORT ON THE\r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ # ###### ###### # ###### # # #### ####\r
+ # # # # # # # ## # # # # #\r
+ # # # # # # # # # # #### #\r
+ # # # # ## # ###### # # # # # #\r
+ # # # # # # # # # ## # # #\r
+ ###### ###### ###### ###### # # # # #### ######\r
+ \r
+ \r
+ \r
+ \r
+ PROGRAMMING LANGUAGE (*)\r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ W.M.BARTOL, P.GBURZYNSKI, P.FINDEISEN, A.KRECZMAR, M.LAO, A.LITWINIUK\r
+ \r
+ T.MULDNER, W.NYKOWSKI, H.OKTABA, A.SALWICKI, D.SZCZEPANSKA-WASERSZTRUM\r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ ---------------------------------------------------------\r
+ (*) Supported in part by Zjednoczenie "MERA", POLAND\r
+ \r
+ \r
+ \r
+1\r
+ \r
+ \r
+ FOREWORD\r
+ --------\r
+ \r
+ \r
+ \r
+ We submit to the reader the report of a language whose design is still in\r
+ progress. Therefore any remarks and comments are very desirable. They can\r
+ be sent to:\r
+ \r
+ \r
+ UNIVERSITY OF WARSAW\r
+ INSTITUTE OF INFORMATICS\r
+ PKIN 8TH FLOOR\r
+ 00-901 WARSAW\r
+ POLAND\r
+ \7f\r
+ \r
+ \r
+ \r
+ \r
+ \r
+ The edition has been produced by using the editor program (prepared by\r
+ P.Gburzynski, University of Warsaw) on minicomputer MERA 400. This original\r
+ Polish minicomputer was used for the first implementation of LOGLAN-82.\r
+ \r
+ \r
+ \r
+ Warszawa, June, 1982\r
+1 - 1 -\r
+ \r
+ \r
+ CONTENTS.\r
+ #########\r
+ \r
+ List of symbols...................................................3\r
+ \r
+ 1. Preface........................................................4\r
+ \r
+ 2. The basic characteristics of LOGLAN-82.........................8\r
+ 2.1. Control structure.........................................8\r
+ 2.2. Block structure...........................................11\r
+ 2.3. Procedures and functions..................................13\r
+ 2.4. Classes...................................................14\r
+ 2.5. Prefixing.................................................15\r
+ 2.6. Object deallocator........................................17\r
+ 2.7. Arrays....................................................18\r
+ 2.8. Parameters................................................19\r
+ 2.9. Coroutines................................................20\r
+ 2.10. Processes.................................................21\r
+ 2.11. Other important features..................................22\r
+ \r
+ 3. Lexical and textual structure..................................23\r
+ \r
+ 4. Types..........................................................26\r
+ 4.1. Primitive types............................................27\r
+ 4.2. System types...............................................28\r
+ 4.3. Compound types and objects.................................29\r
+ 4.3.1. Array type.............................................29\r
+ 4.3.2. Class type.............................................30\r
+ 4.4. Formal types...............................................30\r
+ \r
+ 5.Declarations....................................................31\r
+ 5.1. Constant declaration.......................................31\r
+ 5.2. Variable declaration.......................................32\r
+ 5.3. Unit declaration...........................................33\r
+ 5.3.1. Class declaration (introduction).......................33\r
+ 5.3.2. Subprogram declaration (introduction)..................34\r
+ 5.3.3. Block..................................................35\r
+ 5.3.4. Prefixing..............................................36\r
+ 5.3.5. Formal parameters......................................37\r
+ 5.3.6. Unit body..............................................40\r
+ \r
+ 6. Static and dynamic locations . Visibility rules................42\r
+ 6.1. Unit attributes............................................42\r
+ 6.2. Protected attributes.......................................43\r
+ 6.2.1. Hidden attributes......................................43\r
+ 6.2.2. Taken attributes.......................................44\r
+ 6.2.3. Legal and illegal identifiers .........................44\r
+ 6.2.4. Close attributes.......................................45\r
+ 6.3. Static location............................................46\r
+ 6.4. Objects....................................................48\r
+ 6.4.1.ements..........................................71\r
+ 9.1. Sequential primitive statements............................71\r
+ 9.1.1. Evaluation statement...................................72\r
+ 9.1.2. Configuration statement................................75\r
+ 9.1.2.1. Allocation statement...............................75\r
+ 9.1.2.2. Deallocation statement.............................83\r
+ 9.1.3. Simple control statement...............................84\r
+ 9.1.4. Coroutine statement....................................86\r
+ 9.2. Compound statements.......................................87\r
+ 9.2.1. Conditional statement..................................87\r
+ 9.2.2. Case statement.........................................89\r
+1 - 2 -\r
+ \r
+ \r
+ 9.2.3. Iteration statement....................................90\r
+ \r
+ 10. Exception handling............................................96\r
+ 10.1. Signal specification.......................................96\r
+ 10.2. Signal handlers............................................97\r
+ 10.3. Signal raising.............................................98\r
+ 10.4. Handler execution.........................................101\r
+ 10.5. System signals............................................103\r
+ \r
+ 11. Processes....................................................104\r
+ 11.1. Transition state statement...............................106\r
+ 11.2. Primitive synchronizing statement........................109\r
+ 11.3. Monitors (compound synchronization facilities)...........112\r
+ \r
+ 12. Separate compilation of units................................115\r
+ 12.1. Library items............................................117\r
+ 12.1.1. Interface............................................118\r
+ 12.1.2. Using languages......................................121\r
+ 12.1.3. Using externals......................................122\r
+ 12.1.4. Using sl-virtuals....................................122\r
+ 12.2. Linking library items....................................123\r
+ 12.2.1. Connecting the interface.............................123\r
+ 12.3. Binary items.............................................126\r
+ 12.4. Processing libraries.....................................127\r
+ 12.4.1. Recompilation........................................127\r
+ 12.4.2. Insertions and deletions.............................128\r
+ \r
+ 13. File processing..............................................129\r
+ 13.1. External and internal files..............................129\r
+ 13.2. File generation and deallocation.........................130\r
+ 13.3. Binary input-output......................................132\r
+ 13.4. Other predefined operations..............................133\r
+ 13.5. Text input-output........................................134\r
+ 13.6. Example of high-level file processing....................136\r
+ \r
+ Bibliography.....................................................137\r
+ Index............................................................139\r
+1 - 3 -\r
+ \r
+ \r
+ List of symbols\r
+ ***************\r
+ \r
+ \r
+ \r
+ We shall use the following symbols (with indices if necessary):\r
+ \r
+ A - arithmetic expression,\r
+ B - boolean expression,\r
+ C - character expression,\r
+ D - string expression,\r
+ E - arbitrary expression,\r
+ F - function/procedure,\r
+ G, H - statement (or sequence of statements),\r
+ i, j, k, l, u - integer variable or index,\r
+ M, N, P, R, S, T - type or unit identifier,\r
+ O - object,\r
+ Q - constant,\r
+ V - valuation,\r
+ W - arbitrary identifier,\r
+ X - object expression,\r
+ Y - arbitrary variable,\r
+ Z - simple variable,\r
+ Pf - formal parameter,\r
+ Pa - actual parameter,\r
+ VE - the value of an expression E.\r
+1 - 4 -\r
+ \r
+ \r
+ 1. PREFACE\r
+ ###########\r
+ \r
+ LOGLAN-82 #) is a universal programming language designed at the\r
+ Institute of Informatics, University of Warsaw. The shortest, informal\r
+ characterization of the language would read as follows. LOGLAN-82 belongs\r
+ to the Algol family of programming languages. Its syntax, however, is\r
+ patterned upon Pascal's. Many ideas are borrowed from SIMULA-67 [3]. The\r
+ language includes also some modern facilities such as concurrency and\r
+ exception handling.\r
+ \r
+ The characteristic programming constructs and facilities of the language\r
+ are as follows:\r
+ \r
+ - a convenient set of structured statements,\r
+ - block structure,\r
+ - procedures an functions,\r
+ - classes,\r
+ - prefixing,\r
+ - programmed deallocation,\r
+ - adjustable arrays,\r
+ - formal types and formal procedures,\r
+ - coroutines,\r
+ - processes,\r
+ - encapsulation techniques,\r
+ - exception handling,\r
+ - separate compilation techniques,\r
+ - file processing.\r
+ \r
+ \r
+ LOGLAN-82 history\r
+ -----------------\r
+ \r
+ In the early seventies the Institute of Mathematical Machines "MERA"\r
+ (with two members of the present team of authors) and the Institute of\r
+ Informatics of Warsaw University initiated the design of a new high level\r
+ programming language. There were two main inspirations for taking up this\r
+ research. First the awareness that the SIMULA 67 programming language was a\r
+ substantial contribution to the software methodology and second that the\r
+ fast development of multiprocessor hardware will change the software\r
+ practice.\r
+ We began our work with analytical studies, seminars and lectures dealing\r
+ with the basic constructs and features of the known programming languages.\r
+ This helped us to establish the goals a new programming language should\r
+ reach. By then, however, we decided that the design of the programming\r
+ language would be a component of a broader software project, called LOGLAN.\r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ -------------------------------------------------------------------------\r
+ #) Recently we received information about another LOGLAN - an\r
+ esperanto-like language developed in US.\r
+1 - 5 -\r
+ \r
+ \r
+ There is no doubt that the environment in which our investigations have\r
+ been carried out has shed a new light on these goals. In particular, the\r
+ experience accumulated by a big part of our team in the field of\r
+ Algorithmic Logic [15] influenced the form of the solutions accepted.\r
+ The first step of our work was finished in 1977 with the report on the\r
+ LOGLAN programming language [12]. The report provides a general outline of\r
+ a universal programming language. Among its most important features let us\r
+ mention a new approach to arrays, assignments, parameter transmission and\r
+ parallel computations. This version was not implemented. It constituted the\r
+ base for the agreement between the University of Warsaw and the State\r
+ Industrial Trust MERA, signed a year later.\r
+ A careful analysis of the constructs suggested in the primary project\r
+ preceded an actual implementation. With the intention of attaining this,\r
+ the interpreter of the language was designed. At that stage a number of\r
+ important modifications were introduced to the proposed outline. They\r
+ resulted from experiments with the interpreter which proved the usefulness\r
+ of some constructs and the uselessness of some others.\r
+ At the next stage of research the language was implemented on the\r
+ original Polish two-processor minicomputer MERA 400. The design was\r
+ restricted in several points because of the implementation constraints.\r
+ Some constructs were rejected, the decision concerning some others was put\r
+ off until a more elaborate analysis was carried out.\r
+ The experience of the team in the field of abstract data types and\r
+ computational complexity helped us to solve one of the most fundamental\r
+ implementation problems - a proper structure for secure and fast storage\r
+ management. In consequence, the language is furnished with a programmed\r
+ deallocator which allows the user to design the best strategy of storage\r
+ management at run time.\r
+ The implementation of unrestricted prefixing needed a completely new\r
+ approach. The well-known mechanisms like Dijkstra's display do not allow us\r
+ to release the SIMULA restrictions (the most important forbids the use\r
+ prefixing at different levels of unit nesting). Such a solution was found\r
+ and the LOGLAN-82 users may apply prefixing at an arbitrary level of unit\r
+ nesting.\r
+ Of the results we have obtained so far let us mention paper [1], which\r
+ deals with the principles of an efficient implementation of programming\r
+ languages with prefixing at many levels. The paper introduces the\r
+ generalized display mechanism and proves the correctness of an\r
+ update-display algorithm. A new data structure for efficient and secure\r
+ storage management is also provided.\r
+ Paper [2] deals with the design and implementation of class Simulation\r
+ (improving that provided in SIMULA 67).\r
+ The concurency problems are described in the special mathematical model\r
+ [19]. The correctness of the monitor implementation is proved in [20]. The\r
+ semantics of an assignment statement for subscripted variables is defined\r
+ and carefully examined in [21]. Paper [16] describes the semantics of\r
+ allocation, deallocation and control statements.\r
+ A comprehensive survey about LOGLAN-82 and its applications is supplied\r
+ in [8]. Let us mention the close connections between the development of the\r
+ language itself and of Algorithmic Logic, see [15, 22, 23, 24, 25, 26].\r
+1 - 6 -\r
+ \r
+ \r
+ LOGLAN-82 high points\r
+ ---------------------\r
+ \r
+ \r
+ - An orderly and intellectually manageable fashion of program design.\r
+ \r
+ - Clean, modular extensibility (by means of the above mentioned\r
+ facilities, in particular by prefixing). An algorithm employing an\r
+ abstract data structure can be prefixed by a class realizing that\r
+ structure. The class may be programmed by the user himself or by\r
+ another user, taken from the system library etc. In this way,\r
+ programs may be developed by teams of programmers.\r
+ \r
+ - An environment for distributed and safe development of large\r
+ programs and systems with easy inter-communication between members\r
+ of software teams, i.e., different parts of the design are easy to\r
+ read, check and modify. The modifications do not entail unexpected\r
+ interactions.\r
+ \r
+ - Possibility of systematic debugging in a way which contributes to\r
+ confidence in the overall program correctness.\r
+ \r
+ - The separate compilation facility.\r
+ \r
+ - Type checking, especially of references to objects, which\r
+ substantially reduces the need for run-time checks and increases the\r
+ safety of handling pointers.\r
+ \r
+ - Efficient storage management by means of well-tailored allocation/\r
+ deallocation operations.\r
+ \r
+ - Clear visibility rules with the capability of unit encapsulation\r
+ techniques.\r
+ \r
+ - Concurrent computations in which several processes are\r
+ simultaneously and independently executed by any number of\r
+ processors. The concurrent multiprocessor computations were treated\r
+ with due care. We reached the necessary foundations for the\r
+ description of atomic operations for the concurrent statements. The\r
+ atomic operations may be efficiently implemented in any operating\r
+ system kernel. It is well known that concurrent computations have to\r
+ be synchronized and scheduled. We do not prejudge which facilities\r
+ are to be used for those purposes. In LOGLAN-82 all known\r
+ synchronization methods may be declared as predefined classes. For\r
+ example, let us mention that it is possible to define:\r
+ \r
+ - monitoring dialect similar to CONCURRENT PASCAL,\r
+ cf.[5], with the main notions: process, monitor, entry\r
+ procedure, delay, continue,\r
+ - tasking dialect similar to ADA's tasks, cf.[11], with\r
+ the main notions: task, accept, select, rendez-vous.\r
+ \r
+1 - 7 -\r
+ \r
+ \r
+ First implementation of LOGLAN-82\r
+ ---------------------------------\r
+ \r
+ \r
+ The first implementation of the language was finished in December 1981 on\r
+ the two processors Polish minicomputer MERA-400 (uni-bus architecture). The\r
+ whole compiler was programmed in FORTRAN IV Standard. The run-time system\r
+ and file processing were coded in the Mera Assembly Language GASS.\r
+ The implementation team was headed by Antoni Kreczmar (who is the author\r
+ of Running System) and included Pawel Gburzynski (File Processing), Marek\r
+ Lao (Semantic Analysis), Andrzej Litwiniuk (Code Generation), Wojtek\r
+ Nykowski (Parsing) and Danuta Szczepanska-Wasersztrum (Static Semantics).\r
+ \r
+ \r
+ \r
+ \r
+ Further work on LOGLAN-82\r
+ -------------------------\r
+ \r
+ Although we are convinced that LOGLAN-82 will prove to be useful for an\r
+ average user, we would like to stress that we were interested mainly in\r
+ finding answers to research questions. Our approach is more scientific than\r
+ commercial.\r
+ Among the studies that are planned for the nearest future, let us mention\r
+ further research on LOGLAN-82 itself and on its first compiler. The\r
+ portability of the compiler seems to be the main target of our team.\r
+ Moreover, LOGLAN-82 will be used in several applications. In this way the\r
+ language will be verified and its usefulness will be analyzed. We are\r
+ convinced that the new computer architecture and multiprocessor environment\r
+ should be taken into account. Therefore, we plan studies which could\r
+ support an efficient implementation of the language with richer semantics\r
+ are planned. It seems that the crucial point of the future hardware would\r
+ be the efficient implementation of the storage management.\r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ Acknowledgments\r
+ ---------------\r
+ \r
+ \r
+ We wish to express our gratitude to all institutions and persons who\r
+ supported us materially or morally. Thanks are due to the State Industrial\r
+ Trust "MERA" and to its deputy director A.Janicki for the arrangements that\r
+ enabled us to realize the LOGLAN-82 project.\r
+ The LOGLAN-82 team wishes to thank all colleagues in Warsaw for criticism\r
+ and helpful remarks. This report has been carefully read by a number of\r
+ people, including J.Deminet, F.Kluzniak, A.Janicki, J.Rudzinski,\r
+ W.M.Turski. Their critical comments helped us to avoid numerous mistakes.\r
+1 - 8 -\r
+ \r
+ \r
+ 2. The basic characteristics of LOGLAN-82\r
+ #########################################\r
+ \r
+ 2.1. Control structure\r
+ **********************\r
+ \r
+ \r
+ Compound statements in LOGLAN-82 are built up from simple statements\r
+ (like assignment or call statement) by means of conditional, iteration and\r
+ case statements.\r
+ \r
+ \r
+ The syntax of a conditional statement is as follows:\r
+ \r
+ if boolean expression\r
+ then\r
+ sequence of statements\r
+ else\r
+ sequence of statements\r
+ fi\r
+ \r
+ The semantics of a conditional statement is standard. The keyword fi\r
+ allows us to nest conditional statements without the appearence of the\r
+ "dangling else" ambiguity. The "else" part in a conditional statement may\r
+ be omitted:\r
+ \r
+ if boolean expression\r
+ then\r
+ sequence of statements\r
+ fi\r
+ \r
+ Another version of a conditonal statement has the form:\r
+ \r
+ if B1 orif ... orif Bk\r
+ then\r
+ sequence of statements\r
+ else\r
+ sequence of statements\r
+ fi\r
+ \r
+ For the execution of a conditional statement with the orif list the\r
+ specified conditions B1, ..., Bk are evaluated in succession, until the\r
+ first one evaluates to true. Then the rest of the sequence is abandoned and\r
+ the "then" part is executed. If none of the conditions evaluates to true,\r
+ the "else" part is executed (if any). The orif construction provides a good\r
+ method for a short circuit technique, since the boolean expression\r
+ controling the conditional statement execution need not be evaluated till\r
+ the end.\r
+1 - 9 -\r
+ \r
+ \r
+ Similarly, a conditional statement with the andif list has the form:\r
+ \r
+ if B1 andif ...andif Bk\r
+ then\r
+ sequence of statements\r
+ else\r
+ sequence of statements\r
+ fi\r
+ \r
+ For the execution of this kind of statement the conditions B1, ..., Bk\r
+ are evaluated in succession until the first one evaluates to false. Then\r
+ the "else" part is executed (if any). Otherwise the "then" part is\r
+ executed.\r
+ \r
+ \r
+ The basic form of an iteration statement in LOGLAN-82 is the following:\r
+ \r
+ do\r
+ sequence of statements\r
+ od;\r
+ \r
+ To terminate the iteration statement one can use the simple control\r
+ statement exit, which has the following syntactic form:\r
+ \r
+ exit ..... exit\r
+ \r
+ repeated an arbitrary number of times. It may occur in a nested loop\r
+ statement. The execution of exit.....exit (i - times) statement consists in\r
+ the control transfer to the statement immediately following the i-th od\r
+ after the exit statement, (where in counting the od's, the pairs do-od are\r
+ disregarded). In particular, when exit occurs in a simple loop the control\r
+ is transferred to the statement immediately following the od symbol, which\r
+ allows us to terminate the loop. Similarly, a double exit terminates two\r
+ nested loops, a triple exit terminates three nested loops etc. Moreover, a\r
+ LOGLAN-82 iteration statement allows us to place many loop exit points in\r
+ arbitrary configurations, e.g., exit may appear in nested conditional\r
+ statements, case statements, etc.\r
+ \r
+ Iteration statements with controlled variables (for statements) have the\r
+ forms:\r
+ \r
+ for j := A1 step A2 to (or downto) A3\r
+ do\r
+ sequence of statements\r
+ od;\r
+1 - 10 -\r
+ \r
+ \r
+ The type of the controlled variable j must be discrete. The value of this\r
+ variable in the case of the for statement with to is increased, and in the\r
+ case of the for statement with downto is decreased. The discrete range\r
+ begins with the value of A1 and changes with the step equal to the value of\r
+ A2. The execution of the for statement with to terminates when the value of\r
+ j becomes for the first time greater than A3 (with downto when the value of\r
+ j becomes for the first time less than A3). The values of the expressions\r
+ A1, A2, A3 are evaluated once, upon entry to the iteration statement. The\r
+ default value of A2 is equal to 1 (when the keyword step and A2 are\r
+ omitted).\r
+ \r
+ \r
+ An iteration statement with the while condition has the form:\r
+ \r
+ while boolean expression\r
+ do\r
+ sequence of statements\r
+ od;\r
+ \r
+ and is equivalent to\r
+ \r
+ do\r
+ if not boolean expression then exit fi;\r
+ sequence of statements\r
+ od;\r
+ \r
+ To enhance the users's comfort, the simple statement repeat is provided.\r
+ It may appear in an iteration statement and causes the current iteration to\r
+ be finished and the next one to be continued (something like jump to\r
+ CONTINUE in Fortran's DO statement). In general, this statement has the\r
+ form:\r
+ \r
+ exit ... exit repeat\r
+ \r
+ and causes the current iteration of the corresponding enclosing iteration\r
+ statement to be finished and the next one to be continued.\r
+ \r
+ A case statement in LOGLAN-82 has the form:\r
+ \r
+ case A\r
+ when Q1 : G1\r
+ when Q2 : G2\r
+ ...\r
+ when Qk : Gk\r
+ others G\r
+ esac\r
+ \r
+ where A is an arithmetic expression, Q1, ..., Qk are constants and G1, ...,\r
+ Gk are sequences of statements. A case statement selects for execution a\r
+ sequence Gj where the value of A equals Qj. The choice others covers all\r
+ values (possibly none) not given in the previous choices.\r
+1 - 11 -\r
+ \r
+ \r
+ 2.2. Block structure\r
+ ********************\r
+ \r
+ \r
+ \r
+ LOGLAN-82 adopts and extends the main semantic features of the ALGOL\r
+ family programming languages (ALGOL-60, ALGOL-68, SIMULA-67) i.e., the\r
+ block structure. The block concept of ALGOL-60 is a fundamental example of\r
+ this mechanism. The syntactic structure of a block is as follows:\r
+ \r
+ block\r
+ list of declarations\r
+ begin\r
+ sequence of statements\r
+ end\r
+ \r
+ The list of declarations defines some syntactic entities, e.g. constants,\r
+ variables, procedures, functions etc., whose scope is that block. The\r
+ syntactic entities occurring in the sequence of statements are identified\r
+ by means of identifiers which are introduced in the declaration lists. For\r
+ every identifier occurrence it must be possible to identify the\r
+ corresponding syntactic entity. This kind of correspondence between\r
+ occurrences of identifiers and syntactic entities is necessary to define\r
+ the semantics of a block statement. The block statement semantics may be\r
+ described as follows.\r
+ \r
+ When a block is entered, a dynamic instance of the block is generated. In\r
+ a computer, a block instance takes the form of a memory frame containing\r
+ syntactic entities declared in that block. All local syntactic entities of\r
+ an instance will be called its attributes .\r
+ \r
+ The frame of a block instance may be viewed as a box (with displayed\r
+ attributes when necessary).\r
+ \r
+ ------------------------\r
+ ! attribute k !\r
+ ------------------------\r
+ ! ... !\r
+ ------------------------\r
+ ! ... !\r
+ ------------------------\r
+ ! attribute 1 !\r
+ ------------------------\r
+ block instance\r
+1 - 12 -\r
+ \r
+ \r
+ A block is a statement, and so other blocks may occur in its sequence of\r
+ statement (i.e., blocks may be nested). Observe, that the occurrences of\r
+ identifiers in an inner block need not be local. They can refer to entities\r
+ declared in the outer block. For a non-local occurrence of identifier, the\r
+ corresponding attribute of a non-local instance should be identified. That\r
+ identification is possible thanks to an auxiliary notion of a syntactic\r
+ father.\r
+ \r
+ Consider the following block structure:\r
+ \r
+ --------------\r
+ ! block[1] !\r
+ ! !\r
+ ! -----------!\r
+ ! ! block[2]!!\r
+ ! -----------!\r
+ --------------\r
+ \r
+ \r
+ \r
+ \r
+ When the statements of block[2] are executed, the following two dynamic\r
+ block instances are created:\r
+ \r
+ \r
+ -------- --------\r
+ ! O[2] !=============>! O[1] !\r
+ -------- SL --------\r
+ \r
+ Here O[1] is an instance of the block[1], and O[2] is an instance of the\r
+ block[2].\r
+ \r
+ The instance O[1] is called the syntactic father of O[2] (or\r
+ alternatively the instance O[2] is syntactically linked by the SL-link with\r
+ the instance O[1]). During a program's execution the sequence of syntactic\r
+ fathers determined by an active instance forms a chain, called an SL-chain.\r
+ The instances forming the SL-chain correspond to the consequtive enclosing\r
+ units of the program, starting from the active one and ending on the main\r
+ block. Thus, this chain allows us to identify all non-local occurrences of\r
+ identifiers.\r
+ \r
+ A block statement terminates when the control reaches its final end, and\r
+ then its instance is automatically deallocated.\r
+1 - 13 -\r
+ \r
+ \r
+ 2.3. Procedures and functions\r
+ *****************************\r
+ \r
+ \r
+ A block is the simplest example of a unit. Blocks are syntactic units\r
+ generated by means of a block statement and deallocated automatically when\r
+ the end symbol is reached. Procedures and functions constitute the next\r
+ step of know-how in high level programming languages.\r
+ \r
+ The syntactic form of a procedure declaration is as follows:\r
+ \r
+ unit name: procedure(formal parameters);\r
+ list of declarations\r
+ begin\r
+ sequence of statements\r
+ end;\r
+ \r
+ A procedure is a named syntactic unit which may be invoked only via its\r
+ identifier by means of a call statement:\r
+ \r
+ call name (actual parameters);\r
+ \r
+ (Procedures differ from blocks also in that they can have parameters, but\r
+ this question will be discussed later.)\r
+ \r
+ When a procedure is called, its instance is created, as in the case of a\r
+ block. All local attributes are allocated in the new frame. A syntactic\r
+ father of such a newly generated instance is defined as usual, and allows\r
+ us to identify all non-local attributes.\r
+ \r
+ A procedure call is terminated when the control reaches return statement\r
+ or the final end. Then the control returns to the instance where the\r
+ procedure was called. That instance is referred to by another system\r
+ pointer (DL-link).\r
+ \r
+ After the termination of a procedure call there is no syntactic means to\r
+ access its local attributes, hence its instance is automatically\r
+ deallocated.\r
+ \r
+ Functions differ from procedures only in that they return a value and are\r
+ invoked in the expressions.\r
+1 - 14 -\r
+ \r
+ \r
+ 2.4. Classes\r
+ ************\r
+ \r
+ To meet the need for permanent data structures LOGLAN-82 introduces the\r
+ notion of class (cf [3]). Class is declared in a similar way to procedure.\r
+ It is named and may have parameters:\r
+ \r
+ unit M :class(formal parameters);\r
+ list of declarations\r
+ begin\r
+ sequence of statements\r
+ end;\r
+ \r
+ The main difference between classes and procedures consists in the way\r
+ the instances of these syntactic units are treated. (To distiguish class\r
+ instances from those of blocks, functions and procedures they will be\r
+ called class objects or simply objects). The class generation yields a\r
+ class object which is a permanent data unlike the vanishing procedure\r
+ (function, block) instance. The object O of class M is generated by the\r
+ object generator statement:\r
+ \r
+ new M\r
+ \r
+ This statement invokes the same sequence of actions as a procedure call,\r
+ i.e., it opens a new object, transmits parameters and executes the sequence\r
+ of statements of M. Return to the caller is made by the execution of a\r
+ return statement or when the final end is reached.\r
+ The access to such an object is then possible if its address is set to a\r
+ variable. The variables whose values point to class objects are called\r
+ reference variables.\r
+ A reference variable of type M is declared as follows:\r
+ \r
+ var X:M;\r
+ \r
+ and may point to any object of class M, for instance, the statement:\r
+ \r
+ X:=new M\r
+ \r
+ generates an object O of class M and assigns its address (reference) to X.\r
+ The default value of any reference variable is none, which denotes\r
+ fictitious non-existing object.\r
+ What is left behind is a structure of attributes which can be accessed by\r
+ means of dot-notation. These accessible attributes are either formal\r
+ parameters or local entities. If X is a reference variable of type M and W\r
+ is an attribute of class M, then the remote access to the attribute W has\r
+ the form:\r
+ \r
+ X.W\r
+ \r
+ The above remote access is correct if X points to an object O of class M.\r
+ Otherwise a run time error is raised (for instance when the value of X is\r
+ none).\r
+1 - 15 -\r
+ \r
+ \r
+ 2.5. Prefixing\r
+ ***************\r
+ \r
+ Prefixing is another important programming facility borrowed from\r
+ SIMULA-67. Its most important feature consists in the possibility of unit\r
+ extension. Consider the following example. Let M be a class:\r
+ \r
+ unit M: class;\r
+ list of declarations of M\r
+ begin\r
+ sequence of statements of M\r
+ end ;\r
+ \r
+ Now let N be a class:\r
+ \r
+ unit N: M class\r
+ list of declarations of N\r
+ begin\r
+ sequence of statements of N\r
+ end ;\r
+ \r
+ Class N is prefixed by class M. The name of the prefix is located\r
+ immediately before the symbol class. Class N is treated as an extension of\r
+ M, i.e., the object of class N has a compact frame consisting of the\r
+ attributes of N as well as the attributes of M:\r
+ \r
+ ---------------\r
+ ! !\r
+ ! ... ! M-attributes\r
+ ! !\r
+ --------------- - - - - - -\r
+ ! !\r
+ ! !\r
+ ! ... ! N-attributes\r
+ ! !\r
+ ---------------\r
+ \r
+ object of N\r
+ \r
+ The structure of such an object is determined by the class M as well as\r
+ by N (thus containing both M-attributes and N-attributes).\r
+ The statement\r
+ \r
+ X:=new N ,\r
+ \r
+ where X is a variable of type N, creates an object of class N.\r
+1 - 16 -\r
+ \r
+ \r
+ The sequences of statements of classes M and N are also concatenated. In\r
+ the sequence of statements of a class the keyword inner may occur anywhere,\r
+ but once only. The sequence of statements of N consists of the sequence of\r
+ statements of M with inner replaced by the sequence of statements of N\r
+ (inner in N is equivalent to an empty statement). If class N prefixes\r
+ another class P, then inner in N is replaced by the sequence of statements\r
+ of P, and so on. If inner does not occur explicitly, an implicit occurrence\r
+ of inner just before the final end of class is assumed.\r
+ \r
+ Prefixing allows the programmer to extend units. Assume, for instance,\r
+ that STACK is the data structure which defines a push-down memory:\r
+ \r
+ unit STACK :class;\r
+ ...\r
+ unit pop: function...\r
+ end;\r
+ ...\r
+ unit push: procedure...\r
+ end;\r
+ ...\r
+ begin\r
+ ...\r
+ end STACK;\r
+ \r
+ Any class prefixed by STACK inherits the operations on stack. For\r
+ instance, in a class declaration\r
+ \r
+ unit N: STACK class;\r
+ ...\r
+ begin\r
+ ...\r
+ call push;\r
+ ...\r
+ end ;\r
+ \r
+ the function pop and the procedure push may be used as any other local\r
+ attribute.\r
+ \r
+ A class may also be used to prefix blocks, procedures and functions. An\r
+ instance of a prefixed block is a compound object and is created upon entry\r
+ to the block and deallocated after its termination, as in the case of a\r
+ simple block. Similarly, an instance of a prefixed procedure (function) is\r
+ a compound object which is created when a procedure (function) is called\r
+ and deallocated after its termination.\r
+1 - 17 -\r
+ \r
+ \r
+ 2.6. Object deallocator\r
+ ***********************\r
+ \r
+ The classical methods used to deallocate class objects are based on\r
+ reference counters or garbage collection. Sometimes both methods may be\r
+ combined. The reference counter is a system attribute holding the number of\r
+ references pointing to the given object. Hence any change of the value of a\r
+ reference variable X is followed by a corresponding increase or decrease of\r
+ the value of its reference counter. When the reference counter becomes\r
+ equal to 0, the object can be deallocated.\r
+ \r
+ The deallocation of class objects may also occur during the process of\r
+ garbage collection. During this process all unreferenced objects are found\r
+ and removed (while memory may be compactified). In order to keep the\r
+ garbage collector able to collect all the garbage, the user should clear\r
+ all reference variables, i.e., set to none, whenever possible. This system\r
+ has many disadvantages. First of all, the programmer is forced to clear all\r
+ reference variables, even those which are of auxiliary character. Moreover,\r
+ the garbage collector is a very expensive mechanism and thus can be used\r
+ only in emergency cases.\r
+ \r
+ In LOGLAN-82 a dual operation to the object generator, the so-called\r
+ object deallocator is provided. Its syntactic form is as follows:\r
+ \r
+ kill(X)\r
+ \r
+ where X is a reference expression. If the value of X points to no object\r
+ (none) then kill(X) is equivalent to an empty statement. If the value of X\r
+ points to an object O, then after the execution of kill(X) the object O is\r
+ deallocated. Moreover, all reference variables which pointed to O are set\r
+ to none., This deallocator provides full security, i.e., the attempt to\r
+ access the deallocated object O is checked and results in a run-time error.\r
+ For example,\r
+ \r
+ Y:=X; kill(X); Y.W:=Z;\r
+ \r
+ causes the same run-time error as\r
+ \r
+ X:=none; X.W:=Z;\r
+ \r
+ The system of storage management is arranged in such a way that the\r
+ frames of killed objects may be immediately reused without the necessity of\r
+ calling the garbage collector, i.e., the relocation is performed\r
+ automatically.\r
+1 - 18 -\r
+ \r
+ \r
+ 2.7. Arrays\r
+ ***********\r
+ \r
+ LOGLAN-82's array is a kind of a class with indices instead of\r
+ identifiers selecting the attributes. A variable of an array type is a\r
+ reference variable pointing to an object which contains components of a\r
+ one-dimensional array. The components of such an array may also point to\r
+ one-dimensional arrays and so forth, hence multi-dimensional arrays may be\r
+ generated as well.\r
+ \r
+ The declaration of a variable Y of array type has the following form:\r
+ \r
+ var Y : array_of ... array_of T\r
+ \r
+ where the number of array_of defines the dimension of Y. The declaration of\r
+ a variable Y fixes its dimension, while the bound pairs are still\r
+ undetermined. The array generation statement has the form\r
+ \r
+ new_array Y dim (l : u)\r
+ \r
+ where l, u are arithmetic expressions determining the lower and upper\r
+ bounds of the first index. The object O of an array is generated and the\r
+ reference to O is assigned to Y.\r
+ \r
+ If Y is declared as a two-dimensional array, then one can generate a\r
+ two-dimensional array by means of the statements\r
+ \r
+ new_array Y dim (l:u);\r
+ \r
+ for i:=l to u\r
+ do\r
+ new_array Y(i) dim (li:ui)\r
+ od;\r
+ \r
+ where the shape of each row is determined by the bounds li, ui. Hence\r
+ triangular, tridiagonal, streaked arrays, etc. may be generated. Moreover,\r
+ the assignment statements allow us to interchange array references that are\r
+ of the same dimension and the same type, e.g. Y(i):=Y(j). In consequence,\r
+ the user may operate on array slices. The default value of any array\r
+ variable is none, as in the case of a reference variable.\r
+ \r
+1 - 19 -\r
+ \r
+ \r
+ 2.8. Parameters\r
+ ****************\r
+ \r
+ In LOGLAN-82 there are four categories of parameters: variable\r
+ parameters, procedure parameters, function parameters and type parameters.\r
+ \r
+ Variable parameters\r
+ -------------------\r
+ \r
+ Variable parameter transmission is simplified in comparison with ALGOL-60\r
+ and SIMULA-67. There are three transmission modes of variable parameters:\r
+ input mode, output mode and inout mode. In the syntactic unit which is a\r
+ procedure, a function or a class, the formal input parameters are preceded\r
+ by the symbol input, the formal output parameters are preceded by the\r
+ symbol output and the formal inout parameters are preceded by the symbol\r
+ inout. The default transmission mode is input. Input parameters are treated\r
+ as local variables initialized by the values of the corresponding actual\r
+ ones. Output parameters are treated as local variables initialized in the\r
+ standard manner (real with 0.0, integer with 0, reference with none, etc.).\r
+ Upon return their values are assigned to the corresponding actual\r
+ parameters, which in this case must be the variables. Inout parameters act\r
+ as input and output parameters together.\r
+ \r
+ Procedure and function parameters\r
+ ---------------------------------\r
+ \r
+ In LOGLAN-82 procedures and functions may also be formal parameters. This\r
+ category of parameters allows us to parametrize a unit with respect to some\r
+ operations. A formal procedure (function) has the full specification part,\r
+ i.e., the parameter list (and the function type), for instance :\r
+ \r
+ unit Bisec: procedure(function f(x: real): real; a, b, eps:real);\r
+ begin\r
+ ...\r
+ end;\r
+ \r
+ Type parameters\r
+ ---------------\r
+ \r
+ Types are also allowed to be transmitted as parameters. This kind of\r
+ parameters enables us to parametrize a unit with respect to some types. For\r
+ instance consider the following declaration:\r
+ \r
+ unit sort:procedure(type T;A:arrayof T; function less(x, y:T):boolean);\r
+ begin\r
+ ...\r
+ end\r
+ \r
+ The actual parameter corresponding to the formal T must be a\r
+ non-primitive type. The array A must be the array of elements of the actual\r
+ type.\r
+ If function less defines the ordering relation on the elements of the\r
+ actual type, then this procedure may be invoked to sort the array A.\r
+1 - 20 -\r
+ \r
+ \r
+ 2.9. Coroutines\r
+ ***************\r
+ \r
+ Coroutine is a generalization of class. A coroutine object is an object\r
+ whose sequence of statements can be suspended and reactivated in the\r
+ programmed manner. The generation of a coroutine object terminates with the\r
+ execution of the return statement (then the control is passed to the caller\r
+ as in the case of classes). A coroutine object after the execution of the\r
+ return statement is suspended. A suspended coroutine object may be\r
+ reactivated with the help of the attach statement:\r
+ \r
+ attach(X)\r
+ \r
+ where X is a reference variable designating the activating object.\r
+ \r
+ In general, from the moment of generation a coroutine object is either\r
+ active or suspended. Any reactivation of a suspended coroutine object O\r
+ causes the active coroutine object to be suspended and continues the\r
+ execution of O from the statement following the last executed one.\r
+ \r
+ During a coroutine execution some other unit instances may be generated.\r
+ They are dynamically dependent on that coroutine object. Thus, an active\r
+ coroutine (in particular the main program) can be illustrated by the\r
+ following chain:\r
+ \r
+ -------- -------- --------\r
+ ! O[k] ! ---> !O[k-1]! --->...---> ! O[1] !--->\r
+ -------- -------- --------\r
+ coroutine head\r
+ \r
+ where the arrows denote the DL-links.\r
+ \r
+ This DL-chain is transformed into the DL-cycle when the control is\r
+ transferred to another coroutine as the result of the attach statement.\r
+ \r
+ -------- -------- --------\r
+ ! O[k] ! ---> !O[k-1]! --->...---> ! O[1] !--->\r
+ -------- -------- -------- !\r
+ ! !\r
+ <----------------------------------------------!\r
+ \r
+ \r
+1 - 21 -\r
+ \r
+ \r
+ 2.10. Processes\r
+ ***************\r
+ \r
+ The concept of process in LOGLAN-82 is a natural extension of coroutine.\r
+ Coroutines are units which once generated may operate independently, each\r
+ one treated as a separate process. For coroutines, however, an essential\r
+ assumption is established; namely, when one coroutine object is activated,\r
+ the active one must be suspended. When processes are used, the activation\r
+ of a new process does not require the active one to be suspended. Thus\r
+ during a program's execution many processes may be active simultaneously.\r
+ Their statements are computed in parallel.\r
+ There are two operations, stop and resume, which concern the control of\r
+ processes.\r
+ \r
+ stop Operation which causes the active process to be\r
+ stopped.\r
+ resume(X) Operation which reactivates the process referenced by X.\r
+ \r
+ Synchronization and scheduling.\r
+ \r
+ Elementary synchronization in LOGLAN-82 is achieved by two-valued\r
+ semaphores and a number of simple indivisible statements operating on them.\r
+ These statements are the following (where Z denotes a variable of semaphore\r
+ type):\r
+ \r
+ \r
+ ts(Z) Test-and-set boolean function which closes semaphore Z\r
+ and returns the value true if Z was open and false if Z\r
+ was closed.\r
+ lock(Z) Operation which tests the value of the semaphore Z and\r
+ either enables the given process to enter the critical\r
+ region guarded by Z (if Z is open) or suspends the\r
+ process (in the opposite case) until another one opens\r
+ that critical region.\r
+ unlock(Z) Operation the execution of which opens the critical\r
+ region guarded by Z.\r
+ stop(Z) Operation that opens the critical region guarded by Z\r
+ and stops the execution of the given process.\r
+ \r
+ The above operations are implemented in the kernel of the operating\r
+ system. One can use them to define any complex synchronization facility,\r
+ e.g., monitors (cf. 11.3.). Once defined and stored in the library, the\r
+ facility can be used by any user. Moreover, using the high level\r
+ synchronizing tools, the user can cover the low level, primitive ones\r
+ (therefore the properties of high level tools cannot be disturbed).\r
+ \r
+ There is also a parameterless function wait. If wait is called in the\r
+ given process X, then process X waits for the termination of any of its son\r
+ (a son of X is a process which was generated in X). The returned value of\r
+ wait points to the first terminated son, and then, the computation of\r
+ process X is continued. If there is no such son, the returned value of wait\r
+ is none.\r
+1 - 22 -\r
+ \r
+ \r
+ 2.11. Other important features\r
+ ******************************\r
+ \r
+ In LOGLAN-82 the access control mechanism is enlarged so that it supports\r
+ the data encapsulation technique and the protection of attributes in\r
+ different environments. The mode of accessibility to attributes of a class\r
+ can be controlled by means of the specification hidden and close. On the\r
+ other hand, the mode of accessibility to attributes of a unit that are\r
+ inherited from its prefix can be controlled by means of the specifification\r
+ taken. This permits more flexible communication across the unit boundary as\r
+ well as defining of abstract behaviour with a hidden auxiliary structure.\r
+ (For details see 6).\r
+ \r
+ The language provides facilities for dealing with run time errors and\r
+ other exceptional situations raised by the user. These events are called\r
+ exceptions. So, the exceptions cause interruption of a normal program\r
+ execution. The response to an exception is defined by an exception handler.\r
+ The user is allowed to define the actions that should be raised when an\r
+ exception is encountered.\r
+ (For details see 10).\r
+ \r
+ Program units can be compiled separately. Two kinds of separately\r
+ compiled units are provided: binary items ready to be executed, and library\r
+ items. The purposes of separate compilation are the following: creating\r
+ user libraries, handling system and user libraries, compiling program\r
+ components during program testing, and program overlaying.\r
+ (For details see 12).\r
+ \r
+ Input-output facilities and file processing are defined by means of some\r
+ simple primitives. The user is able, however, to declare in the language\r
+ any class that provides high-level and secure file operations. Examples of\r
+ system classes that deal with high-level file operations are also given.\r
+ (For details see 13).\r
+1 - 23 -\r
+ \r
+ \r
+ 3. Lexical and textual structure\r
+ ################################\r
+ \r
+ \r
+ The basic character set consists of\r
+ \r
+ (a) 26 upper case letters:\r
+ \r
+ a b c d e f g h i j k l m n o p q r s t u v w x y z\r
+ \r
+ (b) 10 digits:\r
+ \r
+ 0 1 2 3 4 5 6 7 8 9\r
+ \r
+ (c) 16 auxiliary characters:\r
+ \r
+ . : , ; _ = / + - * < > ' " ( )\r
+ \r
+ (d) the space character\r
+ \r
+ This set can be extended with the following characters:\r
+ \r
+ (e) lower case letters\r
+ \r
+ (f) other special ASCII characters, e.g.:\r
+ \r
+ # $ ? % ^\r
+ \r
+ (lower case letters are equivalent to the corresponding upper case ones.)\r
+ \r
+ A finite sequence of characters is called a word. The words called\r
+ identifiers have a special meaning. They are composed of letters, digits,\r
+ and underscores and start with a letter:\r
+ \r
+ \r
+ \r
+ <identifier>:\r
+ \r
+ ----------> <letter> -------------------------->\r
+ ^ ^ !\r
+ ! ! !\r
+ !---> <digit> ----> ! !\r
+ ! !\r
+ ! !\r
+ !--- _ -----> !\r
+ ! ! !\r
+ <-------------------------------\r
+ \r
+ \r
+ \r
+1 - 24 -\r
+ \r
+ \r
+ Identifiers serve to identify program entities, i.e., constants, variables,\r
+ types, functions, procedures, classes, coroutines and processes. There are\r
+ a certain number of predefined system identifiers which have special\r
+ significance in the language. The following system identifiers are reserved\r
+ words (these identifiers cannot be declared by the programmer).\r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ and_if detach if od taken\r
+ and dim in open terminate\r
+ array_of div inner or then\r
+ attach do input or_if this\r
+ downto inout others to\r
+ is output type\r
+ begin else\r
+ block end kill pref unit\r
+ esac procedure unlock\r
+ exit last_will process\r
+ lock put var\r
+ call fi virtual\r
+ case for main qua\r
+ class function mod wait\r
+ close raise wind\r
+ const get new read when\r
+ copy new_array repeat while\r
+ coroutine hidden none repeat write\r
+ handlers not return writeln\r
+ \r
+ signal\r
+ step\r
+ stop\r
+ \r
+ \r
+ \r
+1 - 25 -\r
+ \r
+ \r
+ The lexical entities are identifiers, numbers, strings and delimiters.\r
+ The delimiters from the basic character set are:\r
+ \r
+ , ; = / + - * > < . ( ) :\r
+ \r
+ and the compound symbols are :\r
+ \r
+ =/= >= <= :=\r
+ \r
+ Spaces play the role of separators, i.e., at least one space must\r
+ separate adjacent identifiers or numbers. The end of each line is\r
+ equivalent to a space.\r
+ \r
+ A comment starts with a left parenthesis and an asterisk and is\r
+ terminated by an asterisk and a right parenthesis. It may only appear\r
+ following a lexical unit or at the beginning or end of a program entity.\r
+ Comments have no effect on the meaning of a program and are used solely for\r
+ program documentation.\r
+ \r
+ By an identifier definition we mean a declaration or description in the\r
+ list of formal parameters.\r
+ \r
+ The notion of a unit is explained by the following diagram:\r
+ \r
+ \r
+ ---------------------- unit ----------------------\r
+ ! ! !\r
+ ! ! !\r
+ ! ! !\r
+ -----subprogram---- generalized class !\r
+ ! ! ! ! ! !\r
+ ! ! ! ! ! !\r
+ function procedure class coroutine process block\r
+1 - 26 -\r
+ \r
+ \r
+ 4. Types\r
+ ########\r
+ \r
+ \r
+ A type T determines a set !T! of values and a family of operations\r
+ applicable to the elements of the set. Three kinds of types are\r
+ distinguished: primitive types, system types and compound types. Variables\r
+ may be declared to be of type T. Depending on the kind of type T we have to\r
+ distinguish two cases.\r
+ \r
+ \r
+ a) T is a primitive type. The value assigned to a variable Y of type\r
+ T must belong to the set !T!.\r
+ \r
+ \r
+ b) T is a compound or system type. The value assigned to a variable\r
+ Y of type T must be a reference pointing to an object in the set\r
+ !T! (for the notion of reference cf 4.3. and 6.3.)\r
+ \r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <type identifier>:\r
+ \r
+ -----> <primitive type> ------>\r
+ ! ^\r
+ !-> <system type> ----->!\r
+ ! !\r
+ !-> <compound type> --->!\r
+ ! !\r
+ !-> <formal type> ----->!\r
+ ! !\r
+ !-> <file type> ------->!\r
+ \r
+ \r
+ \r
+ Primitive and system types are pre-defined, compound types are defined by\r
+ the user. For file type see section 13.\r
+1 - 27 -\r
+ \r
+ \r
+ 4.1. Primitive types\r
+ ********************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <primitive type>:\r
+ \r
+ -----> integer -------->\r
+ ! ^\r
+ !---> real ---->!\r
+ ! !\r
+ !--> boolean -->!\r
+ ! !\r
+ !-> character -->!\r
+ ! !\r
+ !---> string -->!\r
+ ! !\r
+ !-> semaphore -->!\r
+ \r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ A primitive type determines a finite set of values which can be effectively\r
+ represented in a computer memory:\r
+ \r
+ !integer! - a subset of integers;\r
+ !real! - a subset of reals;\r
+ !boolean! - the set consisting of logical values T (true) and F (false);\r
+ !semaphore! - the set consisting of two values (closed and open);\r
+ !character! - a set of characters;\r
+ !string! - a subset of strings;\r
+ \r
+ These sets will be precisely defined in a concrete implementation. The\r
+ way in which the primitive type values are represented in a computer memory\r
+ is not essential for the description of semantics; however, the values of\r
+ integer and real types are differently represented. Namely, integers are\r
+ represented in the fixed-point form with a point after the last significant\r
+ digit, reals are represented in the floating-point form. So they will be\r
+ denoted differently, e.g., 2 and 2.0. Those values can be mutually\r
+ converted: the value of type integer is converted to type real by means of\r
+ conversion into the floating point form; the conversion into the opposite\r
+ direction truncates and transforms the real value into the fixed-point\r
+ form.\r
+1 - 28 -\r
+ \r
+ \r
+ 4.2. System types\r
+ #################\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <system type>:\r
+ \r
+ --------> coroutine -------->\r
+ ! ^\r
+ !----> process --->!\r
+ \r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ The set !coroutine! is equal to the union of sets !T! for every type T\r
+ declared as:\r
+ \r
+ - unit T : coroutine\r
+ - unit T : process\r
+ - unit T : S class\r
+ where !S! is already a subset of the set !coroutine!.\r
+ \r
+ The set !process! is equal to the union of sets !T! for every type T\r
+ declared as:\r
+ \r
+ - unit T : process\r
+ - unit T : S class\r
+ where !S! is already a subset of the set !process!.\r
+ \r
+ The user may declare a variable of coroutine (process) type, e.g. of the\r
+ form\r
+ \r
+ var X : coroutine;\r
+ (var X : process;)\r
+ \r
+ and then to assign:\r
+ X:=new T\r
+ \r
+ where T belongs to the set !coroutine! (!process!).\r
+ \r
+ The main block belongs to both sets - !coroutine! and !process!. The\r
+ system variable main gives the reference to the main block. The variable\r
+ main may occur in the statements attach(main) and resume(main) only.\r
+1 - 29 -\r
+ \r
+ \r
+ 4.3. Compound types and objects\r
+ *******************************\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <compound type>:\r
+ \r
+ --------> <array type> ---------->\r
+ ! ^\r
+ !----> <class type> --->!\r
+ \r
+ 4.3.1. Array type\r
+ *****************\r
+ \r
+ \r
+ Objects of array type will be called array objects or shortly arrays. An\r
+ array can be considered as a vector; the access to its components is\r
+ provided by means of indexing.\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <array type>:\r
+ \r
+ ------> array_of -----> <type identifier> ---->\r
+ \r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ LOGLAN-82 types can be uniformly denoted in the following way\r
+ \r
+ \r
+ !! array_of ... array_of T for i>0\r
+ !! i - times\r
+ (array_of)<i>T= !!\r
+ !!\r
+ !! T for i=0\r
+ \r
+ where T is a type identifier.\r
+ \r
+ For i>0, the set !(array_of)<i>T! consists of the array objects. Every\r
+ array object has the attributes accessed via indices l, l+1, ..., u where\r
+ l, u are the values of the lower and upper bounds, respectively, and l<=u.\r
+ The attributes with the indices l, ..., u are of type (array_of)<i-1>T.\r
+ \r
+ Let O be an arbitrary fixed array object and let Y be a variable whose\r
+ value points to O. The operations related to the object O are:\r
+ \r
+ - Y(j), where l<=j<=u, gives the j-th attribute of the object O,\r
+ - lower(Y) and upper(Y), which give the value l and u,\r
+ respectively.\r
+1 - 30 -\r
+ \r
+ \r
+ 4.3.2. Class type\r
+ *****************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <class type>:\r
+ \r
+ -----> <class identifier> ----->\r
+ \r
+ \r
+ <class identifier>:\r
+ \r
+ ------> <identifier> ---------->\r
+ \r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ A class T is a description of a data structure consisting of attributes\r
+ i.e., types, functions, procedures, variables, and a sequence of\r
+ statements. The family of admissible operations on the objects from the set\r
+ !T! contains the operations defined in the sequence of statements and those\r
+ defined in the declarations of functions and procedures. The other\r
+ operations are related to the notion of remote access. They allow us to\r
+ operate on the objects of type !T! from outside of them.\r
+ \r
+ \r
+ \r
+ 4.4. Formal types\r
+ *****************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <formal type>:\r
+ \r
+ -----> <formal type identifier> ----->\r
+ \r
+ \r
+ <formal type identifier>:\r
+ \r
+ -----> <identifier> ------------------>\r
+ \r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ A formal type is a formal parameter of a unit and can be treated as the\r
+ name of an abstract data structure without any attribute. The corresponding\r
+ actual type must be a system type or a compound type. The set of objects of\r
+ the formal type T from a dynamic object O is equal to the set of objects of\r
+ the actual type which occurs in the actual parameter list of O.\r
+1 - 31 -\r
+ \r
+ \r
+ 5. Declarations\r
+ ###############\r
+ \r
+ \r
+ Every identifier which is to be used in a program must be defined. System\r
+ identifiers are pre-defined, other identifiers are pre-compiled, (see 12.)\r
+ or they are defined by means of a declaration or description in the formal\r
+ parameter list. LOGLAN-82 is not strongly typed in the sense that sometimes\r
+ the type of variable and function value cannot be determined at compilation\r
+ time. The user may balance the generality and convenience given by the\r
+ formal types mechanism and the risk of reduced efficiency of his program\r
+ execution. The compiler option, however, allows us to supress the run time\r
+ checking with respect to the type compatibility.\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <declaration>:\r
+ \r
+ ------> <constant declaration> -------->\r
+ ! ^\r
+ !--> <variable declaration> -->!\r
+ ! !\r
+ !--> <unit declaration> ------>!\r
+ ! !\r
+ !--> <signal declaration> ---->!\r
+ ! !\r
+ !--> <linked item specific.>-->!\r
+ \r
+ \r
+ (For the definition of a signal declaration see 10.\r
+ For the definition of linked item specification see 12.)\r
+ \r
+ \r
+ 5.1. Constant declaration\r
+ *************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <constant declaration>:\r
+ \r
+ --> const ---> <identifier> ---> = ---> <expression> ------------------->\r
+ ! !\r
+ <------------------------ , ---------------------\r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ The expression defining the constant must be determinable at compilation\r
+ time. The type and the value of the constant is given by its declaration.\r
+ They are always primitive.\r
+ \r
+ Example.\r
+ --------\r
+ \r
+ const pi=3.1415926, pihalf=pi/2;\r
+ \r
+1 - 32 -\r
+ \r
+ \r
+ 5.2. Variable declaration\r
+ *************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <variable declaration>:\r
+ \r
+ ---> var ---><specification list>--->\r
+ \r
+ \r
+ <specification list>:\r
+ \r
+ ----> <identifier list> ---> : ---> <type identifier> ------>\r
+ ^ !\r
+ !<------------------ , <--------------------------------!\r
+ \r
+ \r
+ <identifier list>:\r
+ \r
+ -----> <identifier> ------->\r
+ ^ !\r
+ !<---- , <---------!\r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ A variable is of a type given in a variable declaration. A declaration is\r
+ elaborated at the instant of generation of a unit object which contains\r
+ that declaration. An elaboration determines an initial value for every\r
+ variable. This value depends on the type identifier :\r
+ \r
+ integer - 0\r
+ real - 0.0\r
+ boolean - F\r
+ semaphore - open\r
+ character and string - defined in concrete implementation\r
+ any compound and system type- none\r
+ \r
+ The value of the variable may be modified by means of an assignment\r
+ statement (see 9.1.1.), but the variables of type T may only point to the\r
+ object from the set !T!.\r
+ \r
+ Example.\r
+ --------\r
+ \r
+ var left, right: node, counter: integer, cycle: array_of boolean;\r
+ \r
+ \r
+1 - 33 -\r
+ \r
+ \r
+ 5.3. Unit declaration\r
+ *********************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <unit declaration>:\r
+ \r
+ ----> unit -------> <class declaration> ---------------------->\r
+ ! !\r
+ !----> <subprogram declaration> --->!\r
+ \r
+ \r
+ 5.3.1. Class declaration (introduction)\r
+ ***************************************\r
+ \r
+ \r
+ A class declaration is understood as a declaration of a class itself, as\r
+ well as a declaration of a coroutine or a process. The prefixing will be\r
+ described in 5.3.4..\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <class declaration>:\r
+ \r
+ ----------><class identifier> : ---> <prefix> -----> class ----->!\r
+ ! ^ !\r
+ ------------->!-><system type>->!\r
+ !\r
+ !<------------------------------------------------------------!\r
+ ! !\r
+ !-> <formal parameter list> ------------------------------->!\r
+ !\r
+ !<------------------------------ ; ----------!\r
+ !\r
+ !--> <class body> ----------------------------->\r
+ ! ^\r
+ !-> <class identifier> ->!\r
+ \r
+ \r
+ <prefix>:\r
+ \r
+ ----------------> <class identifier> ------>\r
+ \r
+ Example.\r
+ --------\r
+ \r
+ unit complex: class(re, im:real);\r
+ var module:real;\r
+ begin\r
+ module:=sqrt(re*re+im*im)\r
+ end ;\r
+1 - 34 -\r
+ \r
+ \r
+ 5.3.2. Subprogram declaration (introduction)\r
+ ********************************************\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <procedure declaration>:\r
+ \r
+ --> virtual --> <procedure identifier>--> : --><prefix> ---> procedure\r
+ ! ^ ! ^ !\r
+ !----------! !------------! !\r
+ !\r
+ <-------------------------------------------------------!\r
+ ! !\r
+ !--> <formal parameter list> -------------------------->!\r
+ !\r
+ <------------------------- ; ---------------------!\r
+ !\r
+ !--> <subprogram body> ------------------------------>\r
+ ! ^\r
+ !-> <procedure identifier>->!\r
+ \r
+ \r
+ \r
+ <procedure identifier> :\r
+ \r
+ ---- <identifier> ------->\r
+ \r
+ \r
+ <function declaration>:\r
+ \r
+ --> virtual --> <function identifier>--> : --> <prefix> --> function\r
+ ! ^ ! ^ !\r
+ !----------! !-----------! !\r
+ !\r
+ !<------------------------------------------------------------!\r
+ ! !\r
+ !-> <formal parameter list> ---------> : ----> <type identifier>->\r
+ !\r
+ !<-------------------- ; ----------------------------!\r
+ !\r
+ !-> <subprogram body> ------------------------------->\r
+ ! ^\r
+ !-> <function identifier>->!\r
+ \r
+ \r
+ \r
+ <function identifier>:\r
+ \r
+ -----> <identifier> ---------->\r
+ \r
+ \r
+ \r
+ \r
+ Class (function, procedure) identifier may optionally follow the end\r
+ symbol (and if present must match the unit name).\r
+1 - 35 -\r
+ \r
+ \r
+ Example.\r
+ --------\r
+ \r
+ unit Euclid: function(n, m:integer):integer;\r
+ var k:integer;\r
+ begin\r
+ do\r
+ k:=n mod m;\r
+ if k=0 then result:=m; return fi;\r
+ n:=m; m:=k;\r
+ od;\r
+ end Euclid;\r
+ \r
+ \r
+ \r
+ 5.3.3. Block\r
+ ************\r
+ \r
+ \r
+ In order to complete the description of LOGLAN-82 units the block syntax\r
+ is given here, however the occurrence of a block results in the execution\r
+ of its statements - see 9.1.2..\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <block>:\r
+ \r
+ --> pref --> <prefix> ---> <actual parameter list> ---> block ---->\r
+ ! ^ ^ !\r
+ !-------------------->!--------------------------->! !\r
+ !\r
+ !<------------------------------------------!\r
+ !\r
+ !--> <subprogram body>------>\r
+ \r
+ Example.\r
+ --------\r
+ \r
+ block\r
+ var a, b, c, p, S:real;\r
+ begin\r
+ read(a, b, c);\r
+ p:=(a+b+c)/2;\r
+ S:=sqrt(p*(p-a)*(p-b)*(p-c));\r
+ write(S)\r
+ end\r
+1 - 36 -\r
+ \r
+ \r
+ 5.3.4. Prefixing\r
+ ****************\r
+ \r
+ \r
+ A unit which is a specialized form of a certain class (i.e., which has\r
+ all the properties of that class and some additional properties defined in\r
+ the unit) can be defined by means of prefixing. An identifier of the\r
+ prefixed unit may serve as a prefix for another unit, and so tree\r
+ structured hierarchies of units can be created. By a prefix sequence of a\r
+ unit M we mean a sequence M1, ..., Mk of units such that Mk = M, the unit\r
+ M1 has no prefix; for i = 1, ..., k-1, the unit Mi+1 is prefixed by Mi. Any\r
+ unit may be prefixed by a class without changing its character (e.g., a\r
+ prefixed procedure still remains a procedure). Procedures, functions, and\r
+ blocks cannot be used as prefixes. Process and coroutine, as special cases\r
+ of class, may also serve as prefixes, but not for procedures, functions or\r
+ blocks.\r
+ \r
+ If a coroutine (a process) occurs in a prefix sequence of a unit then\r
+ this unit is treated as a coroutine (a process), and so it has all the\r
+ properties of a coroutine (a process). Therefore, if a prefix sequence of a\r
+ unit M contains both a coroutine and a process then M has the properties of\r
+ a coroutine as well as those of a process.\r
+ \r
+ No unit is allowed to occur more than once in its prefix sequence.\r
+ \r
+ Put T pref* S if a unit T belongs to the prefix sequence of the unit S.\r
+ Unit S is called a subunit of unit T. As one can see from the definition of\r
+ object, any object of S has the attributes of the units S and T. Moreover,\r
+ the statements of that object come from the body of the unit T as well as\r
+ from that of the unit S.\r
+ \r
+ From the way of implementation it follows that prefixing is not a\r
+ macro-definition and so it does not require any pre-processing.\r
+1 - 37 -\r
+ \r
+ \r
+ 5.3.5. Formal parameters\r
+ ************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <formal parameter list>:\r
+ \r
+ ---> ( -----> <input parameters> ---------------> ) ---->\r
+ ^ ! ^ !\r
+ ! !--> <output parameters> -->! !\r
+ ! ! ! !\r
+ ! !--> <inout parameters> --->! !\r
+ ! ! ! !\r
+ ! !--> <type parameters> ---->! !\r
+ ! ! ! !\r
+ ! !--> <procedure parameter>->! !\r
+ ! ! ! !\r
+ ! !--> <function parameter> ->! !\r
+ ! !\r
+ !<----------- ; <------------------!\r
+ \r
+ \r
+ <input parameters>:\r
+ \r
+ ----> input -----> <specification list> ------->\r
+ ! ^\r
+ !----------->!\r
+ \r
+ \r
+ <output parameters>:\r
+ \r
+ ----> output ----> <specification list> ------->\r
+ \r
+ \r
+ <inout parameters>:\r
+ \r
+ ----> inout ----> <specification list> ------->\r
+ \r
+ \r
+ <type parameters>:\r
+ \r
+ ----> type ------> <identifier list> ----------->\r
+ \r
+ \r
+1 - 38 -\r
+ \r
+ \r
+ <procedure parameter>:\r
+ \r
+ ----> procedure ---> <procedure identifier> ---->!\r
+ !\r
+ !<-----------------------------------------!\r
+ !\r
+ !---> <formal parameter simp. list> ------>\r
+ ! ^\r
+ !----------------------------------->!\r
+ \r
+ <function parameter>:\r
+ \r
+ ---> function --> <function identifier> ------>!\r
+ !\r
+ !<----------------------------------------------!\r
+ !\r
+ !--> <formal parameter simp. list> --> : --> <type identifier> -->\r
+ ! ^\r
+ !-------------------------------->!\r
+ \r
+ \r
+ <formal parameter simp. list>:\r
+ \r
+ -------> ( --------> <input parameters> -----------------> ) ----->\r
+ ^ ! ^ !\r
+ ! !--> <output parameters> ->! !\r
+ ! ! ! !\r
+ ! !--> <inout parameters> -->! !\r
+ ! ! ! !\r
+ ! !--> <type parameters> --->! !\r
+ ! ! ! !\r
+ ! !-> <proc. simp. param.>-->! !\r
+ ! ! ! !\r
+ ! !--> <func. simp. param.>->! !\r
+ ! !\r
+ <----------------- ; <-------------------!\r
+ \r
+ \r
+ <procedure simp. parameter>:\r
+ \r
+ ----> procedure -----> <procedure identifier> ------>\r
+ \r
+ \r
+ <function simp. parameter>:\r
+ \r
+ ----> function -------> <function identifier> ------->\r
+1 - 39 -\r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ \r
+ By a formal parameter list of a unit M we shall mean a concatenated list\r
+ of formal parameters of the bodies of all units M1, ...., Mk = M from the\r
+ prefix sequence of unit M (successively from 1 to k). The parameters\r
+ occurring in a unit declaration are called formal parameters to stress that\r
+ they constitute a pattern for parameters occurring in the unit body. At the\r
+ instant of object generation the actual parameters for this generation are\r
+ fixed. The relations between formal and actual parameters depend on the\r
+ transmission mode which is specified in the formal parameter list.\r
+ \r
+ Those relations make possible the communication between a unit and its\r
+ environment. The first mode of transmission rectricts the communication to\r
+ the input (as the beginning of the body) of the actual parameter value for\r
+ the corresponding formal parameter. The second mode restricts the\r
+ communication to the output (as the end of the body) of the formal\r
+ parameter value for the corresponding actual parameter. The third mode\r
+ possesses both possibilities of the input and output transmission modes. In\r
+ all three cases, the formal parameters are considered to be declared in the\r
+ unit body.\r
+ \r
+ The next two modes of transmission are designed for subprograms and\r
+ types. The occurrence of a formal subprogram/type in the unit body is\r
+ matched with the corresponding actual subprogram/type (which is assigned at\r
+ the beginning of the body execution). In the case of a formal subprogram, a\r
+ simplified description of its parameters is required.\r
+ \r
+ Hence a LOGLAN-82 unit may be parametrized and designates the union of\r
+ all units definable by assigning specific actual types to the formal ones.\r
+ The actual type cannot be a primitive one. Parametrized units make possible\r
+ the design of universal algorithms, which will be defined in detail at\r
+ lower levels of program nesting.\r
+1 - 40 -\r
+ \r
+ \r
+ 5.3.6. Unit body\r
+ ****************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <class body>:\r
+ \r
+ ---> <inheritance list> ---> <protection list> ---> <body> ----->\r
+ ! ^ ! ^\r
+ !--------------------->! !------------------->!\r
+ \r
+ \r
+ <subprogram body>:\r
+ \r
+ ----> <inheritance list> ------> <body> ------>\r
+ ! ^\r
+ !---------------------->!\r
+ \r
+ \r
+ <inheritance list>:\r
+ \r
+ ----> taken -----> <identifier list> -----> ; ---->\r
+ ! ^\r
+ !-----------------------!\r
+ \r
+ \r
+ <protection list>:\r
+ \r
+ ------------> hidden -------------------> <identifier list> --> ; --->\r
+ ! ! !\r
+ !---------> close ------------>! !\r
+ ! !\r
+ !<--------------------------------------------------------------!\r
+ \r
+ \r
+ \r
+ <body>:\r
+ \r
+ ----> <declaration list> ---->!\r
+ ! !\r
+ <handlers' declaration> ---> begin --> <statement list> --> end -->\r
+ ! ^\r
+ !---------------------------!\r
+1 - 41 -\r
+ \r
+ \r
+ <declaration list>:\r
+ \r
+ !------------------------------------>!\r
+ ! !\r
+ --------> <declaration> -------> ; ---------------->\r
+ ^ !\r
+ !<------------------------------!\r
+ \r
+ \r
+ <statement list>:\r
+ \r
+ ------> <statement > ------->\r
+ ^ !\r
+ !<----- ; ------------!\r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ In a unit body, a sequence of statements (if any) starts from the begin\r
+ symbol. Declarations/statements are separated by semicolons. An execution\r
+ of the unit body begins at the time of the generation of an object (of that\r
+ unit), see 9.1.2.. A declaration of a unit M is restricted at several\r
+ points :\r
+ \r
+ Restrictions\r
+ ------------\r
+ \r
+ (i) The least (textual) unit containing an occurrence of a\r
+ control statement inner (see 9.1.3.) must be a generalized\r
+ class. An inner statement may occur in the class body at\r
+ the most once. If it does not occur explicitly then the\r
+ body of unit M is assumed to contain the inner statement as\r
+ the last one (preceding the end symbol).\r
+ \r
+ (ii) All identifiers defined in the body of unit M are\r
+ different.\r
+ \r
+ (iii) The input/output formal parameters of unit M cannot be of a\r
+ type declared in unit M.\r
+ \r
+ (iv) If a type T is a formal parameter of unit M then its\r
+ occurrence in the list of parameters must precede the\r
+ occurrences of other parameters whose description makes use\r
+ of T;\r
+1 - 42 -\r
+ \r
+ \r
+ 6. Static and dynamic locations of identifiers. Visibility rules.\r
+ #################################################################\r
+ \r
+ \r
+ As noted before, a non-system identifier used in a program must be\r
+ defined in the program by a declaration or by a description in a formal\r
+ parameter list. An identifier need not correspond, however, to only one\r
+ syntactic entity. A program is composed of units, and so the user designing\r
+ a unit must pay attention to the relationship between a given unit and the\r
+ other ones. He should feel free to define his own attributes with the same\r
+ identifiers as those used in the other units as long as he is not\r
+ interested in the entities they describe. Therefore some strict rules of\r
+ correspondence between the identifier and the attribute as well as its\r
+ valuation are necessary. The first correspondence is called the static\r
+ location of an identifier, and the second is called the dynamic location.\r
+ The static location is determined by the syntactic structure of a program.\r
+ The dynamic location depends on the dynamic configuration of objects.\r
+ \r
+ \r
+ 6.1. Unit attributes\r
+ *********************\r
+ \r
+ \r
+ A set of attributes is assigned to each unit M. This set consists of all\r
+ syntactic entities defined in M and in the prefix sequence of M. Most of\r
+ them form the set of attributes which belong to each object of the unit,\r
+ i.e., they are dynamic. Virtual functions and procedures are attributes of\r
+ a very special kind. They are presented separately in 6.4.1. Some other\r
+ attributes, like constants, are static, i.e., they are not attrributes of\r
+ the objects of the unit but of the unit itself. Therefore static attributes\r
+ cannot be accessed by means of dot notation (cf 8.2.3.).\r
+ The user may protect attributes. The protection mechanisms are introduced\r
+ in the following sections and discussed in 8.2.3.\r
+ LOGLAN-82 identifiers cannot be overloaded, i.e., an identifier used in\r
+ the given unit corresponds to "exactly one" attribute determined by the\r
+ context. However, identifiers may be redefined. Therefore strict\r
+ correspondence between the occurrences of the identifiers and the\r
+ attributes must de defined.\r
+ Let W be a syntactic entity and M a syntactic unit. We say that W is\r
+ defined in M iff W is a formal parameter of M (but not of the prefix of M)\r
+ or W is declared in M. If W is defined in M, the entity it denotes is the\r
+ meaning of W. From now on we shall use interchangeably the notions of an\r
+ identifier and of an attribute.\r
+ Let W be an identifier and M a unit. If W is defined in M or in a unit\r
+ from M's prefix sequence, then W corresponds to an attribute of M. More\r
+ precisely, the corresponding attribute is the one defined in M, if it\r
+ exists, or the one defined in the prefix sequence. That means that the\r
+ redefinition of an identifier in a prefixed unit covers the attribute\r
+ corresponding to that identifier.\r
+1 - 43 -\r
+ \r
+ \r
+ 6.2. Protected attributes\r
+ *************************\r
+ \r
+ Let us consider a declaration of a prefixed unit. Let M be such a unit\r
+ and N its prefix. The attributes of N are visible in M (unless covered by\r
+ the local redefinition). The user, however, can restrict the use of N's\r
+ attributes in M. The protection may be specified already in unit N as well\r
+ as in M. The first way corresponds to the hidden specification while the\r
+ second to the taken specification.\r
+ \r
+ \r
+ 6.2.1. Hidden attributes\r
+ ************************\r
+ \r
+ \r
+ A list of hidden attributes is a filter from the prefixing unit. The user\r
+ may specify within prefix N the attributes whose occurrence is illegal in\r
+ any unit prefixed by N (unless the identifiers of these attributes are\r
+ covered by the redeclarations). Remote access to such attributes is\r
+ forbidden as well (cf 6.2). The absence of hidden specification denotes the\r
+ empty list.\r
+ Consider an example:\r
+ \r
+ unit N : class;\r
+ hidden x, y, z;\r
+ var x, y, z:integer;\r
+ ...\r
+ end N;\r
+ \r
+ unit M:N class;\r
+ hidden x, t;\r
+ var x, y, t:integer;\r
+ ...\r
+ end M;\r
+ \r
+ Variables x, y declared in N are redeclared in M, and so the identifiers\r
+ x, y in M refer to the local entities. Variable t is declared in M and is\r
+ hidden in the units prefixed by M. Variable z is hidden in N, hence it\r
+ cannot be used in M.\r
+1 - 44 -\r
+ \r
+ \r
+ 6.2.2. Taken attributes\r
+ ***********************\r
+ \r
+ \r
+ The list of taken attributes is a filter on the prefixed unit. In unit M\r
+ the user may specify explicitly the attributes from prefix N which are used\r
+ in M. Then in M the only attributes accessible from N are those from the\r
+ taken list. The occurrence of another attribute from N in M's body is\r
+ illegal. The absence of taken specification denotes the list of all (legal\r
+ and not hidden) identifiers from N. This means that the user is not\r
+ interested in the specification of this kind of filtering.\r
+ The identifiers in the taken list must be defined in the prefix sequence,\r
+ not in unit M. An exception is an identifier of a virtual attribute (cf\r
+ 6.4.).\r
+ \r
+ \r
+ 6.2.3. Legal and illegal identifiers\r
+ ************************************\r
+ \r
+ In this section we consider only identifiers corresponding to the\r
+ attributes of a given unit.\r
+ \r
+ All identifiers defined in a unit are legal in that unit. In particular,\r
+ all identifiers declared in a non-prefixed unit are legal.\r
+ \r
+ Now let M be a unit, N its prefix and W an identifier not defined in M.\r
+ Then W is a legal identifier corresponding to an attribute of M iff\r
+ \r
+ \r
+ - W is legal in N\r
+ - W does not occur in the hidden list in N\r
+ - W occurs in the taken list in M or this list is absent\r
+ \r
+ \r
+ All identifiers specified in every context in a unit must be legal in\r
+ that unit. All identifiers specified in the taken list must be legal in the\r
+ prefix.\r
+ \r
+ An identifier is illegal in a unit iff it denotes an attribute of the\r
+ unit (according to 6.1) and that attribute is not legal.\r
+1 - 45 -\r
+ \r
+ \r
+ 6.2.4. Close attributes\r
+ ***********************\r
+ \r
+ \r
+ Close attributes are not accessible by means of remote access (cf.\r
+ 8.2.3.) outside the unit.\r
+ \r
+ Let M be a unit with the prefix sequence M1, ..., Mk=M. An attribute W of\r
+ unit M is called a close attribute if W occurs in the close list of Mj for\r
+ some j, 1<=j<=k, and W is not redefined in any unit following that Mj in\r
+ the prefix sequence. However, remote access to a close attribute W is\r
+ allowed within the text of the unit M specifying it to be close, i.e., if\r
+ the static qualification of the object expression is equal to M, remote\r
+ access to W is allowed in all the units declared (directly or indirectly)\r
+ in M.\r
+ \r
+ The list of close attributes must consist of legal identifiers. All\r
+ hidden attributes are simultaneously close attributes.\r
+ \r
+ \r
+ Example\r
+ -------\r
+ \r
+ block\r
+ var v:A;\r
+ unit A: class;\r
+ hidden z;\r
+ close x;\r
+ var x, z:real, y:A;\r
+ \r
+ unit B:A class;\r
+ var t:B;\r
+ begin\r
+ \r
+ ... z ... (* is illegal since hidden in A *)\r
+ ... x ... (* is legal *)\r
+ .. y.x+y.z .. (* is legal since y is qualified by A\r
+ and the expression is within A *)\r
+ ... t.x .. (* is illegal since t is qualified by B *)\r
+ \r
+ end B;\r
+ begin\r
+ \r
+ ... v.x+y.x .... (* is legal *)\r
+ \r
+ end A;\r
+ \r
+ begin (* outside A *)\r
+ \r
+ ... v.z .. (* is illegal since hidden, and so close as well *)\r
+ ... v.y.x ... (* is illegal since x is close *)\r
+ end\r
+1 - 46 -\r
+ \r
+ \r
+ 6.3. Static location\r
+ *********************\r
+ \r
+ \r
+ We say that the occurrence of an identifier W is in a unit M if M is the\r
+ syntactic unit most tightly enclosing that occurrence. On the basis of the\r
+ program structure every occurrence of an identifier W in a unit M can be\r
+ unequivocally related to a unit N, where the corresponding attribute W is\r
+ defined. The unit N is called the static container for that occurrence of W\r
+ in M and is denoted by SC(W, M).\r
+ More precisely, by a static container of an occurrence of an identifier W\r
+ in a unit M we mean a syntactic unit N such that:\r
+ \r
+ - W is defined in N\r
+ \r
+ - there exists a unit P satisfying the following conditons:\r
+ \r
+ \r
+ (1) N belongs to the prefix sequence of P (or is P),\r
+ (2) M is declared in P directly or indirectly,\r
+ (3) there is no other unit closer to M than P satisfying (2) in\r
+ which W is an attribute,\r
+ (4) N is P's nearest prefix defining W\r
+ (5) if W is illegal (hidden or not taken) in P, then the static\r
+ container is undefined.\r
+ \r
+ The following figure illustrates this definition\r
+ \r
+ the prefix sequence of P\r
+ P <-------- R <------------ SC(W,M)=N ... declaration of W ...\r
+ ^\r
+ !\r
+ .\r
+ .\r
+ .\r
+ ^\r
+ !\r
+ M ... the occurrence of W ...\r
+ \r
+ \r
+ The static location of an identifier W is defined for the occurrence of W\r
+ in a unit M iff there exists a static container SC(W, M). Every program\r
+ must be an expression in which the static location is defined for all\r
+ occurring identifiers.\r
+ The static container is sufficient to determine the static attribute of a\r
+ unit (constant).\r
+1 - 47 -\r
+ \r
+ \r
+ Example.\r
+ --------\r
+ \r
+ Consider the following program\r
+ \r
+ block\r
+ unit M: class; var X ... end M;\r
+ unit N: M class; var X ... end N;\r
+ begin\r
+ pref N block (* P *)\r
+ var Y : ...;\r
+ unit R: class;\r
+ ... X ... Y ...\r
+ end R;\r
+ begin\r
+ new R;\r
+ ...\r
+ pref N block (* S *)\r
+ var Y : ...,\r
+ unit T: R class;\r
+ ... X ... Y ...\r
+ end T;\r
+ begin\r
+ new T;\r
+ ...\r
+ end S;\r
+ end P;\r
+ end\r
+ \r
+ \r
+ Here we have\r
+ \r
+ SC(X, R)=SC(X, T)=N\r
+ and SC(Y, R)=P, SC(Y, T)=S.\r
+1 - 48 -\r
+ \r
+ \r
+ 6.4. Objects\r
+ *************\r
+ \r
+ \r
+ \r
+ \r
+ An object O of type M with the prefix sequence M1, ..., Mk=M (k=>1) is:\r
+ \r
+ - a k-tuple of the form O = (<V1, M1>, ... <Vk, Mk>) where Vi\r
+ is the valuation of non-static attributes defined in the\r
+ unit Mi,\r
+ \r
+ \r
+ - and a unique reference pointing to this k-tuple.\r
+ \r
+ \r
+ Since the references are unique, two objects are different even if their\r
+ tuples are identical.\r
+ \r
+ Now let us define the valuation of an attribute of object O, depending on\r
+ the kind of that attribute:\r
+ \r
+ - the valuation of variables and variable parameters gives\r
+ their values,\r
+ \r
+ - the valuation of an attribute which is a subprogram is the\r
+ text of its declaration and an environment. (The environment\r
+ is the object containing the declaration of the subprogram.\r
+ In the case of a formal subprogram the value is determined\r
+ by the actual one (see 9.1.2.). The case of virtuals is\r
+ discussed below.)\r
+ \r
+ - an attribute which is a type has the value of the form:\r
+ (array_of)<j> text of declaration.\r
+1 - 49 -\r
+ \r
+ \r
+ 6.4.1. Virtual attributes\r
+ *************************\r
+ \r
+ \r
+ The main feature of virtual atributes is that a redeclaration of an\r
+ identifier denoting a virtual subprogram in a prefixed unit does not cover\r
+ the declaration in the prefix but replaces it in all occurrences. The\r
+ replacement takes place in the so-called virtual chains of identifiers. We\r
+ define this notion below.\r
+ Let F be a subprogram and M a unit. By a virtual chain of F in M we mean\r
+ a sequence of virtuals corresponding to the maximal subsequence N1, ..., Nk\r
+ of the prefix sequence of M such that:\r
+ \r
+ (1) F is a legal identifier in every Ni and denotes an attribute\r
+ specified as virtual (unit virtual F: ...)\r
+ (2) In all the units Ni except Nk, F must not occur in the\r
+ hidden list\r
+ (3) In all the units except N1, F must occur in the taken list\r
+ unless the list is not specified. F must not occur in the\r
+ taken list in N1 if the list is specified.\r
+ (4) After removing the declaration of F from N1, F should be an\r
+ illegal attribute in N1 (hidden in the prefix, not taken) or\r
+ should denote a non-virtual attribute\r
+ (5) If Nk is not M, then one of the following conditions must be\r
+ satisfied:\r
+ - F occurs in the hidden list in Nk,\r
+ - F does not occur in the taken list in the unit\r
+ prefixed directly by Nk if the list is\r
+ specified,\r
+ - F is redefined in the unit prefixed directly\r
+ by Nk as a non-virtual attribute (then it must\r
+ not occur in the taken list either).\r
+ The class Nk from the definition is called the end of the virtual chain.\r
+ For a given unit and an identifier there may exist more than one virtual\r
+ chain.\r
+1 - 50 -\r
+ \r
+ \r
+ Example 1.\r
+ ----------\r
+ \r
+ \r
+ M unit virtual F: <M-body>\r
+ \r
+ N unit virtual F: <N-body>\r
+ \r
+ P .... F ....\r
+ \r
+ R unit F: <R-body>\r
+ \r
+ S unit virtual F: <S-body>\r
+ hidden F;\r
+ \r
+ T unit F: <T-body>\r
+ \r
+ We have three virtual chains of F with respect to T. One is for F from the\r
+ classes M and N:\r
+ (F: <M-body>), (F: <N-body>),\r
+ The second is for F from the class S:\r
+ (F: <S-body>)\r
+ And the third one is for F in T:\r
+ (F: <T-body>)\r
+ \r
+ \r
+ Restrictions\r
+ ------------\r
+ \r
+ (i) All virtual attributes belonging to the same virtual chain must be of\r
+ the same kind (either function or procedure),\r
+ \r
+ (ii) All the declarations of the virtuals belonging to the same virtual\r
+ chain must have formal parameter lists of the same pattern, in particular:\r
+ \r
+ - the lists may use different names of formal parameters,\r
+ but the correspondence between formal types must remain\r
+ valid,\r
+ \r
+ - the class types of corresponding formal variables or\r
+ functions must belong to the same prefix sequence,\r
+ \r
+ - the types of variable parameters or formal functions in\r
+ the ending of the virtual chain must not be less strongly\r
+ defined than the types of the corresponding parameters in\r
+ the beginning, i.e., a formal or system type against a\r
+ statically defined type,\r
+ \r
+ - the types of virtual functions must be identical or the\r
+ type of the function from the beginning of the virtual\r
+ chain must be a prefix of the type of the function from\r
+ the ending,\r
+ \r
+ (iii) The compatibility of virtuals must be defined statically.\r
+1 - 51 -\r
+ \r
+ \r
+ Example 2.\r
+ ----------\r
+ \r
+ (1)\r
+ The following lists are not compatible\r
+ .... (type T; type P; X: T; Y: P) ....\r
+ .... (type R; type S; X: S; Y: R) ....\r
+ \r
+ \r
+ (2)\r
+ The following lists are compatible iff M and N belong to the same prefix\r
+ sequence (and both are classes)\r
+ .... (type T; Z: T; Z1: M) ....\r
+ .... (type P; X: P; Y: N) ....\r
+ \r
+ \r
+ (3)\r
+ The following lists are compatible iff M denotes a system type (coroutine\r
+ or process) or is a formal type\r
+ \r
+ at the beginning: (X: M; Y: real)\r
+ at the ending: (X:coroutine; Y:real)\r
+ \r
+ (4)\r
+ The following lists are not compatible:\r
+ \r
+ ... (Y:integer)\r
+ ... (Y:real)\r
+ \r
+ (5)\r
+ The lists of the function from the beginning of the chain\r
+ \r
+ ... function (Z:integer; Z1:P) : M\r
+ \r
+ and from the ending\r
+ \r
+ ... function (Z:integer; Z1:P) :N\r
+ \r
+ are compatible iff M is a prefix of N.\r
+1 - 52 -\r
+ \r
+ \r
+ 6.4.2. Valuation of virtuals\r
+ ****************************\r
+ \r
+ \r
+ Let O be an object of type M with the prefix sequence M1, ..., Mk=M. The\r
+ value of virtual attribute F declared in Mi is:\r
+ \r
+ - the text of the declaration taken from the end of the virtual chain,\r
+ - the environment of the object O.\r
+ \r
+ Example\r
+ -------\r
+ An object of the class T given in the example 1 from 6.4.1 is of the\r
+ following form:\r
+ \r
+ ---------------------------------------------\r
+ ! ! !\r
+ ! F : body F from N ! M !\r
+ ---------------------------------------------\r
+ ! ! !\r
+ ! F : body F from N ! N !\r
+ ---------------------------------------------\r
+ ! ! !\r
+ ! ! P !\r
+ ---------------------------------------------\r
+ ! ! !\r
+ ! F : body F from R ! R !\r
+ ---------------------------------------------\r
+ ! ! !\r
+ ! F : body F from S ! S !\r
+ ---------------------------------------------\r
+ ! ! !\r
+ ! F : body F from T ! T !\r
+ ---------------------------------------------\r
+ \r
+ \r
+ The name "virtual subprogram" is derived from the features of virtual\r
+ entities, i.e., in any class a virtual subprogram F with an empty statement\r
+ list can be declared and then used as a virtual entity within the body of\r
+ the class. The user can assume the results of its execution without\r
+ knowledge of its internal structure. He can declare in a subclass a virtual\r
+ subprogram F again. This declaration replaces the previous one. So, during\r
+ the calls of the subprogram F in the body of the class as well as in the\r
+ body of the subclass, the subprogram with the text defined in the subclass\r
+ will be executed. This replacement is done only if F is a virtual attribute\r
+ of the subclass. Otherwise the new declaration of F covers the virtual\r
+ attribute of the class.\r
+1 - 53 -\r
+ \r
+ \r
+ \r
+ \r
+ Abstention from those rules permits us:\r
+ \r
+ (i) to define the types of the parameters of a virtual subprogram and to\r
+ check them already at compilation time,\r
+ \r
+ (ii) to execute the virtual subprogram declared at the beginning of the\r
+ prefix sequence; its body may be empty, but it is always defined,\r
+ \r
+ (iii) to end the virtual chain and to cover a virtual identifier by a\r
+ redeclaration.\r
+ \r
+ The possibilities (ii) and (iii) can be used in the following case. Let M\r
+ and N be system classes of the form :\r
+ \r
+ unit M: class;\r
+ unit virtual error: procedure;\r
+ (* virtual procedure to be defined in M's subclasses*)\r
+ end error;\r
+ begin\r
+ ...\r
+ if B1 then call error fi;\r
+ end M;\r
+ \r
+ unit N: M class;\r
+ unit virtual error: procedure;\r
+ (* the definition of the body of error. It\r
+ will be executed during the calls within N\r
+ as well as in M *)\r
+ end error;\r
+ begin\r
+ ...\r
+ if B2 then call error fi;\r
+ end N\r
+ \r
+ If the programmer prefixes his own units by class M, he can declare his\r
+ own virtual procedure error. If he does not intend to signalize any errors,\r
+ he is able to use M without a redeclaration. Then if the condition B1 is\r
+ satisfied, the procedure with an empty body will be called, i.e., no\r
+ statement will be executed. On the other hand, if the programmer uses N as\r
+ a prefix of his own units, he can redeclare his own non-virtual procedure\r
+ error. In consequence, during the execution of statements of the classes M\r
+ and N the procedure defined by this system in the class N will be executed.\r
+ However during the execution of the user's units the procedures defined by\r
+ himself will be executed.\r
+1 - 54 -\r
+ \r
+ \r
+ 6.5. Dynamic location\r
+ **********************\r
+ \r
+ An executable program must always be a well-formed expression. During its\r
+ execution we can deal with many objects of the same syntactic unit even at\r
+ the same time. Hence an execution of a statement (in an object) requires\r
+ identification and access to all the syntactic entities used. In order to\r
+ define the syntactic environment of object O (of unit M) a static link (SL)\r
+ is introduced. This link always points to an object O1 of a unit N such\r
+ that M is declared in N.\r
+ Let us consider the occurrence of identifier W within a body of class N\r
+ from the prefix sequence of M. Let SL(M) denote the SL-chain of objects\r
+ starting from an object of unit M. This means that SL(M) is a sequence of\r
+ objects O1, ..., Ok such that O1 is an object of unit M, Ok is an object of\r
+ the main program, the SL-link of object Oi points to object Oi+1, for every\r
+ i=1, ..., k-1.\r
+ \r
+ The dynamic container of the occurrence of W in a body of class N with\r
+ respect to an object O1 (denoted by DC(W, N, O1)) is an object Oi from\r
+ SL(M) such that:\r
+ \r
+ (*) Oi is an object of the unit prefixed by the static container SC(W,\r
+ N);\r
+ (**) Oi is the nearest object in the SL-chain such that Oi satisfies (*).\r
+ \r
+ Hence the dynamic container is the unique object which contains the\r
+ valuation of the entity W related to the occurrence of this entity. Let us\r
+ return to the example from 6.3.; after the creation (new T) of an object O\r
+ of the class T the SL-chain of O is as follows:\r
+ \r
+ -------------- ------------ ---------------\r
+ ! X ! M ! ! X ! M ! ! ! R !\r
+ <----- !------!-----! <------- !-----!----! <------ !-------!-----!\r
+ ! X ! N ! SL ! X ! N ! SL ! ! !\r
+ !------!-----! !-----!----! ! ! T !\r
+ OP ! Y,R ! P ! OS ! Y,T ! S ! O ! ! !\r
+ -------------- ------------ ---------------\r
+ \r
+ Because SC(X, R)=SC(X, T)=N , we have DC(X, R, O)=DC(X, T, O)=OS. Since\r
+ SC(Y, T)=S , we have DC(Y, T, O)=OS. On the other hand SC(Y, R)=P and DC(Y,\r
+ R, O)=OP.\r
+ The syntactic environment of an object is determined by the SL chain. Its\r
+ main property is that for each identifier occurrence in the statements of\r
+ the given object exists its dynamic container in the chain. In order to\r
+ define the dynamic location of identifier W occurring in object O of unit M\r
+ in a body of unit R (which belongs to the prefix sequence of M), the\r
+ following steps are performed:\r
+ \r
+ - a static container N=SC(W, R) is defined;\r
+ - a dynamic container O1=DC(W, R, O) is defined (in the SL chain of object\r
+ O, the nearest object O1 is found such that this object has a "layer" <V,\r
+ N>);\r
+ - a valuation V1(W) is found in the layers <V1, N1> of the object O1 such\r
+ that N1 is the nearest N's prefix.\r
+1 - 55 -\r
+ \r
+ \r
+ 7. Consistency of types\r
+ #######################\r
+ \r
+ In order to determine the context-sensitive correctness of an assignment\r
+ statement and parameter transmission it is necessary to introduce the\r
+ notion of the static consistency of types. Nevertheless this notion is not\r
+ sufficient to determine the correctness of the executions of those\r
+ constructs. Therefore, the notion of the dynamic consistency of types will\r
+ be introduced to define the semantic correctness of program. The introduced\r
+ distinction follows from the implementation constraints; namely, static\r
+ consistency is verified at compilation time, dynamic consistency is\r
+ verified at run time.\r
+ \r
+ \r
+ Static consistency of types\r
+ ---------------------------\r
+ \r
+ The type (array_of)<i>T is statically consistent with the type\r
+ (array_of)<j>S, where T and S are not array types, iff one of the following\r
+ conditions holds:\r
+ - i=j and T=S,\r
+ - i=j=0 and T, S are integer or real types,\r
+ - both T and S are formal types,\r
+ - T is a formal type, S is not a formal type and i<=j,\r
+ - S is a formal type, T is not a formal type and j<=i,\r
+ - i=j=0 and T, S are generalized class types and T pref* S or\r
+ S pref* T,\r
+ - i=j=0 and T and S are one of them a system type and the other a\r
+ generalized class or system type.\r
+ \r
+ \r
+ Dynamic consistency of types.\r
+ -----------------------------\r
+ \r
+ The type (array_of)<i>T is dynamically consistent with the type\r
+ (array_of)<j>S, where T and S are not array types, iff one of the following\r
+ conditions holds:\r
+ - i=j and T=S,\r
+ - i=j=0 and T, S are integer or real types,\r
+ - i=j=0 and T, S are generalized class types and T pref* S,\r
+ - i=j=0, T = coroutine, and S is declared as:\r
+ unit S: ... coroutine ...; or\r
+ unit S: ... process .....; or\r
+ unit S: R class..., where T is dynamically consistent with R,\r
+ - i=j=0, T = process, and S is declared as:\r
+ unit S: ... process .......; or\r
+ unit S: R class..., where T is dynamically consistent with R.\r
+ \r
+ At run time all formal types are replaced by actual non-formal ones.\r
+ Therefore, there is no reason to define dynamic consistency for formal\r
+ types.\r
+ Dynamic consistency is a subrelation of static consistency. Thus the\r
+ dynamic consistency is checked at compilation time, if possible. In other\r
+ cases the check is made at run-time.\r
+ From now on we shall use the following notation:\r
+ - for the desription of context properties, an occurrence of an\r
+ expression E is considered to be contained in the body of unit M,\r
+ - for the desription of semantic properties, an occurrence of an\r
+ expression E is considered to be contained in the body of unit M, with\r
+ respect to an object O of type M0 such that M pref* M0.\r
+1 - 56 -\r
+ \r
+ \r
+ 8. Expressions\r
+ ##############\r
+ \r
+ \r
+ Expressions are composed of primitive expressions - constants and\r
+ variables by means of system operators and functions. They serve as\r
+ patterns for computing a certain value. Two kinds of expression properties\r
+ have to be considered: context (static) and semantic (dynamic) ones.\r
+ \r
+ \r
+ \r
+ \r
+ Context properties.\r
+ -------------------\r
+ \r
+ We consider two context properties of each expression:\r
+ - to be a well-formed formula,\r
+ - to have a static type.\r
+ \r
+ The context correctness of an expression is examined at compilation time.\r
+ From now on, an expression is said to be a well-formed formula (shortly :\r
+ WFF) if it is statically correct. The static type of an expression is\r
+ determined by the program text.\r
+ \r
+ \r
+ \r
+ \r
+ Semantic properties.\r
+ --------------------\r
+ \r
+ We consider three semantic properties of each expression:\r
+ - to be defined,\r
+ - to have a dynamic type,\r
+ - to have the type of its value.\r
+ \r
+ In some cases (for expressions of formal types) type must be determined\r
+ at run-time. Replacing formal types by the corresponding actual ones in the\r
+ static types of expressions, we obtain the dynamic types of those\r
+ expressions. Notice, that the actual type may not be accessible, if the\r
+ dynamic container for the formal type of the expression was killed. The\r
+ dynamic type will be defined only for the expressions which may occur on\r
+ the left side of an assignment, i.e., for variables. When the value and the\r
+ type of the value are computed, the semantic correctness of the expression\r
+ is established.\r
+ From now on an expression is said to be defined if it is dynamically\r
+ correct at run-time. The correctness of an expression will be examined\r
+ under the assumption that it is a WFF. Five kinds of expressions are\r
+ distinguished: arithmetic, boolean, character, string, and object\r
+ expressions.\r
+1 - 57 -\r
+ \r
+ \r
+ 8.1. Constant\r
+ *************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <constant>:\r
+ \r
+ -----> <identifier> ----->\r
+ \r
+ CONTEXT.\r
+ --------\r
+ \r
+ Let E be a constant Q. The expression Q is a WFF if the static container\r
+ SC(Q, M) exists. The static type of Q is determined by its declaration (see\r
+ 5.1.). A constant cannot occur on the left side of an assignment statement,\r
+ as an actual output parameter, or in an expression X.Q, where X is an\r
+ object expression.\r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ The constant Q is always defined. The value of the constant is fixed from\r
+ the declaration of that constant and cannot be modified. The type of the\r
+ value is equal to the static type.\r
+ \r
+ \r
+ \r
+ 8.2. Variable\r
+ *************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <variable>:\r
+ \r
+ --------> <simple variable> ------------>\r
+ ! ^\r
+ !---> <subscripted variable>->!\r
+ ! !\r
+ !----> <dotted variable> ---->!\r
+ ! !\r
+ !----> <system variable> ---->!\r
+ \r
+ \r
+ For each kind of variables its context and semantic correctness will be\r
+ defined. Additionally the dynamic address of a variable will be defined as\r
+ a pair: (reference to an object, attribute of that object).\r
+1 - 58 -\r
+ \r
+ \r
+ 8.2.1. Simple variable\r
+ **********************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ (simple variable>:\r
+ \r
+ ----> <identifier> ----->\r
+ \r
+ \r
+ Let E be a variable Z.\r
+ \r
+ \r
+ CONTEXT.\r
+ --------\r
+ \r
+ The variable Z is a WFF if the static container SC(Z, M) = R exists. The\r
+ static type of Z is determined by the declaration of Z and may be a formal\r
+ one.\r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ The variable Z is defined if the dynamic container O1 = DC(Z, M, O)\r
+ exists. Let the static type of Z be: (array_of)<i>S. The dynamic type of Z\r
+ is equal to (array_of)<i>S in the case where S is not formal, otherwise it\r
+ is (array_of)<i+k>T, where the actual type corresponding to the formal one\r
+ is (array_of)<k>T.\r
+ The actual type is taken from the dynamic container DC(S, R, O1), i.e.,\r
+ from an object belonging to the SL chain of the object O1. The value of Z\r
+ is given by the corresponding valuation of Z in the object O1. The address\r
+ of Z is a pair: (the reference to O1, attribute Z of O1).\r
+1 - 59 -\r
+ \r
+ \r
+ 8.2.2. Subscripted variable\r
+ ***************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <subscripted variable>:\r
+ \r
+ --> <simple variable> --> ( -> <arithmetic expression> -----> ) -->\r
+ ^ !\r
+ !<----------- , --------------!\r
+ \r
+ \r
+ Let E be an expression of the form Z(A1, ..., Ak), where Z is a simple\r
+ variable and A1, ..., Ak are arithmetic expressions.\r
+ \r
+ CONTEXT.\r
+ --------\r
+ \r
+ Let (array_of)<i>S denote a static type of Z. The expression Z(A1, ...,\r
+ Ak) is a WFF if:\r
+ - Z and A1, ..., Ak are WFFs,\r
+ - static types of A1, ..., Ak are integer or real,\r
+ - 1<=k<=i.\r
+ The static type of E is (array_of)<i-k>S.\r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ The expression E is defined if:\r
+ - the expression Z(A1, ..., Ak-1) is defined and its value equals the\r
+ reference to a non-empty array object O1 with the bounds l and u, l<=u.\r
+ - the value of Ak is defined and its truncation l1 satisfies: l<=l1<=u.\r
+ The dynamic type of E is equal to the static one if S is not formal,\r
+ otherwise it is (array_of)<i-k+j>T where the actual type corresponding to\r
+ the formal one is (array_of)<j>T. The actual type is determined as for a\r
+ simple variable (see 8.2.1.). The value of E is that of the attribute (l1)\r
+ of the object O1. The address of E is the pair: (the reference to O1,\r
+ attribute (l1)).\r
+1 - 60 -\r
+ \r
+ \r
+ 8.2.3. Dotted variable\r
+ **********************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <dotted variable>:\r
+ \r
+ -> <qualified object expression> -->. --> <variable> ---->\r
+ \r
+ \r
+ It is sufficient to consider the expression E of the form X.Y, where Y is\r
+ a simple or subscripted variable.\r
+ \r
+ CONTEXT.\r
+ --------\r
+ \r
+ The expression E is a WFF if:\r
+ \r
+ \r
+ - X, Y are WFFs, X is the qualified object expression,\r
+ - the static type of X is a generalized class type,\r
+ - Y is a non-closed attribute of the static type of X.\r
+ \r
+ \r
+ The static type of E is the same as the static type of Y. Notice that the\r
+ static type of X cannot be a formal type.\r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ The expression E is defined if:\r
+ \r
+ \r
+ - the expression X is defined,\r
+ - the value of X is a reference to a non-empty object O1.\r
+ \r
+ \r
+ The dynamic type of E is the same as the dynamic type of Y would be if Y\r
+ occurred in the object O1. The value of X.Y is that of the attribute Y of\r
+ the object O1. The address of X.Y is the address of Y would be if Y\r
+ occurred in O1.\r
+1 - 61 -\r
+ \r
+ \r
+ 8.2.4. System variable\r
+ **********************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <system variable>:\r
+ \r
+ ------> result ---------------------------------------->\r
+ \r
+ \r
+ CONTEXT and SEMANTICS.\r
+ ----------------------\r
+ \r
+ For every function F there is an implicitly declared variable result of\r
+ type T of the value of function F. The initial value of that variable\r
+ depends on type T (is equal to the default value of type T), the final\r
+ value (after completion of a function call) is also the value of function F\r
+ for the given call (see 9.1.2.). An occurrence of the variable result is\r
+ matched with the smallest unit F which contains that occurrence and which\r
+ is a function.\r
+ \r
+ \r
+ Example.\r
+ --------\r
+ \r
+ unit Newton_symbol: function (i, k:integer): integer;\r
+ var j: integer;\r
+ begin\r
+ if i>= k and k>=0\r
+ then result:=1;\r
+ for j:=0 to k-1\r
+ do\r
+ result:=result*(i-j)div(j+1)\r
+ od\r
+ fi\r
+ end Newton_symbol;\r
+1 - 62 -\r
+ \r
+ \r
+ 8.3. Arithmetic expression\r
+ **************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <arithmetic expression>:\r
+ \r
+ !------------------->!\r
+ ! !\r
+ -----------> <sign> --------> <term> ------->\r
+ ^ !\r
+ !<--------------------------------!\r
+ \r
+ \r
+ \r
+ <sign>:\r
+ \r
+ -----> + ----->\r
+ ! ^\r
+ !-> - -->!\r
+ \r
+ \r
+ \r
+ <term>:\r
+ \r
+ ---------> <factor> ----------------->\r
+ ^ !\r
+ ! !<-------------------!\r
+ ! ! ! ! !\r
+ ! ! ! ! !\r
+ ! * / div mod\r
+ ! ! ! ! !\r
+ ! ! ! ! !\r
+ !<-----------------!\r
+ \r
+ \r
+ \r
+ <factor>:\r
+ \r
+ ------------------ <integer> -------------------------------->\r
+ ! ^ ! ^\r
+ !-<abs>-! !---> <real> ---------------------------->!\r
+ ! !\r
+ !--> <constant> ------------------------->!\r
+ ! !\r
+ !--> <variable> ------------------------->!\r
+ ! !\r
+ !------> <function call> ---------------->!\r
+ ! !\r
+ !-> ( -><arithmetic expression>-> ) ----->!\r
+1 - 63 -\r
+ \r
+ \r
+ <integer>:\r
+ \r
+ -----> <digit> ------>\r
+ ^ !\r
+ !<------------!\r
+ \r
+ \r
+ <real>:\r
+ \r
+ !-------->!\r
+ ! !\r
+ ---> <integer>--> . ---> <integer>----->E --> <sign>--> <integer> -->\r
+ ! ^ ! ^\r
+ !------------------>! !---------------------------->!\r
+ \r
+ \r
+ (function call will be defined in 9.1.2.).\r
+ \r
+ CONTEXT and SEMANTICS.\r
+ ----------------------\r
+ \r
+ The type of the value of an arithmetic expression is always equal to its\r
+ static type. The dynamic type is not to be defined. The context and\r
+ semantic properties of arithmetic expressions will be defined inductively.\r
+ \r
+ Factors.\r
+ The type of an integer is integer, the type of a real is real, their\r
+ values are given directly. Constant, variable, and function call must be\r
+ WFFs (in the meaning of 8.1., 8.2 and 9.1.2.), and of type integer or real\r
+ (in order to create a well-formed factor). The factor is defined iff the\r
+ variable and the function call are defined. The context and semantic\r
+ properties of the factors of the form " abs A1 ", and " (A2) " are the same\r
+ as those of arithmetic expressions A1 and A2, respectively. The value of "\r
+ abs A1 " is the absolute value of A1.\r
+ \r
+ \r
+ Terms.\r
+ The operators *, /, div, mod are interpreted as multiplication, division,\r
+ integer division and remaindering, respectively. The last two operators are\r
+ defined for integer arguments only, " A1 div A2 " is equal to the\r
+ truncation of A1/A2; " A1 mod A2 " is equal to the remainder of A1/A2. The\r
+ type of a term of the form <factor> <operator> <factor> is real if the\r
+ operator is /, or at least one of the arguments is of type real. The term "\r
+ A1/A2 " is defined if the value of A2 is different from 0. The value is\r
+ defined inductively if Av1 and Av2 are the values of factor A1 and term A2\r
+ respectively, and <W> is an interpretation of operator W, then the value of\r
+ a term of the form " A1 W A2 " is Av1 <W> Av2. If one of the arguments is\r
+ of type integer and the other is of type real then for the operators *, /\r
+ the integer type value is converted into a real type one.\r
+ \r
+ \r
+ Arithmetic expression.\r
+ An arithmetic expression of the form <term> <sign> <term> is of type\r
+ integer if both terms are of that type and it is of type real in the\r
+ opposite case. A value is defined inductively: if Av1 and Av2 are the\r
+ values of term A1 and arithmetic expression A2, respectively, then the\r
+ value of an expression A1+(-)A2 is Av1+(-)Av2, the value of +(-)A1 is\r
+ +(-)Av1. If one of the arguments is of type integer and the other is of\r
+ type real, then the integer type value is converted into a real type one.\r
+1 - 64 -\r
+ \r
+ \r
+ 8.4. Boolean expression\r
+ ***********************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <boolean expression>:\r
+ \r
+ -------> <boolean term> ---------------->\r
+ ^ !\r
+ !<---- or <---------------!\r
+ \r
+ \r
+ <boolean term>:\r
+ \r
+ ------> <boolean factor> ---------->\r
+ ^ !\r
+ !<---- and <------------!\r
+ \r
+ \r
+ <boolean factor>:\r
+ \r
+ ----> not ----> <boolean primary> ------------>\r
+ ! ^\r
+ !-------->!\r
+ \r
+ \r
+ <boolean primary>:\r
+ \r
+ --------> <boolean constant> -------------------->\r
+ ! ^\r
+ !----> <constant> -------------------->!\r
+ ! !\r
+ !----> <variable> -------------------->!\r
+ ! !\r
+ !----> <function call> --------------->!\r
+ ! !\r
+ !----> <relation> -------------------->!\r
+ ! !\r
+ !--> ( --> <boolean expression> ->)--->!\r
+ \r
+ \r
+ <relation>:\r
+ \r
+ -----> <arithmetic relation> --------------->\r
+ ! ^\r
+ !-> <boolean relation> ----------->!\r
+ ! !\r
+ !-> <character relation> --------->!\r
+ ! !\r
+ !-> <reference relation> --------->!\r
+ ! !\r
+ !-> <object relation> ------------>!\r
+ \r
+ \r
+ <boolean constant>:\r
+ \r
+ -----> false -------->\r
+ ! ^\r
+ !--> true --->!\r
+1 - 65 -\r
+ \r
+ \r
+ <arithmetic relation>:\r
+ \r
+ ---> <arithmetic expression> --> <arithmetic relational operator>\r
+ !\r
+ !<-----------------------!\r
+ !\r
+ !---> <arithmetic expression> ---->\r
+ \r
+ \r
+ <arithmetic relational operator>:\r
+ \r
+ ----> <equality operator> --------->\r
+ ! ^\r
+ !-> <inequality operator> -->!\r
+ \r
+ \r
+ <equality operator>:\r
+ \r
+ ----------> = ---------------->\r
+ ! ^\r
+ !------> =/= ------->!\r
+ \r
+ \r
+ <inequality operator>:\r
+ \r
+ --------------------------------->!\r
+ ! ! ! !\r
+ < > <= >=\r
+ ! ! ! !\r
+ !------------------------------->\r
+ \r
+ \r
+ <character relation>:\r
+ \r
+ ---> <character expression> --> <equality operator> -->\r
+ !\r
+ !<-----------------------------------------!\r
+ !\r
+ !---> <character expression> ----->\r
+ \r
+ \r
+ <reference relation>:\r
+ \r
+ ---> <object expression> --> <equality operator> -->\r
+ !\r
+ !<----------------------------------------------!\r
+ !\r
+ !---> <object expression> ------>\r
+ \r
+ \r
+ <object relation>:\r
+ \r
+ ---> <object expression> ----> is ------> <system type> ------->\r
+ ! ^ ! ^\r
+ !--> in -->! !--> <class type> ---->!\r
+1 - 66 -\r
+ \r
+ \r
+ CONTEXT and SEMANTICS.\r
+ ----------------------\r
+ \r
+ The context and semantic properties of boolean expressions can be defined\r
+ in the same way as those of arithmetic ones. A boolean expression is of\r
+ type boolean.\r
+ \r
+ Boolean primary.\r
+ The value of a boolean constant true and false is T and F, respectively.\r
+ The equality and inequality operators have the usual interpretation. Let\r
+ A1, A2 be two defined arithmetic expressions and let Av1, Av2 be their\r
+ values. Let <W> be an interpretation of the arithmetic relational operator\r
+ W. Then the value of arithmetic relation " A1 W A2 " is Av1 <W> Av2. If one\r
+ of the expressions is of type integer and the other is of type real then\r
+ the integer type value is converted into real type one.\r
+ \r
+ Let C1, C2 be two defined character expressions and let Cv1, Cv2 be their\r
+ values. Then the value of the character relation " C1=C2 " (" C1=/=C2 ") is\r
+ true iff the characters Cv1, Cv2 are identical (different). For string type\r
+ there are no relations, even no equality.\r
+ \r
+ A reference relation " X1=X2 " (" X1=/=X2 ") is a WFF if X1 and X2 are\r
+ well-formed object expression. The static types of the expressions have to\r
+ be statically consistent. The relation is defined if X1 and X2 are defined.\r
+ The value of that relation is true iff the values of both expressions are\r
+ equal to (different from) the same reference; in particular, if they are\r
+ both equal to none, then the value of " X1=X2 " is T.\r
+ An object relation "X is S" is a WFF if S is a generalized class\r
+ identifier, X is a WFF, and the static type of X is statically consistent\r
+ with S. An object relation "X in S" is a WFF if S is a generalized class or\r
+ system type identifier, X is a WFF, and the static type of X is statically\r
+ consistent with S. The value of the relation "X is S" is T iff the value of\r
+ the expression X is the reference to an object of class S. The value of the\r
+ relation "X in S" is T iff the value of X belongs to the set !S! .\r
+ \r
+ Boolean factor.\r
+ The value of a boolean factor "not B", where B is a boolean primary, is T\r
+ iff the value of B is F.\r
+ \r
+ Boolean term.\r
+ Let Bv2 and Bv1 be the values of boolean factor B2 and boolean term B1,\r
+ respectively. Then the value of a term of the form "B1 and B2" is T iff\r
+ Bv2=Bv1=T.\r
+ \r
+ Boolean expression\r
+ Let Bv1 and Bv2 be the values of boolean term B1 and boolean expression\r
+ B2, respectively. Then the value of an expression of the form "B1 or B2" is\r
+ F iff Bv1=Bv2=F.\r
+ \r
+ The value of the arithmetic and boolean expression is computed from left\r
+ to right with the following operator priorities:\r
+ (1) parentheses (, ), abs\r
+ (2) *, /, div, mod\r
+ (3) +, -\r
+ (4) <, <=, >, >=, =, =/=\r
+ (5) not\r
+ (6) and\r
+ (7) or.\r
+1 - 67 -\r
+ \r
+ \r
+ 8.5. Character expression\r
+ *************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <character expression>:\r
+ \r
+ ----> <character constant> --------------------->\r
+ ! ^\r
+ !---> <constant> --------------->!\r
+ ! !\r
+ !---> <variable> --------------->!\r
+ ! !\r
+ !---> <function call> ---------->!\r
+ \r
+ \r
+ <character constant>:\r
+ \r
+ ----> ' -----> <symbol> -----> ' ------>\r
+ \r
+ \r
+ <symbol>:\r
+ \r
+ -------> <letter> ---------------------------->\r
+ ! ^\r
+ !---> <digit> --------------->!\r
+ ! !\r
+ !---> <auxiliary sign> ------>!\r
+ ! !\r
+ !--> <other characters> ----->!\r
+ ! !\r
+ !-> (: --> <integer> --> :) ->!\r
+ \r
+ \r
+ \r
+ \r
+ CONTEXT and SEMANTICS.\r
+ ----------------------\r
+ \r
+ Constant, variable and function call are WFFs if they are of type\r
+ character. The standard function ord is defined for a character expression\r
+ and gives an integer value (dependent on implementation).\r
+1 - 68 -\r
+ \r
+ \r
+ 8.6. String expression\r
+ **********************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <string expression>:\r
+ \r
+ -----> <string constant> -------->\r
+ ! ^\r
+ !---> <constant> ------->!\r
+ ! !\r
+ !---> <variable> ------->!\r
+ ! !\r
+ !---> <function call> -->!\r
+ \r
+ \r
+ \r
+ <string constant>:\r
+ \r
+ ---> " -------> <character> ---------------------> " ----->\r
+ ! !\r
+ !<-------------------------------------!\r
+ \r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ Constant, variable and function call are WFFs if they are of string type.\r
+ The quotation mark " in the string constant is written twice "".\r
+ \r
+ Remark\r
+ ------\r
+ The string type is a constant type in the sense that the universe is\r
+ defined at compilation time and there are no string operations predefined\r
+ in the language. However, a standard function may transform a string into\r
+ an array of characters. Then the user can treat the array of character as a\r
+ text type and can define any set of suitable text operations.\r
+ \r
+ End of remark\r
+ -------------\r
+1 - 69 -\r
+ \r
+ \r
+ 8.7. Object expression\r
+ **********************\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <qualified object expression>:\r
+ \r
+ --------> <object expression>--------------------------------------->\r
+ ! ^\r
+ !--> <variable>--------> qua -> <class type identifier> -->!\r
+ ! ^\r
+ !--> <function call> -!\r
+ \r
+ <object expression>:\r
+ \r
+ ----------> <object constant> --------------------->\r
+ ! ^\r
+ !-----> <variable> ------------>!\r
+ ! !\r
+ !---> <function call> --------->!\r
+ ! !\r
+ !---> <object generator> ------>!\r
+ ! !\r
+ !----> <local object> --------->!\r
+ ! !\r
+ !-----> <process waiting> ----->!\r
+ \r
+ <object constant>:\r
+ \r
+ -----> none -------- >\r
+ \r
+ <local object>:\r
+ \r
+ ----> this ----> <class type> --------->\r
+ \r
+ \r
+ (Function call and object generator will be defined in 9.1.2, process\r
+ waiting will be defined in 11.1. Variable is described in 8.2.).\r
+1 - 70 -\r
+ \r
+ \r
+ CONTEXT.\r
+ --------\r
+ The constant none is of a fictitious type statically consistent with any\r
+ non-primitive type.\r
+ To define the context of a local expression let us recall that the\r
+ occurrence of the expression E is considered in the unit M. Let E be the\r
+ local object "this T", then E is a WFF if there exists a unit N such that M\r
+ decl* N and T pref* N, (i.e., there exists a unit N statically enclosing M\r
+ and containing T in its prefix sequence). The static type of the expression\r
+ E is T.\r
+ The qualified object expression of the form "X qua T" is a WFF if X is a\r
+ WFF and the static type of X is statically consistent with T. The static\r
+ type of this expression is T.\r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ The constant none is always defined as an empty object. Every compound\r
+ and system type is dynamically consistent with the fictitious type of none.\r
+ The value of the local object "this T" is the nearest object of the type T1\r
+ belonging to the SL chain of the object O such that T1 is prefixed by T,\r
+ (recall that O contains the given occurrence of the local object). The\r
+ expression "this T" is defined if its value exists. The dynamic type is not\r
+ to be defined. The type of the value is S. The qualified object expression\r
+ of the form "X qua T" is defined if X is defined, its value is different\r
+ from none, and the dynamic type of X as well as the type of its value are\r
+ dynamically consistent with T. The value of this expression is equal to the\r
+ value of X. The dynamic type is not to be defined.\r
+1 - 71 -\r
+ \r
+ \r
+ 9. Sequential statements.\r
+ ##########################\r
+ \r
+ \r
+ Sequential statements are patterns for the sequencing of primitive actions.\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <sequential statement>:\r
+ \r
+ --------> <primitive statement> ------------>\r
+ ! ^\r
+ !-------> <compound statement> ---->!\r
+ \r
+ \r
+ \r
+ In a similar way to that followed in the description of expressions we\r
+ shall consider context and semantic properties of statements. A statement\r
+ will be called a WFF if it is correct at compilation time, and said to be\r
+ defined if it is correct at run time.\r
+ \r
+ \r
+ \r
+ \r
+ \r
+ \r
+ 9.1. Sequential primitive statements\r
+ *************************************\r
+ \r
+ \r
+ The result of an execution of a primitive statement consists in the\r
+ modification of:\r
+ - the valuation (assignment statement);\r
+ - the configuration (allocation and deallocation statement);\r
+ - the control (control statement).\r
+ \r
+ By a configuration we mean the set of all objects existing at a given state\r
+ of computation.\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <primitive statement>:\r
+ \r
+ --------> <evaluation statement> ------------->\r
+ ! ^\r
+ !----> <configuration statement> ---->!\r
+ ! !\r
+ !----> <simple control statement> --->!\r
+ ! !\r
+ !----> <coroutine statement> -------->!\r
+ \r
+ \r
+1 - 72 -\r
+ \r
+ \r
+ 9.1.1. Evaluation statement\r
+ ****************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <evaluation statement>:\r
+ \r
+ --------> <empty statement> ---------------------->\r
+ ! ^\r
+ !----> <assignment statement> ------>!\r
+ ! !\r
+ !----> <copying statement> --------->!\r
+ \r
+ \r
+ \r
+ <empty statement>:\r
+ \r
+ --------------------------->\r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ An execution of an empty statement has no effect.\r
+ \r
+ \r
+ \r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <assignment statement>:\r
+ \r
+ ------> <variable list> ---> := --> <expression> ---->\r
+ \r
+ \r
+ <variable list>:\r
+ \r
+ ----------> <variable> ------> , --------------->\r
+ ! !\r
+ ! !\r
+ <---------------------------------\r
+ \r
+ \r
+ CONTEXT.\r
+ --------\r
+ \r
+ An assignment statement of the form y1, ..., yk:=e is a WFF if:\r
+ - variables y1, ..., yk and expression E are WFFs;\r
+ - the static types T1, ..., Tk of variables y1, ..., yk are statically\r
+ consistent with the static type S of the expression E.\r
+1 - 73 -\r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ The execution of a statement consists of three steps : prologue, body and\r
+ epilogue.\r
+ \r
+ In the prologue the computation of the addresses of variables y1, ..., yk\r
+ is performed, i.e.:\r
+ \r
+ - For a dotted variable of the form X.z, the value of the expression X is\r
+ computed;\r
+ - For a subscripted variable of the form Z(i1, ..., ij) the value of the\r
+ expression Z(i1, ..., ij-1) is computed. If Z is of a formal type, then the\r
+ dynamic type T of the variable Z is determined. Finally the value of the\r
+ expression ij is computed.\r
+ \r
+ The above actions are performed from left to right.\r
+ \r
+ \r
+ During the body the computation of the type and the value of expression E\r
+ is performed.\r
+ \r
+ \r
+ The epilogue checks if the statement is well-defined and assigns the\r
+ values to the attributes determined by the addresses evaluated during the\r
+ prologue.\r
+ \r
+ An assignment is defined, if:\r
+ - the expressions y1, .., yk, E are defined;\r
+ - the dynamic types of y1, .., yk are defined and are dynamically\r
+ consistent with the type of the value of E.\r
+ \r
+ The values are assigned from right to left, i.e., at first the value of E\r
+ is assigned to yk (with possible conversion to the type of yk), next the\r
+ value of yk is assigned to yk-1 (with appropriate conversion), and so on.\r
+ For example, when r is real, n is integer, then:\r
+ \r
+ after r, n:=2.5 we have n=2, r=2.0,\r
+ after n, r:=2.5 we have r=2.5, n=2.\r
+ \r
+ Remark.\r
+ -------\r
+ \r
+ The value of the expression Z computed at prologue may point to a non-empty\r
+ object O, but it could be changed to none as a result of the deallocation\r
+ of the object O (during the execution of the statement). It will be\r
+ detected at epilogue and will result in a run-time error.\r
+ \r
+ End of remark.\r
+ --------------\r
+1 - 74 -\r
+ \r
+ \r
+ An object of a compound type can be simultanously referenced by a number\r
+ of variables. If X and Y are the variables of such a type, then after\r
+ assignment X:=Y, both variables reference the same object. Hence some\r
+ side-effects may occur: the value of an attribute of the object referenced\r
+ by variable X can be changed as a result of an access to that object by\r
+ means of variable Y. In order to avoid such effects, one can use a copying\r
+ statement:\r
+ \r
+ X:=copy(Y)\r
+ \r
+ after which both variables reference identical objects but not the very\r
+ same one.\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <copying statement>:\r
+ \r
+ -> <variable list> -> := -> copy -> ( -> <object expression> -> ) ->\r
+ \r
+ \r
+ CONTEXT and SEMANTICS.\r
+ ----------------------\r
+ \r
+ The semantics of the copying statement differs from that of the assignment\r
+ statement in the following points:\r
+ \r
+ \r
+ - The copying statement is defined if the value of the right side object\r
+ expression E is a reference to a terminated class object (i.e., an object\r
+ whose all statements were completed, see 9.1.3). Coroutine or process\r
+ objects must not be copied.\r
+ \r
+ \r
+ - During the epilogue, the copy of the value of the expression E is\r
+ assigned (a copy of none is none).\r
+1 - 75 -\r
+ \r
+ \r
+ 9.1.2. Configuration statement\r
+ *******************************\r
+ \r
+ \r
+ Configuration statements correspond to the generation and deallocation of\r
+ units and arrays. Allocation of an array object is a result of array\r
+ generation, allocation of a unit object is a result of a subprogram call,\r
+ generation of a generalized class object or block statement.\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <configuration statement>:\r
+ \r
+ -----> <object allocation> ------->\r
+ ! ^\r
+ !--> <object deallocation> -->!\r
+ \r
+ \r
+ 9.1.2.1. Allocation statement\r
+ *****************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <object allocation>:\r
+ \r
+ ------> <function call> ----------------->\r
+ ! ^\r
+ !--> <procedure call> -------->!\r
+ ! !\r
+ !--> <object generation> ----->!\r
+ ! !\r
+ !---> <block statement>------->!\r
+ ! !\r
+ !--> <array generation> ------>!\r
+ \r
+ \r
+ <function call>:\r
+ \r
+ ---> <remote function identifier> ---> <actual parameter list> ---->\r
+ ! ^\r
+ !--------------------------->!\r
+ \r
+ \r
+ <procedure call>:\r
+ \r
+ --> call --> <remote procedure identifier> -->!\r
+ !\r
+ !<-----------------------!\r
+ !\r
+ !---> < actual parameter list> ------------>\r
+ ! ^\r
+ !----------------------------------->!\r
+1 - 76 -\r
+ \r
+ \r
+ <object generation>:\r
+ \r
+ --> <qualified object expression> --> . --> new -----!\r
+ ! ^\r
+ !--------------------------------------! !\r
+ !\r
+ !--------------------------------------------------!\r
+ !\r
+ !--> <class identifier>---> <actual parameter list> -------->\r
+ ! ^\r
+ !---------------------------!\r
+ \r
+ \r
+ <remote function identifier>:\r
+ \r
+ ----> <qualified object expression> --> . -->!\r
+ ! ^ !\r
+ !----------------------------------------! !\r
+ !\r
+ !--------------------------------------------!\r
+ !\r
+ !---> <function identifier> --->\r
+ \r
+ \r
+ <remote procedure identifier>:\r
+ \r
+ ----> <qualified object expression> --> . -->!\r
+ ! ^ !\r
+ !----------------------------------------! !\r
+ !\r
+ !--------------------------------------------!\r
+ !\r
+ !---> <procedure identifier> --->\r
+ \r
+ \r
+ <actual parameter list>:\r
+ \r
+ ---->(----------------> <expression> ----------------> ) ---->\r
+ ^ ! ^ !\r
+ ! !-><remote function identifier>-------->! !\r
+ ! ! ! !\r
+ ! !-><remote procedure identifier>------->! !\r
+ ! ! ! !\r
+ ! !-><type identifier>------------------->! !\r
+ ! !\r
+ !--------------- , <---------------------------!\r
+1 - 77 -\r
+ \r
+ \r
+ CONTEXT.\r
+ --------\r
+ \r
+ We shall start with an allocation of a unit object O, i.e., subprogram\r
+ call, object generation and block statement. The execution of those\r
+ statements causes the generation of the new object O. Let Pa1, ..., Pak\r
+ denote actual parameters, k>=0, and let X be an object expression. The\r
+ allocation of an object of unit M is of one of the following forms:\r
+ \r
+ - for function M: M(Pa1, ..., Pak) or X.M(Pa1, ..., Pak)\r
+ (a function call must occur in an expression; it is not allowed as an\r
+ independent statement);\r
+ \r
+ - for procedure M: call M(Pa1, ..., Pak) or call X.M(Pa1, ..., Pak);\r
+ \r
+ - for class M: new M(Pa1, ..., Pak) or X.new M(Pa1, ..., Pak);\r
+ (an object generator may occur in an expression and it is also allowed as\r
+ an independent statement).\r
+ \r
+ - for block statement: pref M(Pa1, ..., Pak) block...end or block... end\r
+ (a block can be considered as an unnamed unit and a generation of its\r
+ object is the result of an occurrence of that block statement).\r
+ \r
+ \r
+ The allocation of a unit object is a WFF if:\r
+ \r
+ - a unit identifier M is visible (in the sense of the rules\r
+ used for the variables, see 8.2.),\r
+ - the actual parameters are WFFs,\r
+ - the formal parameter list and the actual parameter list\r
+ are statically compatible in the sense given below.\r
+ \r
+ Let us recall (5.3.5.) that a formal parameter list of a unit M is\r
+ defined as a concatenation of the lists of units belonging to the prefix\r
+ sequence of M.\r
+ \r
+ Static compatibility of parameters.\r
+ \r
+ The list of formal parameters (Pf1, ..., Pfj) is statically compatible\r
+ with the list of actual parameters (Pa1, ..., Pak) if j=k and for i=1, ...,\r
+ k the following conditions hold:\r
+ \r
+ - if Pfi is an input/output formal parameter then Pai is a\r
+ WFF of a static type which is statically compatible with\r
+ the static type of parameter Pfi,\r
+ - if Pfi is an output/inout parameter then Pai is a\r
+ variable,\r
+ - if Pfi is a formal function (procedure) then Pai is a\r
+ function (procedure) identifier,\r
+ - if Pfi is a formal type then Pai is a non-primitive type\r
+ identifier.\r
+1 - 78 -\r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ The allocation of a unit object O is defined if:\r
+ - the unit and its environment are determined,\r
+ - the list of formal parameters is dynamically compatible\r
+ with that of actual parameters (in the sense provided\r
+ below),\r
+ - three steps of actions, called prologue, body, and\r
+ epilogue, are determined.\r
+ \r
+ Note the difference between the unit identifier and the unit itself. The\r
+ environment is the object which becomes the syntactic father of O. In the\r
+ case of a formal subprogram, the unit identifier may be replaced by one of\r
+ many existing units. Denote by O1 the object containing the given unit\r
+ object allocation statement. The prologue computes the values for input\r
+ formal parameters, determines the addresses of output actual parameters,\r
+ and determines actual subprograms/types. The prologue is executed in the\r
+ environment of the object O1. The body transfers the control to the\r
+ statements from the prefix sequence of the given unit. Those statements are\r
+ executed in the environment of the object O.\r
+ The epilogue transmits the values of output formal parameters (in the\r
+ environment of the object O1).\r
+ \r
+ Unit environment\r
+ \r
+ Consider the allocation of a unit which is not a block. A unit identifier\r
+ has one of the following forms:\r
+ \r
+ (a) M,\r
+ (b) X.M or X.new M .\r
+ \r
+ Ad (a). Let the static location of the given occurrence of M be\r
+ determined by the attribute M of the unit T. Consider three cases:\r
+ \r
+ (a1) M is an attribute of T and it is neither a virtual attribute nor a\r
+ formal parameter. Then the declaration of M is determined as (at\r
+ compilation time) as the declaration of the attribute M of unit T. The\r
+ environment of the unit M is the dynamic container of identifier M with\r
+ respect to the object O1.\r
+ \r
+ (a2) M is a virtual attribute of T. Then the declaration of M is\r
+ determined at run-time by the dynamic location of identifier M with respect\r
+ to the given occurrence (see 6.1.5.). The environment is determined as in\r
+ (a1).\r
+ \r
+ (a3) M is a formal subprogram of T. Then the declaration of M and its\r
+ environment are taken from the dynamic container of the identifier M. The\r
+ dynamic container is determined with respect to the object O1.\r
+ \r
+ Ad (b). Let X be a well-formed object expression of type R, let M be a\r
+ not close attribute of R, and let the expression X be defined. Denote by O2\r
+ the non-empty object of unit R0 (R pref* R0) which is pointed to by X. The\r
+ cases (a1)-(a3) have to be considered in the same way as the above ones.\r
+ The descriptions differ in that the environments are determined with\r
+ respect to the object O2. Note that the environment of the object becomes\r
+ the syntactic father of the object O.\r
+1 - 79 -\r
+ \r
+ \r
+ Dynamic compatibility of parameters.\r
+ \r
+ First let us note the difference between the determination of dynamic type\r
+ for the actual parameter Pa and the formal parameter Pf. The dynamic type\r
+ of Pa is determined in the environment of the object O1 (containing the\r
+ given allocation). It means that for the formal type S the actual type is\r
+ taken from the dynamic container with respect to O1. Recall that it\r
+ corresponds to the determination of the valuation of identifier S in the\r
+ SL-chain of O1 (according to the visibility rules) and taking the text of\r
+ declaration assigned to S (cf. 6.1.5.).\r
+ The dynamic type of Pf is determined in the corresponding environment. It\r
+ means that for the formal type S the actual type is taken from the\r
+ corresponding dynamic container. In other words, the valuation of\r
+ identifier S is searched for in the SL-chain of the environment (according\r
+ to the visibility rules).\r
+ \r
+ The list of formal parameters is dynamically compatible with the list of\r
+ actual parameters if the following conditions hold:\r
+ \r
+ - if Pfi is an input formal parameter, then Pai is defined and\r
+ the dynamic type of Pfi is dynamically consistent with the\r
+ type of the value of Pai,\r
+ - if Pfi is an output/inout formal parameter, then Pai is\r
+ defined and the dynamic type of Pai is statically consistent\r
+ (!) with the dynamic type of Pfi,\r
+ - if Pfi is a formal function (procedure), then the lists of\r
+ formal parameters of Pfi and that of Pai must be of the same\r
+ pattern (disregarding the descriptions of subprogram\r
+ parameters). They may differ in the parameter identifiers, and\r
+ they may differ in the class types of corresponding parameters\r
+ (however, the class types must belong to the same prefix\r
+ sequence),\r
+ - if Pfi is a formal function, then the dynamic type of Pfi\r
+ prefixes the dynamic type of Pai, or the two types are\r
+ identical.\r
+ \r
+ The above conditions are checked from left to right (i.e., for i=1, ...,\r
+ k).\r
+ \r
+ Recall that in the following description of prologue and epilogue the\r
+ computations of the values and addresses for formal parameters and actual\r
+ ones are performed in the syntactic environment of the object O1.\r
+1 - 80 -\r
+ \r
+ \r
+ Prologue.\r
+ \r
+ The prologue consists of the following steps:\r
+ \r
+ (i) The frame for a new object O is allocated, the object O1 is called\r
+ the dynamic father of the object O. The sequence of dynamic fathers creates\r
+ a chain called the DL chain (DL for dynamic links);\r
+ \r
+ (ii) For the input and inout formal parameter Pf, the value of the\r
+ corresponding actual parameter is computed and assigned to Pf;\r
+ \r
+ (iii) For the output and inout formal parameter Pf, the address of the\r
+ corresponding actual parameter Pa is computed (in other words, the prologue\r
+ of the assignment of Pf to Pa is performed);\r
+ \r
+ (iv) For the formal type parameter Pf, the corresponding actual type Pa\r
+ is determined. According to 6.1.5. the valuation of the object O assigns\r
+ the text of the determined type Pa to the identifier Pf. Therefore as long\r
+ as that object exists the access to Pf is well-defined and connected with\r
+ Pa;\r
+ \r
+ (v) For the formal subprogram parameter, the actual subprogram is fixed\r
+ (in the same way as the determination of the allocated unit and its\r
+ environment).\r
+ \r
+ \r
+ After the execution of the epilogue the control is transferred to the\r
+ object O. Let M1, ..., Mk=M be the prefix sequence of M. The execution of\r
+ the statements from the object O begins from the first statement of the\r
+ unit M1 (for the description of the further progress of computation, see\r
+ inner statement, 9.1.3.). Note that those statements are executed in the\r
+ syntactic environment of the object O. When the control returns to the\r
+ calling object O1, the actions of the epilogue are performed.\r
+1 - 81 -\r
+ \r
+ \r
+ Epilogue.\r
+ \r
+ The epilogue consists of the following steps:\r
+ \r
+ (i) For the output and inout formal parameter Pf the actions of the\r
+ epilogue for the assignment Pa:=Pf are performed, where Pa is the actual\r
+ parameter corresponding to Pf. It means that the value of Pf (computed\r
+ during the execution of the body) is assigned to Pa (this address was\r
+ computed during the prologue);\r
+ \r
+ (ii) If the unit is a function, then the result of the given call is\r
+ determined by the current value of the corresponding variable result,\r
+ \r
+ (iii) If the unit is a generalized class, then the result of a new M is a\r
+ reference to the object O;\r
+ \r
+ (iv) A terminated object (cf. 9.1.3.) of a block or a subprogram is\r
+ deallocated. However, the terminated object of a generalized class is\r
+ accessible as long as there is a reference pointing to it (unless it is\r
+ directly deallocated by means of the kill statement).\r
+ \r
+ \r
+ Remark.\r
+ -------\r
+ \r
+ Note that for the input formal parameter Pf of non-primitive type, the\r
+ value of the corresponding actual variable parameter Pa may be updated\r
+ (both the formal parameter and the actual one point to the same object). In\r
+ order to access the value of Pa without the possibility of its modification\r
+ one can use the copying statement Pf:=copy(Pf) at the end of the unit body.\r
+ \r
+ End of remark.\r
+ --------------\r
+1 - 82 -\r
+ \r
+ \r
+ Array generation.\r
+ -----------------\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <array generation>:\r
+ \r
+ ----> new_array -----> <variable > -----> ( -->!\r
+ !\r
+ !<----------------------------------------------!\r
+ !\r
+ !--> <arithmetic expression> --> : --> <arithmetic expression>--> ) -->\r
+ \r
+ \r
+ A declaration of a variable of an array type fixes the type of the array\r
+ elements; bound pairs are fixed at the time of generation.\r
+ \r
+ CONTEXT.\r
+ --------\r
+ \r
+ A statement new_array Y dim (l:u) is a WFF if:\r
+ \r
+ - Y is a variable of the type (array_of)<i>T, where i>0, T is a type\r
+ identifier;\r
+ \r
+ - l, u are WFFs and arithmetic expressions.\r
+ \r
+ The above statement is considered to be an assignment of a reference (to a\r
+ newly created object) on the variable Y.\r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ The following actions are performed:\r
+ \r
+ - determine the address of variable Y;\r
+ - compute the values l1, u1 of expressions l, u;\r
+ - put l0, u0 truncations of l1, u1 respectively;\r
+ - check the condition l0<=u0;\r
+ - generate an array object and assign its address to Y.\r
+ \r
+ The initial values of attributes (l0), ..., (u0) depend on their type of\r
+ the form (array_of)<i-1>T.\r
+ The value of an array type variable may be changed by means of\r
+ assignment, copying, and generation statements. The generation of an\r
+ n-dimensional array consists of n steps. The first dimension is generated:\r
+ e.g. new_array Y dim (l1:u1),\r
+ next the second dimension:\r
+ e.g. for i:=l1 to u1 do new_array Y(i) dim (li2:ui2) od\r
+ and so on. Unregular arrays can be generated in this way.\r
+1 - 83 -\r
+ \r
+ \r
+ 9.1.2.2. Deallocation statement\r
+ *******************************\r
+ SYNTAX.\r
+ -------\r
+ <object deallocation>:\r
+ \r
+ ----> kill ----> ( ----> <object expression> ----> ) --->\r
+ \r
+ CONTEXT and SEMANTICS.\r
+ ----------------------\r
+ \r
+ A statement kill(X) is a WFF if X is a well formed object expression of\r
+ compound type. The statement kill(none) is always WFF and it is equivalent\r
+ to the empty statement.\r
+ The statement is defined if X points to an object O not belonging to the\r
+ SL chain or DL chain of an active object. By an active object we mean the\r
+ object containing the statement currently being executed (notice that in\r
+ the case of parallelism there may co-exist several active objects).\r
+ The execution of the statement results in the deallocation of object O,\r
+ all variables pointing to O are set to none. The deallocation of an object\r
+ which belongs to the SL chain or DL chain of an active object results in a\r
+ run-time error.\r
+ The statement kill(X) where X points to a coroutine head is described in\r
+ 9.1.4. The statement kill(X) where X points to a process is described in\r
+ 11.1.\r
+ \r
+ Remark.\r
+ -------\r
+ \r
+ After a block or subprogram termination, the corresponding object is\r
+ automatically deallocated. On the other hand, the array, class, coroutine,\r
+ or process objects are not automatically deallocated. The computer memory\r
+ may be overloaded with such objects even if they are no longer referenced.\r
+ Those objects are recovered with the help of the system program called the\r
+ garbage collector. The user can help in the execution of that system\r
+ program and increase the efficiency of his program execution if he\r
+ deallocates unnecessary objects. One should realize, however, what are the\r
+ effects of deallocation (in particular, a side effect consisting in the\r
+ modification of the values of all variables which point to the same\r
+ deallocated object).\r
+ \r
+ End of remark.\r
+ --------------\r
+ \r
+ Example.\r
+ --------\r
+ \r
+ The deallocation of a binary tree can be performed by means of the\r
+ following recursive procedure:\r
+ \r
+ unit tree_kill: procedure (n:node);\r
+ begin\r
+ if n.l=/=none then call tree_kill(n.l) fi;\r
+ if n.r=/=none then call tree_kill(n.r) fi ;\r
+ kill(n)\r
+ end tree_kill\r
+ \r
+ where the class node has the form\r
+ \r
+ unit node: class;\r
+ var l, r: node ;\r
+1 - 84 -\r
+ \r
+ \r
+ end node;\r
+1 - 85 -\r
+ \r
+ \r
+ 9.1.3. Simple control statement\r
+ ********************************\r
+ \r
+ \r
+ There are two kinds of simple control statements: a textual control\r
+ statement and a dynamic control statement. In this section we shall\r
+ consider the occurrence of a control statement in the object O of the unit\r
+ M, in the body of the unit Mj, where M has the prefix sequence M1, ...,\r
+ Mk=M, and 1<=j<=k.\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <simple control statement>:\r
+ \r
+ -----> <textual control statement> -------->\r
+ ! ^\r
+ !--> <dynamic control statement> --->!\r
+ \r
+ <textual control statement>:\r
+ \r
+ -------> inner ----->\r
+ ! !\r
+ ! !\r
+ !-----> exit ----->!\r
+ ! ! ! !\r
+ ! !<------! !\r
+ ! ! !\r
+ !---> repeat ----->!\r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ For j=1, ..., k-1 the execution of the inner statement results in the\r
+ commencement of the execution of the unit Mj+1. The inner statement in the\r
+ body of the unit Mk=M is empty.\r
+ \r
+ ------- ------- ------- -------\r
+ ! ! ! ! ! ! ! !\r
+ inner < inner < ........ < inner < .....\r
+ ! ! ! ! ! ! ! !\r
+ ------- ------- ------- -------\r
+ \r
+ body of M1 body of M2 body of Mk-1 body of Mk\r
+ \r
+ The semantics of repeat and exit statements will be defined jointly with\r
+ the semantics of a loop statement, see 9.2.3..\r
+1 - 86 -\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <dynamic control statement>:\r
+ \r
+ ---------> return ----------->\r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ In this section we shall describe the semantics of a return statement and\r
+ a pseudo-statement end (which bound a unit declaration).\r
+ An object may be in one of the following three states: non-generated,\r
+ generated, terminated. An object is non-generated until the control reaches\r
+ the first return statement. From that moment an object becomes generated.\r
+ An object is terminated after the execution of its end statement. The main\r
+ program is considered to be always generated. A generated object is\r
+ considered to have no dynamic father (its DL is none). Note that the\r
+ execution of a terminated object cannot be resumed. However, the execution\r
+ of the generated object of a coroutine or a process can be resumed and\r
+ suspended. The return statement is empty if M is a coroutine and O is\r
+ generated. If M is a block, subprogram, or generalized class and O is\r
+ non-generated then O becomes generated. The control returns to the dynamic\r
+ father of O. For a coroutine or process the statement following the return\r
+ statement is a reactivation point.\r
+ \r
+ Now we shall consider the execution of the final end. For j=2, ..., k the\r
+ execution of the final end results in the control transfer to the statement\r
+ following the inner statement from the unit Mj-1. Suppose that j=1. If O is\r
+ a non-generated object of a coroutine, then O becomes generated and the\r
+ control returns to the dynamic father of O. Otherwise (O is a\r
+ coroutine/process object) the object O becomes terminated. The control\r
+ transfer is the same as in the case of detach statement. Moreover, if M is\r
+ a process, then the control becomes idle (and the corresponding processor\r
+ may be released, see 11).\r
+1 - 87 -\r
+ \r
+ \r
+ 9.1.4. Coroutine statement\r
+ ***************************\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <coroutine statement>:\r
+ \r
+ ------> detach ---------------------------------------------->\r
+ ! ^\r
+ !-----> attach ----> ( ---> <object expression>--> ) -->!\r
+ \r
+ CONTEXT and SEMANTICS.\r
+ ----------------------\r
+ \r
+ By a chain of coroutine N with the head Ol we shall mean the DL chain of\r
+ objects O1, ..., Ol such that:\r
+ - for i=1, ..., l-1 the object Oi+1 is the dynamic father of Oi;\r
+ - Ol is the generated object of the coroutine N;\r
+ - Ol is non-terminated.\r
+ Thus the chain contains non-generated objects with the exception of the\r
+ head, which is generated but non-terminated.\r
+ The execution of a kill(X) statement where X points to the head Ol of the\r
+ coroutine chain results in a deallocation of the entire chain.\r
+ \r
+ The chain may be in one of the following two states:\r
+ - detached - the execution of the statements contained in this\r
+ chain is suspended, the object O1 contains a distinguished\r
+ point, called the reactivation point of the chain;\r
+ - attached - a statement from the object O1 is currently\r
+ executed.\r
+ \r
+ In the case of a sequential program exactly one chain is operational,\r
+ i.e., in the attached state. Note that a coroutine head may be the main\r
+ program. Coroutine control statements change the states of coroutine\r
+ chains. A reference to the coroutine chain W1 which has recently\r
+ transferred the control to the chain W is associated with chain W. Let us\r
+ denote this reference by CL (coroutine link). This link is then used by the\r
+ detach statement. Suppose that the object O (containing the occurrence of\r
+ the coroutine control statement) belongs to the chain W of the coroutine N\r
+ with the head Ol.\r
+ The statement attach(X) is a WFF if X is a well formed object expression\r
+ or the system variable main. The statement is defined if X points to the\r
+ head O1 of a coroutine chain W1. The execution of the statement results in\r
+ changing the state of W to a detached one and that of W1 to an attached\r
+ one. The statement determined by the reactivation point of the chain W1\r
+ starts its execution. The CL link to the chain W is associated with the\r
+ chain W1. If O=O1 then the statement is empty.\r
+ The statement detach is defined except the case where the CL link of\r
+ chain W is none. The execution of the statement results in detaching the\r
+ chain W and attaching the chain W1 determined by the corresponding CL link\r
+ associated with W. The statement following the detach statement is the\r
+ reactivation point of the chain W. The execution of the chain W1 is resumed\r
+ at its reactivation point.\r
+1 - 88 -\r
+ \r
+ \r
+ 9.2. Compound statements\r
+ *************************\r
+ \r
+ Compound statements define case analysis (conditional and case statement)\r
+ and iteration (loop statements).\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <compound statement):\r
+ \r
+ ----------> <conditional statement> -------->\r
+ ! ^\r
+ !-----> <case statement> ------->!\r
+ ! !\r
+ !-----> <loop statement> ------->!\r
+ \r
+ \r
+ \r
+ \r
+ 9.2.1. Conditional statement\r
+ *****************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <conditional statement>:\r
+ \r
+ ---> if --> <boolean expression> --> then --> <statement list>\r
+ ! ! !\r
+ !---> <orif list> ------->! !\r
+ ! ! !\r
+ !---> <andif list> ------>! !\r
+ !\r
+ !\r
+ !\r
+ <-----------------------------------------------!\r
+ ! !\r
+ !------> else --> <statement list> --------> fi ---------->\r
+ \r
+ \r
+ \r
+ \r
+1 - 89 -\r
+ \r
+ \r
+ <orif list>:\r
+ \r
+ ---- <boolean expression> ----------------->\r
+ ! !\r
+ !<------- or_if <----------!\r
+ \r
+ \r
+ <andif list>:\r
+ \r
+ ---- <boolean expression> ----------------->\r
+ ! !\r
+ !<------ and_if <----------!\r
+ \r
+ \r
+ CONTEXT and SEMANTICS.\r
+ ----------------------\r
+ \r
+ \r
+ For the execution of an if statement of the form:\r
+ \r
+ if B1 or_if B2 ... or_if Bj\r
+ then\r
+ G\r
+ else\r
+ H\r
+ fi\r
+ \r
+ \r
+ the boolean expressions B1, .., Bj are evaluated in succession until the\r
+ first one evaluates to true, then the sequence G of statements is executed.\r
+ If none of the boolean expressions evaluates to true, then the sequence H\r
+ is executed. The conditional statement with the "else" part omitted is\r
+ equivalent to the conditional statement with the empty statement following\r
+ the else symbol. If the "andif" list occurs instead of the "orif" list,\r
+ then the expressions B1, ..., Bj are evaluated in succession until the\r
+ first one evaluates to false; then the sequence H is executed. Otherwise\r
+ the sequence G is executed. When a boolean expression occurs instead of an\r
+ "orif" or "andif" list, then its value controls the execution of the\r
+ conditional statement in the standard manner.\r
+1 - 90 -\r
+ \r
+ \r
+ 9.2.2. Case statement\r
+ **********************\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <case statement>:\r
+ \r
+ ----> case --!\r
+ !\r
+ !-----------!\r
+ ! !-------------------->!\r
+ ! ! !\r
+ ! <---- <statement list> <--- : -----! !\r
+ ! ! ! !\r
+ !-> <arithmetic expression> ---> when ---> ---<integer>-------->! !\r
+ ! ^ ! ^ ! !\r
+ ! ! -> <constant> ->! ! !\r
+ ! ! ! !\r
+ ! <----- , -------------! !\r
+ ! !\r
+ !-> <character expression> ---> when ---><character constant>->:-! !\r
+ ^ ^ ! ^ ! ! !\r
+ ! ! !-> <constant> ->! ! ! !\r
+ ! ! ! ! !\r
+ ! !<--------- , --------! ! !\r
+ ! ! !\r
+ !<------ <statement list> <----------! !\r
+ ! !\r
+ ! !\r
+ <------------------------------------------------------------!\r
+ ! !\r
+ ! !\r
+ !-> others ----> <statement list> ---------> esac ---->\r
+ \r
+ \r
+ \r
+ CONTEXT and SEMANTICS.\r
+ ----------------------\r
+ \r
+ A statement:\r
+ \r
+ case E\r
+ when l1:G1\r
+ ...\r
+ when lk:Gk\r
+ others H\r
+ esac\r
+ \r
+ is a WFF if E is an arithmetic or character expression and l1, ..., lk are\r
+ sequences of different constants. If the list H is empty, then the "others"\r
+ part can be omitted.\r
+ The case statement selects for execution a sequence Gi where the value of\r
+ E belongs to the sequence li. The choice others covers all values (possibly\r
+ none) not given in the previous choices. The choices in a case statement\r
+ must be mutually disjoint and if the "others" part is not present they must\r
+ exhaust all the possibile values of the expression E.\r
+ \r
+ \r
+ \r
+1 - 91 -\r
+ \r
+ \r
+ 9.2.3. Iteration statement\r
+ ***************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <iteration statement>:\r
+ \r
+ \r
+ -------> <loop statement> ---------------------------------------->\r
+ ! ^\r
+ !---> <loop statement with condition> --------------------->!\r
+ ! !\r
+ !---> <loop statement with control variable> -------------->!\r
+ \r
+ \r
+ <loop statement>:\r
+ \r
+ \r
+ ---> do -----> <statement list> ----> od --->\r
+ \r
+ \r
+ <loop statement with condition>:\r
+ \r
+ \r
+ --> while --> <boolean expression> --> do --> <statement list>--> od -->\r
+ \r
+ \r
+ <loop statement with control variable>:\r
+ \r
+ ---> for ---> <simple variable> -->:= --> <arithmetic expression> -->!\r
+ !\r
+ <------------------------------------------------------------------!\r
+ ! !\r
+ !--> step --> <arithmetic expression>----> to ----->!\r
+ ! !\r
+ !-->downto-->!\r
+ !\r
+ <---------------------------------------------------!\r
+ !\r
+ !-> <arithmetic expression> -->do--> <statement list>--->od -->\r
+1 - 92 -\r
+ \r
+ \r
+ CONTEXT and SEMANTICS.\r
+ ----------------------\r
+ \r
+ Let us start from the semantics of loop and exit statements. The loop\r
+ statement:\r
+ \r
+ do\r
+ G\r
+ od\r
+ \r
+ causes the iteration of the sequence G until an exit statement is\r
+ encoutered.\r
+ Consider the occurrence of the exit statement exit ... exit(k-times)\r
+ where k >=1 . Let us denote this statement by H. Suppose that statement H\r
+ occurs in l (l>=0) nested iteration statements G1, ..., Gl, i.e., the\r
+ statement G2 is nested in G1, G3 in G2, etc. Let M be the smallest unit\r
+ enclosing that occurrence of H.\r
+ If k>l then the execution of H causes the termination of the unit body M\r
+ (jump to the final end). Otherwise the iteration statement Gk terminates,\r
+ and either the execution of the iteration statement Gk-1 is continued if\r
+ k<l or the execution of the outermost iteration statement G1 terminates if\r
+ k=l.\r
+ The keyword repeat may occur just after the sequence of exit's. Then the\r
+ iteration statement Gk is continued (if k<=l), i.e., the control is\r
+ switched not outside but to the beginning of the loop without the execution\r
+ of the statements occurring after repeat. If the statement Gk is a loop\r
+ statement with the while condition, then the consequtive iteration starts\r
+ from the condition evaluation. If it is a for statement, then the\r
+ consequtive iteration starts with the change of the controlled variable\r
+ value.\r
+ \r
+ \r
+ Remark.\r
+ -------\r
+ \r
+ The goto statement is totally deleted from LOGLAN-82 (contrary to other\r
+ languages, like ADA where goto within a single unit is allowed). The\r
+ structured statements defined above were applied to many examples of known\r
+ algorithms. These exercises showed that the proposed structured statements\r
+ constitute a good balance point between a non structured goto-label\r
+ statement and a classical while statement (which often requires auxiliary\r
+ control boolean variables).\r
+ Notice that the above unit M body is considered to be "non-concatenated",\r
+ i.e., in the case of the jump to end symbol, this end is taken from the\r
+ body of M, not from the body of M concatenated with its prefix sequence. We\r
+ stress that the textual control statements do not lead outside one unit.\r
+ \r
+ End of remark.\r
+ --------------\r
+1 - 93 -\r
+ \r
+ \r
+ A loop statement with condition:\r
+ \r
+ while B\r
+ do\r
+ G\r
+ od\r
+ \r
+ is equivalent to a loop statement of the form:\r
+ \r
+ do\r
+ if not B then exit fi;\r
+ G\r
+ od\r
+ \r
+ A loop statements with controlled variables are of the forms:\r
+ \r
+ (*) for i:=A1 step A2 to A3 do G od\r
+ (**) for i:=A1 step A2 downto A3 do G od\r
+ \r
+ The controlled variable i must be of discrete type. The statement (*) is\r
+ equivalent to the following sequence of statements:\r
+ \r
+ Av1:=A1; Av2:=A2; Av3:=A3; i:=Av1;\r
+ while Av3>=i\r
+ do\r
+ G;\r
+ i:=i+Av2\r
+ od\r
+ \r
+ The statement (**) is equivalent to the above sequence of statements with\r
+ the condition Av3>=i replaced by Av3<=i and the assignment i:=i+Av2\r
+ replaced by i:=i-Av2. The variables Av1, Av2, Av3 are fictitious variables\r
+ introduced only in order to define the semantics. The expression step A2\r
+ may be omitted if the value of A2 equals 1. The value of the controlled\r
+ variable i should not be modified inside the loop (however, the result of\r
+ such a modification would be well-defined). Moreover, its value is\r
+ determined when loop is terminated according to the introduced semantics.\r
+1 - 94 -\r
+ \r
+ \r
+ Examples.\r
+ ---------\r
+ \r
+ \r
+ (1) A palindrome is a word which is identical when written from left to\r
+ right and conversely. The given algorithm looks for the first occurrence of\r
+ a palindrome in a text and writes its length, (if found).\r
+ \r
+ unit palindrome: procedure;\r
+ var i, j, k: integer,\r
+ text: array_of character;\r
+ begin\r
+ read(j);\r
+ new_array text dim (1:j);\r
+ for k:=1 to j\r
+ do\r
+ read (text(k))\r
+ od;\r
+ for i:=2 to j\r
+ do\r
+ k:=1;\r
+ while text(k)=text(i-k+1)\r
+ do\r
+ k:=k+1;\r
+ if k>i-k+1\r
+ then\r
+ write ("found at i-th item");\r
+ return\r
+ fi\r
+ od\r
+ od;\r
+ write ("not found")\r
+ end palindrome;\r
+1 - 95 -\r
+ \r
+ \r
+ (2) A dictionary is a data structure S with the following operations:\r
+ \r
+ member(x, S) - determines whether x is a member of S\r
+ insert(x, S) - replaces S by the union of S and (x)\r
+ delete(x, S) - replaces S by the difference of S and (x)\r
+ \r
+ The elements of the set S are assumed to be of the same type T and to be\r
+ ordered by the relation less. A dictionary will be implemented by means of\r
+ binary search trees. The user has the access to the operations member,\r
+ insert, and delete and does not have to bother about the way of their\r
+ implementation. Below we propose how to accomplish these operations as\r
+ coroutines.\r
+ \r
+ unit bst: class (type t; function less(x, y:t):boolean);\r
+ hidden root, e, i, d;\r
+ var root: node, member: e, insert: i, delete: d;\r
+ unit node: class (value: t);\r
+ var l, r: node;\r
+ end node;\r
+ \r
+ unit e: coroutine; (*elem- output attribute*)\r
+ close trick, q, v;\r
+ var trick, elem: boolean, q, v: node, x:t;\r
+ begin\r
+ return;\r
+ do trick, elem:=false; (* loop for member *)\r
+ q:=root;\r
+ v:=none;\r
+ while q=/=none\r
+ do\r
+ if less(x, q.value)\r
+ then v:=q; q:=q.l\r
+ else\r
+ if less(q.value, x)\r
+ then v:=q; q:=q.r\r
+ else elem:=true; exit\r
+ fi\r
+ fi\r
+ od;\r
+ inner; (* elem=true iff x belongs to S *)\r
+ detach;\r
+ od\r
+ end e;\r
+ \r
+ unit help: E coroutine;\r
+ taken trick, elem, q, v, x;\r
+ begin\r
+ inner; (* trick=true iff x does not belong to S *)\r
+ if not trick then exit fi;\r
+ if v=none\r
+ then root:=q\r
+ else\r
+ if less(x, v.value)\r
+ then v.l:=q\r
+ else v.r:=q\r
+ fi (* after insert or delete *)\r
+ fi (* attach new node q to its father v *)\r
+ end help;\r
+1 - 96 -\r
+ \r
+ \r
+ unit i: help coroutine;\r
+ taken trick, elem, q, x;\r
+ begin\r
+ trick:=true;\r
+ if elem then exit fi;\r
+ q:=new node(x) (* insert is a dummy if x belongs to S *)\r
+ end i;\r
+ \r
+ unit d: help coroutine;\r
+ taken elem, q;\r
+ hidden close w, u, s;\r
+ var w, u, s: node;\r
+ begin (* delete is a dummy if x does belong to S *)\r
+ if not elem then exit fi;\r
+ w:=q;\r
+ if q.r=none\r
+ then q:=q.l\r
+ else\r
+ if q.l=none\r
+ then q:=q.r\r
+ else u:=q.r;\r
+ if u.l=none\r
+ then u.l:=q.l; q:=u\r
+ else\r
+ do s:=u.l;\r
+ if s.l=none then exit fi;\r
+ u:=s\r
+ od;\r
+ s.l.:=w.l; u.l:=s.r;\r
+ s.r:=w.r; q:=s\r
+ fi\r
+ fi\r
+ fi;\r
+ kill(w)\r
+ end d;\r
+ \r
+ begin\r
+ member:=new e; insert:=new i; delete:=new d;\r
+ inner;\r
+ kill(member); kill(insert); kill(delete)\r
+ end bst;\r
+ \r
+ pref bst(t, less) block\r
+ taken member, insert, delete;\r
+ var y:t;\r
+ ...\r
+ begin\r
+ ...\r
+ member.x:=y;\r
+ attach(member);\r
+ if member.elem then ... fi;\r
+ ...\r
+ insert.x:=y;\r
+ attach(insert);\r
+ ...\r
+ delete.x:=y;\r
+ attach(delete);\r
+ ...\r
+ end;\r
+1 - 97 -\r
+ \r
+ \r
+ 10. Exception handling\r
+ #######################\r
+ \r
+ \r
+ This section defines the facilities for dealing with errors or other\r
+ exceptional situations that may arise during program execution. An\r
+ exception is an event that causes a suspention of normal program execution.\r
+ The occurrence of an exception is expressed by raising a signal. Executing\r
+ some actions in response to the arising of an exceptional situation, is\r
+ called signal handling.\r
+ \r
+ Signal names are introduced by signal specifications. Signals can be\r
+ raised by raise statements, or alternatively, their raising is caused by an\r
+ occurrence of a run-time error. When an exception arises, the control can\r
+ be passed to a user-pointed handler associated with the raised signal. The\r
+ principles of determining a handler that responds to the raised signals are\r
+ presented in 10.3.\r
+ \r
+ \r
+ 10.1 Signal specification\r
+ *************************\r
+ \r
+ \r
+ SYNTAX\r
+ ------\r
+ \r
+ <signal specification>:\r
+ \r
+ ----> signal ---> <signal name> ---> ( --> <formal par. list> --> ) -->; -->\r
+ ! ! !!\r
+ ! !-------------------------------->!!\r
+ !<---------------------- , ---------------------------!\r
+ \r
+ CONTEXT\r
+ -------\r
+ \r
+ The signal specification defines signals which can appear in raise\r
+ statements and in signal handlers within the scope of the specification.\r
+ The identifiers of system signals, i.e., signals associated with run-time\r
+ errors, are not specified in the signal specification.\r
+ Signal identifiers are not accessible by remote access. They can occur,\r
+ however, in a hidden, close or taken list of a unit.\r
+1 - 98 -\r
+ \r
+ \r
+ 10.2 Signal handlers\r
+ ********************\r
+ \r
+ The response to one or more signals is specified by a signal handler.\r
+ \r
+ \r
+ SYNTAX\r
+ ------\r
+ \r
+ <handlers' declaration>:\r
+ \r
+ ---> handlers\r
+ !\r
+ !-----------> when ---> <signal name> --> : --> <statement list> --!\r
+ ! ! ! !\r
+ ! !<------ , -------! !\r
+ ! !\r
+ !--------<------------------------------------------------------!\r
+ !\r
+ !-----------> others ----> <statement list> --!\r
+ ! !\r
+ !----------------------------------------> end handlers\r
+ ! !\r
+ !-------------->\r
+ CONTEXT\r
+ -------\r
+ \r
+ Handlers' declaration may appear at the end of the declaration part of a\r
+ unit. All identifiers visible in the unit and the signal formal parameters\r
+ may be used in the handler statements. A handler can handle the named\r
+ signals. A handler corresponding to the choice others handles all signals\r
+ not listed in the previously specified handlers, including those whose\r
+ identifiers are not visible within the unit.\r
+ \r
+ Any statement (except inner) whose occurrence in a unit is legal may\r
+ occur in the handler.\r
+ \r
+ Restrictions\r
+ ------------\r
+ \r
+ The formal parameter lists of signals associated with the same handler\r
+ must be identical.\r
+ \r
+ Example\r
+ -------\r
+ \r
+ \r
+ handlers\r
+ when emptytree: T:=new treelem; return;\r
+ others write(" signal not handled"); raise Error;\r
+ end handlers\r
+1 - 99 -\r
+ \r
+ \r
+ 10.3. Signal raising\r
+ ********************\r
+ \r
+ SYNTAX\r
+ ------\r
+ \r
+ \r
+ ----> raise ---> <signal name> --> ( --> <actual par. list> --> ) ----->\r
+ ! !\r
+ !----------------------------------->!\r
+ \r
+ \r
+ CONTEXT\r
+ -------\r
+ \r
+ The signal name in the raise statement ought to be visible in the unit in\r
+ which the raise statement appears. The formal and actual parameter lists of\r
+ the signal must be compatible.\r
+ \r
+ Example\r
+ -------\r
+ \r
+ raise empty(exprstack);\r
+ raise end_of_file (input);\r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ When a signal is raised, the normal process execution is suspended and\r
+ the control is passed to a signal handler. The actual parameters are\r
+ transmitted to the handler, as in the case of a procedure. However, the\r
+ crucial point of exception handling is the way in which such a handler is\r
+ searched for and activated. Below we present the principles of handler\r
+ determination.\r
+ \r
+ Let us assume that signal f is raised in object Ok. This object and its\r
+ corresponding DL-chain may be illustrated as follows:\r
+ \r
+ \r
+ ------------ ------------ ------------\r
+ ! ! ! ! ! !\r
+ ! ! !handlers ! ! !\r
+ ! !<---...........<---!when f !<---........<---!raise f !\r
+ ! ! ! ! ! !\r
+ ! ! ! ! ! !\r
+ ------------ ------------ ------------\r
+ O1 Oi Ok\r
+ \r
+ where O1 is the object of a coroutine or a process.\r
+1 - 100 -\r
+ \r
+ \r
+ The objects in the DL-chain of Ok are successively checked whether they\r
+ contain a handler for signal f or a handler corresponding to the choice\r
+ others. The object Ok is checked first, next the object Ok-1 is checked and\r
+ so on. This search stops when the first object Oi containing the handler\r
+ for f or the handler for others is found. If such a handler is not found in\r
+ this DL-chain, then the system trap handler is executed and the process\r
+ terminates.\r
+ For the situation presented in the figure, the handler from object Oi is\r
+ executed, provided that none of the objetcs Oi+1, ..., Ok contains a\r
+ handler for signal f or the handler for others.\r
+ \r
+ In a concatenated object, i.e., in an object corresponding to a unit with\r
+ a non-empty prefix, the handlers declared in the prefixing unit are covered\r
+ by the handlers declared in the prefixed unit if they have the same\r
+ identifiers. Thus the signal raised during the execution of the prefix\r
+ statements may be handled by a handler declared in the prefixed unit. The\r
+ handler corresponding to the choice others responds to all the signals not\r
+ listed in the handlers declared in the units from the prefix sequence. The\r
+ handler for the choice others is taken from the innermost unit (with\r
+ respect to prefixing).\r
+ \r
+ Example\r
+ -------\r
+ \r
+ block\r
+ unit A: procedure;\r
+ begin\r
+ ...\r
+ raise f\r
+ ...\r
+ end A;\r
+ unit B: procedure;\r
+ handlers\r
+ when f: .....; (* <----------- handler H1 *)\r
+ end handlers\r
+ begin\r
+ ...\r
+ call A;\r
+ ...\r
+ raise f;\r
+ ...\r
+ end B;\r
+ signal f;\r
+ handlers\r
+ when f: .....; (* <----------- handler H2 *)\r
+ end handlers;\r
+ begin\r
+ ...\r
+ raise f;\r
+ ...\r
+ call B;\r
+ ...\r
+ end\r
+ \r
+ If signal f is raised in the block satement, hanlder H2 will be executed.\r
+ If signal f is raised in procedure B or in procedure A, handler H1 will be\r
+ executed.\r
+1 - 101 -\r
+ \r
+ \r
+ block\r
+ signal f;\r
+ unit A:class;\r
+ signal g;\r
+ handers\r
+ when g: .....; (* <---------- handler G1 *)\r
+ end handlers;\r
+ begin\r
+ ...\r
+ raise f;\r
+ ...\r
+ raise g;\r
+ ...\r
+ end A;\r
+ unit B:A class;\r
+ handlers\r
+ when f: .....; (* <---------- handler F1 *)\r
+ when g: .....; (* <---------- hadller G2 *)\r
+ end handlers;\r
+ begin\r
+ ...\r
+ raise f;\r
+ ...\r
+ raise g;\r
+ ...\r
+ end B;\r
+ begin\r
+ ...\r
+ end;\r
+ \r
+ If signal f is raised in an object of class B, handler F1 will be\r
+ executed. If signal g is raised in an object of class B, handler G2 will be\r
+ executed even if the signal is raised in the statements of class A.\r
+1 - 102 -\r
+ \r
+ \r
+ 10.4. Handler execution\r
+ ***********************\r
+ \r
+ A handler execution terminates if one of the special control statements\r
+ is executed.\r
+ \r
+ SYNTAX\r
+ ------\r
+ \r
+ <handler termination>:\r
+ \r
+ ------> return ----->!\r
+ ! !\r
+ --->!---> wind --------------->\r
+ ! !\r
+ !---> terminate ---->!\r
+ \r
+ CONTEXT\r
+ -------\r
+ \r
+ The statements wind and terminate may appear only within a handler\r
+ declaration. If none of them occurs in a handler statement list, the\r
+ statement terminate is assumed to be the last statement in such a list.\r
+ The execution of the statements wind and terminate causes an abnormal\r
+ termination of the corresponding objects from the DL-chain (see below). In\r
+ that case, the "last-will" statements are executed before the termination\r
+ of the objects.\r
+ \r
+ \r
+ SYNTAX\r
+ ------\r
+ \r
+ <last-will statements>:\r
+ \r
+ -----> last_will ----> : ---> <statement list> ----------->\r
+ \r
+ CONTEXT\r
+ -------\r
+ \r
+ Any unit body may be terminated with a sequence of statements labelled by\r
+ last_will. They are not executed during normal program execution. The\r
+ statement inner must not occur within the "last-will" statements.\r
+1 - 103 -\r
+ \r
+ \r
+ \r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ Let us assume that a signal f raised in an object Ok is handled by a\r
+ handler H from an object Oi:\r
+ \r
+ \r
+ O1 Oi-1 Oi Oi+1 Ok\r
+ ----- ----- ----- ----- -----\r
+ ! ! <---...<---! !<---! !<----! !<---........<---! !\r
+ ----- DL ----- DL ----- DL ----- DL -----\r
+ ! !\r
+ ! SL !\r
+ ----- !\r
+ ! ! H-------------------------------->!\r
+ -----\r
+ \r
+ The statement return in a handler has a similar effect to that of the\r
+ statement return in a procedure. The handler object is deallocated and the\r
+ control is passed to the statement just following the corresponding raise\r
+ f.\r
+ The execution of the statement wind causes the termination and the\r
+ deallocation of the objects H, Ok, ..., Oi+1. Before the termination of\r
+ each of them, the "last-will" statements, if any, are executed. They\r
+ complete the object execution. In the prefixed object the "last-will"\r
+ statements of each prefix are successively executed, starting from the\r
+ innermost and ending on the outermost prefix. When the termination and\r
+ deallocation of these objects is completed, the control is passed to object\r
+ Oi, where the computation is continued in a normal way. Note that the wind\r
+ statement in the case of k=i is equivalent to return.\r
+ \r
+ The statement terminate causes the termination and the deallocation of\r
+ the objects H, Ok, ..., Oi+1, Oi. They are completed as in the case of\r
+ wind, i.e., the "last-will" statements are executed as well. The control is\r
+ passed to Oi-1, if such an object exists. If Oi-1 does not exists, i.e., Oi\r
+ is the head of the DL-chain, then this head is terminated (cf. the\r
+ semantics of the end statement of coroutine and process).\r
+ \r
+ \r
+ Remark\r
+ ------\r
+ \r
+ If any control statement (raise, detach, attach, etc.) is executed within\r
+ the "last-will" statements and the control returns to the interrupted\r
+ object, the execution of the "last-will" statements as well as the\r
+ termination of the remaining objects in the DL-chain will be continued.\r
+ \r
+ End of remark\r
+ -------------\r
+1 - 104 -\r
+ \r
+ \r
+ 10.5. System signals\r
+ ********************\r
+ \r
+ Some of the signals, called system signals, are predefined in the\r
+ language. They are raised automatically when a run-time error or another\r
+ exceptional system situation appears.\r
+ System signals have no parameters. They are not declared in the signal\r
+ specification, but the user may declare handlers for them. The execution of\r
+ the statement return is not allowed in the handler responding to such a\r
+ signal (note that sometimes the statement wind is equivallent to return).\r
+ \r
+ The following signals are predefined in the language:\r
+ \r
+ acc_error\r
+ A remote access to a non-existing object or an error in the\r
+ expression ...x qua A (x does not exist or the type of the object\r
+ pointed to by x is not prefixed by the type A).\r
+ mem_error\r
+ There is no free space for the allocation of a new object.\r
+ num_error\r
+ A numerical error, such as for instance integer overflow,\r
+ floating-point overflow, division by zero etc.\r
+ log_error\r
+ Any kind of the LOGLAN Running System error (except access error)\r
+ like e.g., an attempt to pass the control in a way inconsistent\r
+ with the LOGLAN-82 rules, an attempt to kill an active object, etc.\r
+ con_error\r
+ The value of an index expression exceeds the range of array indices\r
+ or the array bounds are incorrect.\r
+ sys_error\r
+ Any kind of system error like e.g., input-output error, parity\r
+ error, etc.\r
+ \r
+ Some other errors may also be introduced as system errors but are not\r
+ predefined in the language.\r
+1 - 105 -\r
+ \r
+ \r
+ 11. Processes\r
+ ##############\r
+ \r
+ \r
+ Let us consider a snap-shot of a program's computation. This snap-shot is\r
+ called a configuration. Up till now a configuration has consisted of a\r
+ finite number of objects creating a number of coroutine chains. The main\r
+ program is the only chain with the head of process type.\r
+ Moreover, exactly one object has been considered "active" - i.e., its\r
+ statements have been executed by a physical processor. By a physical\r
+ processor we mean here an actual processor as well as the portion of time\r
+ of a central unit.\r
+ A configuration with many active objects illustrates the computation of a\r
+ program with parallel statements. Concurrent computation to some extent\r
+ generalizes coroutines, i.e., a configuration may contain many coroutine\r
+ chains with heads of coroutine type and many process chains with heads of\r
+ process type.\r
+ The fundamental notion is that of a process. A process may be treated as\r
+ a sequential program - only one statement of a process is being executed at\r
+ a time. A parallel program consists of a number of processes. In LOGLAN-82\r
+ a process is a system type. A process object may be generated by means of\r
+ the new statement. The generated process object is suspended with the\r
+ execution of the return statement. This process may be resumed by means of\r
+ the resume statement. After resumption, process statements are executed by\r
+ a new processor, concurrently with the other active processes. During its\r
+ computations, the process may suspend its actions (but not the actions of\r
+ other processes) by means of the stop statement, then it may be resumed\r
+ again, and so on.\r
+ Observe that the attach and detach statements switch the processors from\r
+ one object to another, while the resume and stop statements acquire and\r
+ release a processor respectively. Resumption of a coroutine chain is\r
+ connected with the control transfer from the active coroutine chain.\r
+ Resumption of a process chain acquires new processor for that chain.\r
+ Similarly, suspension of a coroutine chain gives the control back to\r
+ another chain, while suspension of a process chain releases the processor.\r
+ Note that a process object is more complex than a coroutine object. So\r
+ coroutine operations are more efficient with respect to time and space.\r
+ Therefore the user should use processes only when they are indispensable.\r
+1 - 106 -\r
+ \r
+ \r
+ In order to deal with communication among processes (e.g., by messages)\r
+ as well as their competition in acquiring a resource (such as a shared\r
+ variable) one should have the ability to define some synchronizing\r
+ operations. Those operations arise from the following constrains:\r
+ \r
+ - timing, i.e., mutual exclusion of actions;\r
+ - scheduling i.e., stating which of the waiting processes is to be resumed\r
+ as the first one.\r
+ \r
+ \r
+ For this purpose some synchronizing facilities are provided. One may think\r
+ of many such facilities, from low level ones, such as Dijkstra's semaphores\r
+ to high level ones, such as Hoare's monitors. The decision which one of the\r
+ synchronization methods should be chosen and incorporated into the language\r
+ is weighty. The primitive tools are difficult to use, but they are\r
+ efficient. The high-level constructs are safer, but they often limit\r
+ parallelism (because of the strong synchronizing constraints).\r
+ The synchronizing facilities introduced in LOGLAN-82 are elementary (low\r
+ level). Therefore they are implemented efficiently in the kernel of the\r
+ operating system. However, the high-level facilities e.g., monitors (see\r
+ [5], [6]), can be defined with their help. The user can, for a concrete\r
+ synchronization problem, make a choice between the pre-defined facilities\r
+ or program other ones. The low-level facilities are hidden when the high\r
+ level facilities are used. Thus, the properties of the latter cannot be\r
+ disturbed.\r
+ In any case, speaking about a parallel execution of processes, we mean\r
+ that they are executed really in parallel, independently of the relations\r
+ between a number of "ready" processes and a number of available processors\r
+ (the details of processor management are hidden in an operating system).\r
+ \r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <parallel statement>:\r
+ \r
+ ------> <process state transition> ----------------->\r
+ ! ^\r
+ !--> <primitive synchronizing statement> ----->!\r
+ \r
+ \r
+1 - 107 -\r
+ \r
+ \r
+ 11.1. Transition state statement\r
+ *********************************\r
+ \r
+ \r
+ Each process can be in one of five states: active, suspended, locked,\r
+ awaiting, terminated. The transitions among these states are described by\r
+ the following graph (where X denotes the reference to the given process and\r
+ Z a semaphore):\r
+ \r
+ \r
+ \r
+ ****************\r
+ * awaiting *\r
+ **************** X:=new\r
+ ! ! !\r
+ ! ! !\r
+ end of son! ! wait !\r
+ ! ! !\r
+ lock(Z) v ! v\r
+ ************* <------ ************* ------------> ***************\r
+ * locked * * active * stop * suspended *\r
+ ************* -------> ************* <----------- ***************\r
+ unlock(Z) ! resume(X)\r
+ !\r
+ ! end of X\r
+ !\r
+ v\r
+ ******************\r
+ * terminated *\r
+ ******************\r
+ \r
+ \r
+ \r
+ We shall now present the syntax and semantics of object expressions and\r
+ statements connected with the transitions of the process states:\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <process state transition>:\r
+ \r
+ !---> <process suspension> ------------>\r
+ ! !\r
+ !---> <process resumption> ------->!\r
+ ! !\r
+ !------> <process waiting> ------->!\r
+1 - 108 -\r
+ \r
+ \r
+ \r
+ \r
+ <process suspension>:\r
+ \r
+ -----> stop --------> ( ---> <variable> ----> ) ------->\r
+ ! ^\r
+ !--------------------------------->!\r
+ \r
+ \r
+ <process resumption>:\r
+ \r
+ ----> resume -----> ( ---> <object expression> ---> ) ------>\r
+ \r
+ \r
+ <process waiting>:\r
+ \r
+ -----> wait -------------------------------------------->\r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ \r
+ From now on we shall consider the occurrence of the transition state\r
+ statement in the object O which belongs to the process R (i.e., there\r
+ exists a DL chain connecting the object O with the object O(R) of the\r
+ process R). If the process O(P) is generated in the process O(R), then the\r
+ process object O(R) is called the father of the process object O(P), and\r
+ O(P) is called a son of O(R).\r
+ The execution of the statement resume(X), where X points to the process\r
+ object, causes resumption of that process, providing that it was previously\r
+ suspended. Otherwise a run-time error occurs.\r
+1 - 109 -\r
+ \r
+ \r
+ The statement stop suspends the process R. The statement stop(Z) is a\r
+ WFF if Z is a variable of type semaphore. The execution of this statement\r
+ suspends the given process and simultaneously opens semaphore Z. The\r
+ indivisibility of those actions means that no other process can refer to\r
+ the variable Z in the meantime (the statement stop(Z) is useful in the\r
+ synchronization of processes, see 11.2.).\r
+ \r
+ A process may wait for the termination of its son with the help of the\r
+ wait expression. The execution of the expression wait in an object\r
+ belonging to the process R causes waiting for the termination of any son of\r
+ the process R. When the first such son terminates its actions, the\r
+ reference to that son is returned as the value of wait and process R\r
+ continues its computation. If the process S does not embrace a\r
+ non-terminated son, the value of the expression wait is none. Thus the\r
+ execution of the statement\r
+ \r
+ while wait =/= none do od\r
+ \r
+ causes waiting for the termination of all the sons of the given process.\r
+ \r
+ The execution of the deallocation statement kill(X) where X points to a\r
+ process depends on its state. When that process is suspended or terminated,\r
+ then the execution of this statement is the same as in the case of a\r
+ coroutine. Otherwise it results in a run-time error.\r
+ \r
+ \r
+ Relations between parallel and coroutine computations.\r
+ \r
+ LOGLAN-82's coroutine computations can easily be simulated by means of\r
+ parallel computations. Coroutine computations are provided in LOGLAN-82,\r
+ nevertheless, in order to deal with the case of interleaving processes.\r
+ With coroutines instead of processes, one can avoid unnecessary memory\r
+ overloading by data structures inherited for processes and, moreover,\r
+ unnecessary scheduler activations.\r
+ Each process is also a coroutine, and so a process may also be subject to\r
+ the coroutine operations detach and attach. Therefore, the description of\r
+ possible state transitions provided above should be extended to transitions\r
+ caused by coroutine operations.\r
+ The execution of attach(Y) in the active process X results in the control\r
+ transfer from process X to process Y, i.e., if Y is not suspended then the\r
+ statement is illegal, otherwise process X becomes suspended and process Y\r
+ becomes active.\r
+ The execution of the detach statement in the active process X has the\r
+ effect as the execution of attach(Y), where Y is the coroutine (process)\r
+ recently resumed (by means of attach statement) by process X.\r
+1 - 110 -\r
+ \r
+ \r
+ 11.2. Primitive synchronizing statement\r
+ ****************************************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <primitive synchronizing statement>:\r
+ \r
+ ----> lock ----> ( ---> <variable> ---> ) ---->\r
+ ! ^\r
+ !-> unlock -!\r
+ \r
+ \r
+ The expression test-and-set (ts) is a boolean expression (see 8.4.).\r
+ \r
+ \r
+ <test-and-set>:\r
+ \r
+ -----> ts ---> (--><variable> ---> ) --->\r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ The variable Z occurring in the expression ts(Z) has to be of type\r
+ semaphore. Evaluation of the expression consists in indivisible actions: Z\r
+ is closed and the returned value is true iff Z was open.\r
+ The statement lock(Z) is a WFF provided Z is a variable of type\r
+ semaphore. If Z is closed then the process which executes this statement is\r
+ suspended until Z becomes open. If Z is open then exactly one process of\r
+ those waiting for this event (having executed the lock instruction) will be\r
+ able to perform its actions. The others remain suspended as long as Z\r
+ becomes open again. Then exactly one process is allowed to proceed and Z\r
+ becomes closed.\r
+ The statement lock(Z) guards the entry into a critical region, i.e., a\r
+ sequence of statements, which are to be executed by only one process . The\r
+ entrance into a critical region may be of the form\r
+ \r
+ while ts(Z) do od\r
+ \r
+ as well, but it would cause busy waiting of processes awaiting for the\r
+ entrance. The statement lock is implemented in the operating system kernel\r
+ and its execution does not engage the processors by delayed processes.\r
+ \r
+ The exit from a critical region is offered by one of the following two\r
+ statements: stop(Z) or unlock(Z). The former statement is described in\r
+ 11.1. The unlock statement is a WFF provided Z is a variable of type\r
+ semaphore. The execution of this statement brings about the following\r
+ indivisible actions: Z becomes open, and if there are processes waiting for\r
+ entrance, then exactly one of the waiting processes enters the region. The\r
+ scheduling of the waiting processes is assumed to be fair.\r
+ \r
+ Thus a critical region may be written as follows:\r
+ \r
+ \r
+ lock (Z) lock (Z)\r
+ ............ or ............\r
+ unlock(Z) stop (Z)\r
+ \r
+1 - 111 -\r
+ \r
+ \r
+ Example 1.\r
+ ----------\r
+ \r
+ Suppose that the following statements occur in two processes executed in\r
+ parallel:\r
+ \r
+ process P: process Q:\r
+ lock (sem); lock (sem);\r
+ x:=(x+4)*x; x:=-3;\r
+ unlock(sem) unlock(sem)\r
+ \r
+ and the initial value of the variable x is equal to 0. The execution of the\r
+ statement x:=(x+4)*x will not be interleaved by the execution of the\r
+ statement x:=-3, irrespectively of the succession of the arrival of\r
+ processes P and Q at their regions. Thus, these statements will be executed\r
+ in sequence and, independently of the succession, the final value of the\r
+ variable x after executing both those statements is equal to -3.\r
+ If the given statements did not occur in the critical regions, their\r
+ concurrent execution might be the following: compute x+4 - (yielding 4),\r
+ assign x:=-3, compute x*(x+4) - (yielding -12) and assign this value to x.\r
+ The presented critical regions make timing possible. For the description\r
+ of scheduling one should use more complex tools, presented in the next\r
+ section.\r
+ \r
+ Example 2.\r
+ ----------\r
+ \r
+ Consider an algorithm which performs the copying of records from the\r
+ input queue to the output queue (comp. [5]). The algorithm gets the first\r
+ record from the input queue and stores it in the input buffer, next copies\r
+ the input buffer into the output buffer, and finally puts the output buffer\r
+ to the output queue and at the same time gets the next record from the\r
+ input queue, as in the following diagram:\r
+ \r
+ get 1\r
+ ,\r
+ ,\r
+ copy 1\r
+ ,\r
+ , ,\r
+ , ,\r
+ get 2 put 1\r
+ , ,\r
+ , ,\r
+ ,\r
+ .\r
+ .\r
+ copy k\r
+ ,\r
+ ,\r
+ put k\r
+ \r
+ In order to program a parallel execution of get and put operations one\r
+ can use the cobegin-coend program connectives. A particular case of these\r
+ connectives is implemented in the copying procedure given below. We assume\r
+ that in the environment of this procedure the type T and the attributes of\r
+ class queue are visible.\r
+1 - 112 -\r
+ \r
+ \r
+ unit copying: procedure (input_queue, output_queue: head);\r
+ var input_buffer, output_buffer:T, completed:boolean, sem:semaphore,\r
+ counter:integer, getr:get_type, putr:put_type;\r
+ unit cobegin: procedure;\r
+ (*resumes the processes putr and getr, suspends the calling process*)\r
+ begin\r
+ lock(sem);\r
+ resume(putr);\r
+ resume(getr);\r
+ stop(sem)\r
+ end cobegin;\r
+ unit coend: procedure;\r
+ (*suspends the calling process, if both processes\r
+ are suspended then the main program is resumed*)\r
+ begin\r
+ lock(sem);\r
+ if counter=0\r
+ then\r
+ counter:=1\r
+ else\r
+ counter:=0; resume(main)\r
+ fi;\r
+ stop(sem)\r
+ end coend;\r
+ \r
+ unit get_type: process;\r
+ begin\r
+ return;\r
+ do\r
+ if empty(input_queue)\r
+ then completed:=true\r
+ else (*get next record*)\r
+ input_buffer := out(input_queue)\r
+ fi;\r
+ call coend;\r
+ od\r
+ end get_type;\r
+ \r
+ unit put_type: process;\r
+ begin\r
+ return;\r
+ do\r
+ call output_buffer.into(output_queue);\r
+ call coend;\r
+ od\r
+ end put_type;\r
+ \r
+ begin\r
+ if not empty(input_queue)\r
+ then\r
+ input_buffer:=out(input_queue);\r
+ getr:=new get_type; putr:=new put_type;\r
+ do (*copying*)\r
+ output_buffer:=copy(input_buffer);\r
+ call cobegin;\r
+ if completed then exit fi\r
+ od;\r
+ kill(getr); kill(putr)\r
+ fi\r
+ end copying;\r
+1 - 113 -\r
+ \r
+ \r
+ 11.3. Monitors (compound synchronization facilities)\r
+ *****************************************************\r
+ \r
+ \r
+ In this section we shall describe Hoare's monitors ([6]). A monitor is a\r
+ data structure shared by many processes and a set of procedures operating\r
+ on this structure. Access to the shared monitor data is possible only via\r
+ these procedures, and so their bodies constitute critical regions.\r
+ Let us present an example of a class that realizes Hoare's monitors.\r
+ Non-conflict access to the monitor data is realized by the so-called entry\r
+ procedures. An entry procedure has a prefix entry which guarantees that\r
+ only one such procedure may enter the monitor.\r
+ In order to permit scheduling of processes that have entered the monitor,\r
+ two specialized procedures operating on the inner monitor queues are\r
+ provided.\r
+ \r
+ delay(Q) -stops the execution of the process and puts it\r
+ into a queue Q, the entry to the monitor is free,\r
+ continue(Q) -resumes the execution of the first process from a\r
+ queue Q (if Q is non-empty, otherwise the entry to\r
+ the monitor is free).\r
+ \r
+ As can easily be seen, correct use of these constructs is achieved when\r
+ continue is called as the last statement of an entry procedure.\r
+ \r
+ The declaration of the class Monitor is as follows:\r
+ \r
+ unit Monitor : queue class;\r
+ hidden sem, queue;\r
+ var sem:semaphore;\r
+ \r
+ unit entry: class; (* all entry procedures must have prefix entry *)\r
+ hidden busy;\r
+ var busy:boolean;\r
+ unit delay: procedure(Q:queue);\r
+ begin\r
+ call Q.into(this process);\r
+ stop(sem)\r
+ end delay;\r
+ unit continue:procedure(Q:queue);\r
+ (* continue can be called as the last statement of an entry procedure *)\r
+ begin\r
+ if not Q.empty\r
+ then\r
+ busy:=true\r
+ resume(Q.out);\r
+ fi;\r
+ end continue;\r
+ begin (* beginning of the prefix entry *)\r
+ lock(sem); (* entry to the critical region *)\r
+ inner;\r
+ if not busy\r
+ then\r
+ unlock(sem)\r
+ fi;\r
+ end entry;\r
+ end Monitor;\r
+1 - 114 -\r
+ \r
+ \r
+ Example 1\r
+ ---------\r
+ \r
+ A simple mail-box system with a circular buffer may be defined as the\r
+ following class prefixed by a Monitor:\r
+ \r
+ unit Mailbox:Monitor class(type T; size: integer);\r
+ var pool: arrayof T, count, in_index, out_index: integer;\r
+ var readers_queue, writers_queue:queue;\r
+ unit writer:entry procedure (r:T);\r
+ begin\r
+ if count=size then call delay(writers_queue) fi;\r
+ in_index:=in_index mod size +1; count:=count+1;\r
+ pool(in_index):=r; call continue(readers_queue)\r
+ end writer;\r
+ unit reader:entry procedure (output r: T);\r
+ begin\r
+ if count=0 then call delay(readers_queue) fi;\r
+ out_index:=out_index mod size +1; count:=count-1;\r
+ r:=pool(out_index); call continue(writers_queue)\r
+ end reader;\r
+ begin\r
+ new_array pool dim (1:size);\r
+ redears_queue:=new queue; writers_queue:=new queue;\r
+ end mailbox;\r
+ \r
+ Example 2\r
+ ---------\r
+ Let W be a non-singular k to k matrix such that the norm of W is less than\r
+ 1. In order to solve the system of linear equations\r
+ \r
+ W*x = B\r
+ \r
+ one can use the Jacobi iteration method, i.e., for a given approximation Y\r
+ of a solution, the next approximation will be of the form:\r
+ \r
+ x(i)= -(W(i, 1)*y(1)+...+W(i, i-1)*y(i-1)+W(i, i+1)*y(i+1)+...+W(i, k)*y(k))+B(i)\r
+ \r
+ (without loss of generality one can assume that W(i, i)=1.)\r
+ \r
+ We shall use k parallel processes to compute the corresponding components\r
+ of the vector x. When the computation of all the components is completed,\r
+ the next approximation starts. Suppose that vector B is included in the\r
+ array W, i.e., it is the last column of W. In general, array W has many\r
+ zeros, and so instead of this array the user delivers the functions\r
+ computing the values\r
+ \r
+ -(W(i, 1)*y(1)+...+W(i, i-1)*y(i-1)+W(i, i+1)*y(i+1)+...+W(i, k)*y(k))+W(i, k+1)\r
+ \r
+ for the given vector y.\r
+1 - 115 -\r
+ \r
+ \r
+ unit Jacobi : procedure(k:integer;eps:real;inout x:array_of real;\r
+ function W(i:integer; y:array_of real):real);\r
+ (* eps-accuracy, the starting point of the iteration should be\r
+ the actual parameter corresponding to x, the final value of x\r
+ will be equal to the solution found *)\r
+ \r
+ unit jac_unit :Monitor class;\r
+ taken entry;\r
+ var dist:real, q:queue;\r
+ \r
+ unit puti: entry procedure(i:integer);\r
+ taken delay, continue;\r
+ begin\r
+ dist:=dist+abs(x(i)-y(i));\r
+ (*y-new iteration, x-old one*)\r
+ if q.cardinal<k-1 (*q.cardinal<k always*)\r
+ then (*wait for others*)\r
+ call delay(q)\r
+ else (*test stop condition*)\r
+ if dist<=eps\r
+ then\r
+ stop(done)\r
+ else\r
+ z:=x; x:=y; y:=z;\r
+ dist:=0; call continue(q)\r
+ fi\r
+ fi;\r
+ end puti;\r
+ \r
+ begin\r
+ q:=new queue;\r
+ end jac_unit;\r
+ \r
+ unit jac: process(i:integer);\r
+ begin\r
+ if i=1 then lock(done) fi;\r
+ return;\r
+ do\r
+ y(i):=W(i, x);\r
+ call jac_mon.puti(i);\r
+ od\r
+ end jac;\r
+ \r
+ var y, z:array_of real, jac_mon:jac_unit, j:integer, done: semaphore;\r
+ var jacob: array_of jac;\r
+ \r
+ begin\r
+ new_array y dim(1:k); new_array jacob dim(1:k);\r
+ jac_mon:=new jac_unit;\r
+ for j:=1 to k do\r
+ jacob(j):= new jac(j); resume(jacob(j))\r
+ od;\r
+ lock(done);\r
+ for j:=1 to k do kill(jacob(j)) od;\r
+ kill(y); kill(jacob); kill(jac_mon)\r
+ end Jacobi;\r
+1 - 116 -\r
+ \r
+ \r
+ \r
+ 12. Separate compilation of units\r
+ #################################\r
+ \r
+ \r
+ Prefixing is a very convenient way of designing large programs and systems.\r
+ These are constructed by linking together individual units and by using\r
+ prefixes as languages in which the programs are written. There are two\r
+ distinct purposes for compiling modules:\r
+ \r
+ -producing an object module, linking it with some units stored in\r
+ libraries and then executing it\r
+ -producing a library item which in turn may be connected with other\r
+ modules.\r
+ \r
+ \r
+ \r
+ Therefore LOGLAN-82 distnguishes two kinds of compilation units:\r
+ \r
+ -binary items ready to be executed, and\r
+ -library items.\r
+ \r
+ \r
+ By an item we mean the basic unit of compilation, i.e., the smallest and\r
+ self-contained class, coroutine, process, function or procedure. It defines\r
+ also the minimum interface, i.e., units which have to be accessible at run\r
+ time. Most of this section deals with how separately compiled units are put\r
+ together to build large systems.\r
+ Because of checking many context-sensitive conditions, LOGLAN-82 requires\r
+ access to system and user libraries; therefore the language provides tools\r
+ for processing them. The form of a library depends upon a given\r
+ implementation. However, the library has to store some necessary\r
+ information about the interface of a module, its source (or slightly\r
+ preprocessed) code and its object code. Each library posesses its own\r
+ identifier, built with respect to ordinary LOGLAN-82 rules. Any library\r
+ item is identified by its own identifier and the name of the library where\r
+ it is stored. A unit identifier must be unique within the library.\r
+ \r
+ \r
+ \r
+ Library items may be used by another module in two main ways:\r
+ \r
+ -as if they were declared within the module, or\r
+ -as if they were only accessible as non-local attributes from the\r
+ SL-chain of the module.\r
+ The first manner we shall call linking a library item, the other forms the\r
+ interface needed by the module.\r
+1 - 117 -\r
+ \r
+ \r
+ Example\r
+ -------\r
+ \r
+ Let M be an already compiled item stored in a library. And let N be an\r
+ item being compiled.\r
+ Linking means that the program tree of N is the following:\r
+ \r
+ \r
+ O <- N\r
+ . .\r
+ . .\r
+ O O <- linking point of M\r
+ . . .\r
+ O O .----\r
+ ! . !\r
+ ! O <- M - item from the library\r
+ ! !\r
+ -----\r
+ \r
+ If the item N specifies M in its interface, it is expected that the\r
+ module which links N is of the form:\r
+ \r
+ \r
+ .\r
+ .\r
+ O <- linking point of M\r
+ . .\r
+ ----. .\r
+ ! . ! .\r
+ M -> O ! .\r
+ ! ! .\r
+ ----- .\r
+ O\r
+ . .\r
+ . .\r
+ O O <- linking point of N\r
+ . .\r
+ . .\r
+ O .----\r
+ ! . !\r
+ ! O <- N\r
+ ! !\r
+ -----\r
+ \r
+ Indeed, in n's SL-chain-to-come the module N will also be linked.\r
+ \r
+ \r
+ The SL-chain-to-come of an item being compiled will be called the\r
+ environment of the linking point of the item.\r
+1 - 118 -\r
+ \r
+ \r
+ 12.1. Library items\r
+ *******************\r
+ \r
+ \r
+ A library item consists of the interface specification and the body. The\r
+ interface is a connector between separate units: it allows us to code in\r
+ the item the access parts of other units and to use other units as prefixes\r
+ or data types.\r
+ The interface defines three kinds of units needed in order to execute the\r
+ item:\r
+ -externals - these are already compiled units stored in libraries. They\r
+ are expected to be visible in the environment of the linking point,\r
+ -languages- these are also already compiled units stored in libraries.\r
+ They must prefix some module in the SL-chain-to-come,\r
+ -sl_virtuals - functions and procedures which will use the item being\r
+ compiled and its environment whatever links the item. They are not known\r
+ during the compilation of the item.\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <compilation of a library item>:\r
+ \r
+ --------->library item -->into <library identifier>-->;--->!\r
+ ! ! !\r
+ !--------------------------->-! !\r
+ !\r
+ <-----------------------------------------------!\r
+ !\r
+ !\r
+ !------> <interface specification> --->!\r
+ ! !\r
+ ! <------------------------------------!\r
+ !\r
+ !--> compile ---> <unit declaration> ---------------->\r
+ \r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ The item is compiled and then stored in a given library. If in the library\r
+ there is already a module of the same name, it is replaced by the one being\r
+ compiled .\r
+ The default library identifier is the userlib.\r
+ \r
+ Example.\r
+ --------\r
+ \r
+ library item into mathlib;\r
+ compile\r
+ unit sin : function (input x: real) : real;\r
+ .\r
+ .\r
+ end sin\r
+1 - 119 -\r
+ \r
+ \r
+ 12.1.1. Interface\r
+ *****************\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ <interface specification>:\r
+ \r
+ ---------->languages--> <language specification> --> ; ----->!\r
+ ! ^ ! !\r
+ ! !<----------- , ------------! !\r
+ ! !\r
+ ! <---------------------------------------------------!\r
+ !\r
+ !----> externals --> <external specification> --> ; ->!\r
+ ! ^ ! !\r
+ ! !<----------- , ------------! !\r
+ ! !\r
+ ! <---------------------------------------------------!\r
+ !\r
+ !----> sl_virtuals --> <sl_virtual specif. > --> ; -->!\r
+ ! ^ ! !\r
+ ! !<---------- , -----------! !\r
+ ! !\r
+ ! <---------------------------------------------------!\r
+ !\r
+ !------------------->\r
+ \r
+ \r
+ <language specification>:\r
+ \r
+ -----> <lib. item identifier> -----> from <library ident.> ------>\r
+ ^ ! ^ !\r
+ !<-------------- , -----------! !------------------------> !\r
+ \r
+ \r
+ <external specification>:\r
+ \r
+ ------> unit <lib. item identifier> : ----> class ------------>!\r
+ ! ^ !\r
+ !-> coroutine -->! !\r
+ ! ! !\r
+ !-> process ---->! !\r
+ ! ! !\r
+ !-> function --->! !\r
+ ! ! !\r
+ !-> procedure -->! !\r
+ !\r
+ ! <--------------------------------------------------------!\r
+ ! !\r
+ !---> from <library identifier> -------------------------> !\r
+ !->\r
+ \r
+ \r
+ The default library identifier is the userlib.\r
+1 - 120 -\r
+ \r
+ \r
+ <sl_virtual specification>:\r
+ \r
+ -> unit <identifier> : -> function -> <form. par. simp. list> ->!\r
+ ! !\r
+ ! !<-------------------------------!\r
+ ! !\r
+ ! !--> : <type identifier> -------->!\r
+ ! !\r
+ !--> <form. par. simp. list> ------------>!\r
+ !\r
+ !->\r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ \r
+ The interface defines a minimum environment of the point at which the item\r
+ being compiled is to be linked. It is used to code the item and also to\r
+ check its static properties. Therefore, changing externals or languages in\r
+ the library, the user has to recompile also units depending on them.\r
+ Identifiers of externals may be used in sl_virtual specification to\r
+ define types of parameters and by the compiled unit as prefixes, types of\r
+ data and so on. Interface specification is not redundant, i.e., if an\r
+ external or language uses some other library items in its own interface,\r
+ they do not have to be specified again. However, only identifiers of the\r
+ specified units are accessible in the item being compiled.\r
+ \r
+ Example 1.\r
+ ----------\r
+ \r
+ library item into datalib;\r
+ compile\r
+ unit heap : class....\r
+ ...\r
+ end heap;\r
+ \r
+ library item into datalib;\r
+ externals\r
+ unit heap: class from datalib;\r
+ compile\r
+ unit priority_queue: heap class ...\r
+ var z: heap...\r
+ end priority_queue;\r
+ \r
+ library item into proglib;\r
+ externals\r
+ unit priority_queue: class from datalib;\r
+ compile\r
+ unit prog1: class;\r
+ var x: priority_queue;\r
+ ...\r
+ end prog1;\r
+ \r
+ Within the body of prog1 we can use the identifier of the priority_queue.\r
+ Class heap will be automatically connected, we are not allowed, however, to\r
+ use the identifier of heap. To make it possible we should define another\r
+ interface:\r
+1 - 121 -\r
+ \r
+ \r
+ library item into proglib;\r
+ externals\r
+ unit priority_queue: class from datalib;\r
+ unit heap: class from datalib;\r
+ compile\r
+ unit prog2: class...\r
+ var x: priority_queue;\r
+ var y: heap;\r
+ ...\r
+ y:=x;\r
+ ...\r
+ X qua heap\r
+ end prog2;\r
+ \r
+ \r
+ Example 2.\r
+ ----------\r
+ \r
+ library item into datalib;\r
+ externals\r
+ unit heap: class from datalib;\r
+ compile\r
+ unit test: class;\r
+ var z: heap\r
+ ...\r
+ end test;\r
+ \r
+ library item into proglib;\r
+ externals\r
+ unit priority_queue: class from datalib;\r
+ unit test: class from datalib;\r
+ compile\r
+ unit prog3: class;\r
+ var p: priority_queue, e: test;\r
+ ...\r
+ p.z:=e.z\r
+ ...\r
+ end prog3;\r
+ \r
+ \r
+ In this interface heap means the same class for both the priority_queue\r
+ and the test.\r
+1 - 122 -\r
+ \r
+ \r
+ 12.1.2. Using languages\r
+ ***********************\r
+ \r
+ Languages are classes (coroutines, processes) already compiled. They are\r
+ expected to prefix modules in the SL-chain of the point of linking the item\r
+ being compiled. Their attributes may be used within the body of the\r
+ compiled item by means of the construction:\r
+ this <language identifier>.<attribute>\r
+ If it does not lead to any confusion, the phrase\r
+ this <language identifier>.\r
+ may be omitted. The rules of accessing attributes in the case of regular\r
+ units are also valid in the case of languages. A language may also be used\r
+ like any of the specified externals.\r
+ \r
+ Example.\r
+ --------\r
+ \r
+ library item into syslib;\r
+ compile\r
+ unit math: class;\r
+ ...\r
+ unit sin ...\r
+ end math;\r
+ library item into syslib;\r
+ compile\r
+ unit basicio: class;\r
+ ...\r
+ unit writereal...\r
+ end basicio;\r
+ library item;\r
+ languages math, basicio from syslib;\r
+ compile\r
+ unit prog: class...\r
+ ...\r
+ this math.sin (* or simply sin *)\r
+ this basicio.writereal (*or simply writereal *)\r
+ end prog;\r
+ \r
+ A correct use of the unit prog may be of the following form:\r
+ \r
+ library item;\r
+ externals\r
+ unit math: class from syslib,\r
+ unit basicio: class from syslib;\r
+ compile\r
+ unit user: class;...\r
+ basicio block...\r
+ math block...\r
+ class\r
+ external unit prog from userlib\r
+ (* this is linking prog- see 12.2 *)\r
+ ...\r
+ end user;\r
+1 - 123 -\r
+ \r
+ \r
+ 12.1.3. Using externals\r
+ ***********************\r
+ \r
+ \r
+ External items are expected to be linked by the environment of the linking\r
+ point of the item being compiled. They may be used like units which are\r
+ declared and visible in the environment of a regular object. Some simple\r
+ examples have been given in 12.1.1. Some others are given in 12.2.\r
+ \r
+ \r
+ \r
+ 12.1.4. Using sl_virtuals\r
+ *************************\r
+ \r
+ \r
+ The main purpose of sl_virtuals is to permit communication between the\r
+ compiled item and the modules which will use it. Communication may depend\r
+ upon the modules and there may be many fairly distinct of them. Sl_virtuals\r
+ and the modules are not previously compiled, i.e., they are not other\r
+ library items. Sl_virtuals are very similar to formal parameters or\r
+ external subroutines in FORTRAN.\r
+ \r
+ Example.\r
+ --------\r
+ \r
+ This is an example of a procedure which sorts real numbers stored in any\r
+ structure with operations put_real and get_real.\r
+ \r
+ library item into sortlib;\r
+ sl_virtuals\r
+ unit empty : function : boolean,\r
+ unit get_real : function : real,\r
+ unit put_real : procedure (input X : real),\r
+ unit clear : procedure;\r
+ compile\r
+ unit sqsetort : procedure;\r
+ ...\r
+ begin\r
+ (*reading numbers*)\r
+ while not empty\r
+ do\r
+ ...\r
+ get_real;\r
+ ... ...\r
+ od;\r
+ ...\r
+ (*writing numbers*)\r
+ clear;\r
+ do\r
+ ...\r
+ call put_real(Z);\r
+ ...\r
+ od;\r
+ ...\r
+ end sqsetsort;\r
+1 - 124 -\r
+ \r
+ \r
+ 12.2. Linking library items\r
+ ***************************\r
+ \r
+ \r
+ Declarations within a module may include specification of a library item to\r
+ be linked at that point.\r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <linked item specification>:\r
+ \r
+ ----------> external <external specification> ---------->\r
+ \r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ The object code of the linked item is added to the object code of the item\r
+ being compiled. Adding the same item a few times we create some unrelated\r
+ copies of the item as if the same source code occurred many times in\r
+ different places.\r
+ \r
+ \r
+ 12.2.1.Connecting the interface\r
+ *******************************\r
+ \r
+ \r
+ Languages and sl_virtuals.\r
+ --------------------------\r
+ \r
+ Languages and sl_virtuals specified by the linked item are looked for in\r
+ the environment of the linking point. If they are not found there, they\r
+ must be explicitly specified in the interface of the item being compiled.\r
+ \r
+ Example.\r
+ --------\r
+ \r
+ library item into lib;\r
+ compile\r
+ unit M : class;\r
+ ...\r
+ end M;\r
+ \r
+ library item into lib;\r
+ compile\r
+ unit N : class;\r
+ ...\r
+ end N ;\r
+ \r
+ library item into lib;\r
+ languages M, N from lib;\r
+ compile\r
+ unit P : class;\r
+ ...\r
+ end P;\r
+1 - 125 -\r
+ \r
+ \r
+ library item into lib;\r
+ languages M from lib;\r
+ compile\r
+ unit R : class;\r
+ ...\r
+ block\r
+ external unit N : class from lib;\r
+ ...\r
+ N block\r
+ ...\r
+ block\r
+ external unit P : class from lib;\r
+ ...\r
+ end r;\r
+ \r
+ Sl_virtual specification must be compatible in terms of the usual LOGLAN-82\r
+ rules with the actual version or with the specification in the interface of\r
+ the item being compiled.\r
+ \r
+ EXTERNALS\r
+ ---------\r
+ \r
+ The externals specified in the added item are taken from the SL-chain of\r
+ the linking point or from the interface of the item being compiled. If they\r
+ do not occur there, they are linked together with the specified linked item\r
+ at the same point.\r
+ \r
+ Example.\r
+ --------\r
+ \r
+ library item into lib;\r
+ compile\r
+ unit M : class;\r
+ ...\r
+ end M;\r
+ \r
+ library item into lib;\r
+ externals\r
+ unit M : class from lib;\r
+ compile\r
+ unit N : class;\r
+ var X : M\r
+ ...\r
+ end N;\r
+ (a)\r
+ library item into lib;\r
+ externals\r
+ unit M : class from lib;\r
+ compile\r
+ unit P : class;\r
+ external unit N : class from lib;\r
+ ...\r
+ end P;\r
+ \r
+ The actual version of the module M used by the module N is taken from the\r
+ interface of the module p. The SL-link of M is not known.\r
+1 - 126 -\r
+ \r
+ \r
+ (b)\r
+ library item into lib;\r
+ compile\r
+ unit P : class;\r
+ ...\r
+ external unit M : class from lib;\r
+ ...\r
+ block\r
+ ...\r
+ external unit N : class from lib;\r
+ ...\r
+ end P;\r
+ The module M used by the module N comes from P where it is linked. The\r
+ SL-link of M is P.\r
+ Notice that if the program tree is the following:\r
+ \r
+ \r
+ O <- P\r
+ . . .\r
+ . . .\r
+ ----. O O\r
+ ! . ! . .\r
+ M -> O ! . .\r
+ ! ! . .\r
+ ----- .---- .----\r
+ !. ! ! . !\r
+ N1 - copy of N-> O ! ! O <- N2 - copy of N\r
+ ! ! ! !\r
+ ----- -----\r
+ \r
+ Then the attributes X in both copies are compatible, i.e., they are of the\r
+ same type.\r
+ \r
+ \r
+ (c)\r
+ library item into lib;\r
+ compile\r
+ unit P : class;\r
+ unit R : class;\r
+ external unit N : class from lib;\r
+ ...\r
+ end R;\r
+ unit S : class;\r
+ external unit N : class from lib;\r
+ ...\r
+ end S;\r
+ ...\r
+ end P;\r
+ \r
+ In this case two copies of N are formed. Because there occurs no copy of M\r
+ in the SL-chain or in the interface of P, two copies of M are also added.\r
+ The attributes X in the copies of N are of different types and are not\r
+ compatible. The copies of M are "own" copies for each N.\r
+1 - 127 -\r
+ \r
+ \r
+ 12.3. Binary items\r
+ ******************\r
+ \r
+ \r
+ A binary item consists of a very simple interface specification and the\r
+ body. The interface defines languages in which the program is written. A\r
+ binary compiled program is embedded in a number of blocks prefixed by these\r
+ languages. There is also a block containing definitions of linked library\r
+ items.\r
+ Compilation of a binary item results in an object code ready for\r
+ execution.\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <compilation of a binary item>:\r
+ \r
+ -----> binary item ---> into <library identifier> ---> ; ------>!\r
+ ! ^ !\r
+ !---------------------------->! !\r
+ !\r
+ !<------------------------------------------------------------!\r
+ !\r
+ !-----> languages ---> <language specification> --> ; --->!\r
+ ! ^ ! !\r
+ ! !<------------ , ------------! !\r
+ ! !\r
+ ! <-------------------------------------------------------!\r
+ !\r
+ !------> externals ---> <external specification> --> ; -->!\r
+ ! ^ ! !\r
+ ! !<------------- , ------------! !\r
+ ! !\r
+ ! <-------------------------------------------------------!\r
+ !\r
+ !---> compile <declaration of a program unit> ----------------->\r
+ \r
+ \r
+ The rules of using languages and externals are the same as for library\r
+ items.\r
+ The default library identifier is bin.\r
+1 - 128 -\r
+ \r
+ \r
+ 12.4. Processing libraries\r
+ **************************\r
+ \r
+ \r
+ 12.4.1. Recompilation\r
+ *********************\r
+ \r
+ \r
+ LOGLAN-82 guarantees uniqueness for types and units. The compiler\r
+ associates a "time stamp" (time of definition and compilation) with each\r
+ compiled unit. Compiling a module twice (even if no changes are made in its\r
+ source code) makes all units defined in the module different\r
+ (non-equivalent). Therefore after some changes in the library we should\r
+ recompile all modules connecting the changed items.\r
+ For example, consider the case where defs1 is used by defs2, and defs2 is\r
+ linked with the user. Suppose that defs1 is recompiled for some reason,\r
+ then defs2 is recompiled, too. Then the user should also be recompiled,\r
+ because recompiling defs2 invalidated the version of the user.\r
+ \r
+ Compilations and recompilations must occur in a specific order.\r
+ To recompile a module storedin the library, LOGLAN-82 commands the\r
+ following syntax:\r
+ \r
+ \r
+ --> recompile --> <lib. item identifier> --> from <library ident.> -->\r
+ ^ !\r
+ !<------------ , ----------!\r
+ \r
+ It is suggested that the LOGLAN-82 compiler makes the necessary\r
+ recompilations automatically.\r
+1 - 129 -\r
+ \r
+ \r
+ 12.4.2. Insertions and deletions\r
+ ********************************\r
+ \r
+ \r
+ To insert an item into a library the programmer writes only the source code\r
+ of the item. It is a code between\r
+ \r
+ \r
+ \r
+ library binary item into <library identifier>;\r
+ ...\r
+ end\r
+ \r
+ \r
+ This code results in the insertion of the module into a given library. If\r
+ in the given library there already exists a module of the same name, the\r
+ new one replaces the old one.\r
+ \r
+ Deletions are made by using the following syntax:\r
+ \r
+ \r
+ --> delete ---> <lib. item identifier> ---> from <library ident.> ---->\r
+ ^ !\r
+ !<------------ , -----------!\r
+ \r
+ A linked item may be deleted from the library. However, the linking module\r
+ cannot be recompiled after that.\r
+1 - 130 -\r
+ \r
+ \r
+ 13. File processing\r
+ ####################\r
+ \r
+ \r
+ 13.1. External and internal files\r
+ *********************************\r
+ \r
+ External files are named after character strings and denote peripheral\r
+ devices or data sets. The logical and the physical structure of an external\r
+ file depend on the given computer and its file system, and so, for the\r
+ users of LOGLAN-82, external files are accessible via internal files only.\r
+ \r
+ \r
+ An internal file is an object of the predefined class type file. When an\r
+ internal file is generated, it may be associated with an appropriate\r
+ external file. Sometimes the user wish to generate an internal file not\r
+ associated with any specified external one. Such a file is called a local\r
+ file and its life-time is not longer than the life-time of the program\r
+ where it has been generated.\r
+ \r
+ \r
+ A file is always treated as an unbounded sequence of bytes. A file can be\r
+ read or written, and can be set to a required position. Each transmission\r
+ from or on a file starts at the byte pointed out by the so-called current\r
+ file position advanced by the number of transmitted bytes. File size is\r
+ defined as the greatest number of a byte transmitted on the file.\r
+ \r
+ There are some primitive facilities in the language which enable the user\r
+ to read or write a specified number of bytes, to change the current file\r
+ position, to obtain the file size, etc. All these facilities are in some\r
+ sense low-level, since they operate on bytes. The user is able, however, to\r
+ declare a class for file processing with high-level operations.\r
+ \r
+ An example of a system class which defines a set of input-output\r
+ operations applicable to files containing elements of a single type is\r
+ shown in 13.6. Moreover this is not the only way to define high-level file\r
+ processing. The user can declare, for instance, a class which defines\r
+ operations applicable to files containing elements of mixed types, a class\r
+ which defines operations on a file of arrays of various lengths, etc.\r
+1 - 131 -\r
+ \r
+ \r
+ 13.2. File generation and deallocation\r
+ **************************************\r
+ \r
+ \r
+ Before any operation on a file can be carried out, an internal file must\r
+ be generated. If the user wishes to communicate with an external file, then\r
+ the generated internal file must be associated with that external one. When\r
+ the generation of an internal file is in effect, the file is said to be\r
+ open.\r
+ \r
+ \r
+ SYNTAX\r
+ ------\r
+ <file declaration>:\r
+ \r
+ -----> <variable list> ----> : file -------------->\r
+ \r
+ <file generation>:\r
+ \r
+ --> open\r
+ !\r
+ !\r
+ (\r
+ !\r
+ <object expression> ---> , ---> <string> ----> ) ------->\r
+ ! !\r
+ !-------------------->!\r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ Variables of file type are declared as any other variables of class type.\r
+ An object of file type (internal file) has no attributes visible to the\r
+ programmer.\r
+ File generation differs from class generation. It is performed by an open\r
+ statement. If the second argument appears, then a new internal file\r
+ associated with an external one (identified by the string) is generated.\r
+ The reference to such an internal file is set to the variable of type file\r
+ occurring as the first argument. If there is only one argument, then a new\r
+ local file is generated and the reference to the corresponding internal\r
+ file is set to the variable of type file occurring as the argument of the\r
+ operation. For instance:\r
+ \r
+ open(X, "teletype")\r
+ \r
+ generates a new internal file associated with the external file "teletype".\r
+ Similarly\r
+ \r
+ open(Y)\r
+ \r
+ generates a new local file referenced by Y.\r
+1 - 132 -\r
+ \r
+ \r
+ Thus the operation new is not applicable to files. Moreover, remote\r
+ access to internal files is not permissible (no attributes visible to the\r
+ user).\r
+ Except file generation, remote access and prefixing, file type can be\r
+ applied as any other class type. In particular, expressions of file type\r
+ may be compared, assignments on variables of type file are allowed, the\r
+ user can declare a function of type file, etc.\r
+ \r
+ \r
+ Remark\r
+ ------\r
+ \r
+ External file processing is not predefined in the language. The\r
+ operations on external files, such as file creation, file deletion, file\r
+ protection and so on, depend on the given file system. They may be\r
+ introduced into the language as standard functions or procedures in the\r
+ individual implementation.\r
+ \r
+ End of remark\r
+ -------------\r
+ \r
+ \r
+ \r
+ After processing has been completed on a file, it can be closed and the\r
+ corresponding internal file may be deallocated. These actions are performed\r
+ by the kill statement, where the argument points to the corresponding\r
+ internal file.\r
+1 - 133 -\r
+ \r
+ \r
+ 13.3. Binary input-output\r
+ *************************\r
+ \r
+ \r
+ SYNTAX\r
+ ------\r
+ \r
+ \r
+ < binary input-output operations>:\r
+ \r
+ ---> put ---> (---> <object expression>-> , ---> <expression list> --> ) ---->\r
+ \r
+ ---> get ---> (---> <object expression>-> , ---> <expression list> --> ) ---->\r
+ \r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ \r
+ Operation put transmits a sequence of bytes from memory to an open file\r
+ (defined by the first parameter) at the current file position. This\r
+ sequence of bytes is defined by the list of expressions. For any list\r
+ element, going from left to right, the value of the expression is computed.\r
+ If this value is primitive, then the transmitted bytes correspond exactly\r
+ to the internal representation of the value. If the value is a reference to\r
+ an object, then the transmitted bytes cover all non-system attributes of\r
+ the referenced object. If this value is none, then no transmission is\r
+ performed.\r
+ Operation get transmits a sequence of bytes from an open file (defined by\r
+ the first parameter) to the memory. If a list element is an object\r
+ expression, then the transmitted bytes cover all non-system attributes of\r
+ the referenced object (hence, if the value of this expression is none, then\r
+ no transmission is performed). Otherwise, list element must be a variable\r
+ of primitive type, and then the transmitted bytes cover exactly its\r
+ internal representation. The sequence of transmitted bytes starts at the\r
+ current file position.\r
+ \r
+ For instance, let x be a real, i an integer and Y a reference variable to\r
+ an object of type A:\r
+ \r
+ unit A:class(j:integer);\r
+ var u, v, w:real;\r
+ end A;\r
+ \r
+ Then the statement\r
+ \r
+ put(F, x, i, x+i, "nothing", Y)\r
+ \r
+ transmits to file F the internal representation of the values of x, i, x+i,\r
+ the internal representation of the text "nothing" (i.e., the sequence of\r
+ characters) and the internal representation of the attributes j, u, v, w\r
+ from the object referenced by Y.\r
+1 - 134 -\r
+ \r
+ \r
+ 13.4. Other predefined operations\r
+ *********************************\r
+ \r
+ \r
+ SYNTAX\r
+ ------\r
+ <size operator>:\r
+ \r
+ !-----> <type> ----------->!\r
+ ! !\r
+ ------> size ---> ( -! !---> ) -------->\r
+ ! !\r
+ !----> < expression> ----->!\r
+ \r
+ <eof operator>:\r
+ \r
+ ------> eof -----> ( ---> <object expression> ----> ) ------------------>\r
+ \r
+ <position operator>:\r
+ \r
+ ----> position ---> ( ---> <object expression> -----> ) --------------->\r
+ \r
+ <seek operation>:\r
+ \r
+ --> seek --> ( --> <object expression> --> , --> <arithmetic expression> --> ) -->\r
+ \r
+ SEMANTICS\r
+ ---------\r
+ \r
+ \r
+ The size operator of integer type gives the number of bytes of the\r
+ internal representation of an argument. If the argument is an expression of\r
+ primitive type, then the returned value may be computed at compilation time\r
+ and equals the number of bytes of the internal representation of that\r
+ primitive type. If the argument is an expression of class or array type,\r
+ then the returned value gives the number of bytes of the object referenced\r
+ by the argument (except system-attributes). If the object none is\r
+ referenced, then the returned value is 0.\r
+ Another kind of argument of size operator is type. It may be either an\r
+ explicitly written type or a formal type. If the argument is a primitive\r
+ type or a class type, then its length in bytes computed at compilation time\r
+ is returned. If the argument is an array type, then its size cannot be\r
+ established and so the expression is incorrect. If the argument is a formal\r
+ type, the returned value is defined similarly but computed at run time.\r
+ Thus when the actual type is array the run time error is raised.\r
+ In all these cases size operator informs the user about the length in\r
+ bytes of the internal representation of the argument (if possible). In\r
+ particular, the argument may be a file and then the length in bytes of the\r
+ corresponding external or local file is returned.\r
+ \r
+ The argument of the boolean operator eof must be a file. It returns the\r
+ value true iff the current position of the file exceeds or equals its size.\r
+ The argument of the integer operator position must also be a file. It\r
+ returns the current position of the file.\r
+ The first argument of the seek operation must be a file. Then the current\r
+ position of this file is set to the value defined by the second argument of\r
+ the operation.\r
+1 - 135 -\r
+ \r
+ \r
+ 13.5. Text input-output\r
+ ***********************\r
+ \r
+ \r
+ Besides binary input-output LOGLAN-82 provides text input-output\r
+ operations also. The operations read and write are available for input and\r
+ output in human readable form. Namely, operation read decodes a sequence of\r
+ bytes into the internal representation of the corresponding value before\r
+ the transmission is performed. Similarly operation write encodes the\r
+ internal representation of a value into the corresponding sequence of bytes\r
+ before transmission is performed.\r
+ \r
+ \r
+ SYNTAX.\r
+ -------\r
+ \r
+ \r
+ <text input-output statement>:\r
+ \r
+ !--------------------------->!\r
+ ! !\r
+ --> read --> ( --> <object expression> ---> , --> <variable list> --> ) ---->\r
+ \r
+ \r
+ !------------------------------------>!\r
+ ! !\r
+ ->writeln --> ( --> <object expression> --> ) ------------------------->\r
+ !\r
+ !\r
+ ->write --> ( -------------->!\r
+ ! !\r
+ <object expression>-> , -> <expression> ----> <format> ---> ) -------->\r
+ ^ !\r
+ !<--------- , ------------!\r
+ \r
+ \r
+ <format>:\r
+ \r
+ ------------------------------------------------------------------->\r
+ ! ^ ^\r
+ !-> : -> <arithmetic expression>-!- : -> <arithmetic expression> -!\r
+1 - 136 -\r
+ \r
+ \r
+ SEMANTICS.\r
+ ----------\r
+ \r
+ An input statement read(F, y1, ..., yk) is correct if F is a file and y1,\r
+ ..., yk are variables of integer, real, or character type. File F is\r
+ treated as a sequence of symbols. The execution of that statement causes\r
+ the input data represented as the corresponding sequence of symbols from\r
+ file F to be read, decoded and assigned to y1, ..., yk respectively. The\r
+ input statement is defined if the assignments are defined (going from left\r
+ to right).\r
+ An output statement write(F, E:A1) is correct if F is a file, E is an\r
+ expression of a primitive type, and A1 is an arithmetic expression of\r
+ integer type.\r
+ Consider first the case where expression E is of integer type. The value\r
+ of expression A1 determines the number of symbols to be outputed on file F.\r
+ If the specified number of symbols is greater (less) than the number of\r
+ symbols required for the representation of the value of expression E, then\r
+ the value of E is preceded by the appropriate number of blanks (then the\r
+ least significant digits are omitted). The absence of format indicates a\r
+ standard one (dependent on an individual implementation).\r
+ If expression E is of real type, then the output statement may be of the\r
+ form write(F, E:A1:A2), where A1 and A2 are arithmetic expressions of\r
+ integer type. The meaning of the expression A1 is that described above, the\r
+ value of the expression A2 determines the number of digits following the\r
+ decimal point. In case of an output statement of the form write(F, E:A1),\r
+ where E is of real type, the exponent part is always present. The absence\r
+ of format indicates a standard one (dependent on an individual\r
+ implementation).\r
+ An output statement of the form write(F, E) where E is an expression of\r
+ character type causes the external representation of E to be outputed on\r
+ file F.\r
+ If E is an expression of string type, then its external representation is\r
+ outputed on file F. In this case format A1 may appear and defines the\r
+ maximal number of symbols which may be outputed, i.e., if the length of a\r
+ string exceeds the defined format, then the last symbols are dropped.\r
+ In the statement write(F, E:A1:A2) format A2 is computed first (if\r
+ present), format A1 is computed next (if present), and finally the value of\r
+ E is computed and outputed according to the defined formats.\r
+ The execution of an output statement with a list results in the\r
+ successive evaluations of the expressions A2, A1, E, and in the output of\r
+ the computed value.\r
+ Statement writeln outputs the end of line symbol after output is\r
+ completed. If writeln has only the file parameter, then the end of the line\r
+ symbol is outputed on file F.\r
+ If no file is specified, a default standard input or standard output file\r
+ is used. At the beginning of program execution, these files are open and\r
+ associated with two implementation defined external files.\r
+1 - 137 -\r
+ \r
+ \r
+ 13.6. Example of high-level file processing\r
+ *******************************************\r
+ \r
+ A class defining high-level file processing is presented below. The user\r
+ can prefix the main block of his program by such a class, and then, the\r
+ high-level file operations are provided automatically.\r
+ \r
+ unit input_output class;\r
+ hidden uni_file;\r
+ unit uni_file :class(type T);\r
+ hidden element_size;\r
+ var F:file, element_size:integer;\r
+ unit set_position:procedure(i:integer);\r
+ begin\r
+ call seek(F, i*element_size)\r
+ end set_position;\r
+ unit file_position:function:integer;\r
+ begin\r
+ result:=position(F) div element_size\r
+ end file_position;\r
+ unit end_of_file:function:boolean;\r
+ begin\r
+ result:=eof(F)\r
+ end end_of_file;\r
+ unit file_size:function:integer;\r
+ begin\r
+ result:=size(F) div element_size\r
+ end file_size;\r
+ unit read_element:procedure(output x:T);\r
+ begin\r
+ get(F, x)\r
+ end read_element;\r
+ unit write_element:procedure(x:T);\r
+ begin\r
+ put(F, x)\r
+ end write_element;\r
+ begin\r
+ element_size:=size(T)\r
+ end uni_file;\r
+ unit inout_file:uni_file class(S:string);\r
+ hidden F;\r
+ begin\r
+ open(F, S)\r
+ end inout_file;\r
+ unit in_file:inout_file class;\r
+ hidden write_element;\r
+ end in_file;\r
+ unit out_file:inout_file class;\r
+ hidden read_element;\r
+ end out_file;\r
+ unit local_file:uni_file class;\r
+ hiddden F;\r
+ begin\r
+ open(F)\r
+ end local_file;\r
+ unit close_file:procedure(E:uni_file);\r
+ begin\r
+ kill(E.F); kill(E)\r
+ end close_file;\r
+ end input_output;\r
+1 - 138 -\r
+ \r
+ \r
+ Bibliography.\r
+ #############\r
+ \r
+ Part A: the papers related to the language itself.\r
+ \r
+ [1] Bartol W.M, Kreczmar A., Litwiniuk A., Oktaba H.: Semantics and\r
+ implementation of prefixing at many levels, Ins.Inf.U.W. reports, nr 94.,\r
+ 1980.\r
+ \r
+ [2] Bartol-Ratajczak W.M., Szczepanska-Wasersztrum D.: Data structure for\r
+ simulation purposes in LOGLAN. ICS PAS report 373, 1979.\r
+ \r
+ [3] Dahl O-J., Myhrhaug B., Nygaard K.: Common base language. NCC s-22,\r
+ October 1970.\r
+ \r
+ [4] Dahl O-J., Wang A.: Coroutine sequencing in a block structured\r
+ environment. BIT 11, 1971, pp.425-49.\r
+ \r
+ [5] Hansen P.B.: CONCURRENT PASCAL, a programming language for operating\r
+ system design. IST report no.10 April 1974.\r
+ \r
+ [6] Hoare C.A.R.: Monitors, an operating system structuring concept. CACM,\r
+ vol.17, n.10, October 1974, pp.549-57.\r
+ \r
+ [7] Muldner T.: On the properties of ADA's rendez-vous and an\r
+ implementation of its counterpart in LOGLAN. To appear.\r
+ \r
+ [8] Muldner T.: LOGLAN-82 programmer's manual (in Polish), pp.1-417.\r
+ \r
+ [9] Myhre O.: Protecting attributes of a local class. SIMULA Newsletters,\r
+ vol.5, n.4. November 1977.\r
+ \r
+ [10] Naur P.(ed): Revised report on the algorithmic language ALGOL 60. ACM\r
+ 6, 1963, pp.1-7.\r
+ \r
+ [11] Preliminary ADA reference manual. Sigplan Notices, vol.14 n.6, June\r
+ 1979.\r
+ \r
+ [12] Salwicki A., Muldner T., Oktaba H., Bartol-Ratajczak W.M.: Base\r
+ machine language. General outline. (in Polish). Archiwum opracowan nr 20,\r
+ 1977, IMM MERA.\r
+ \r
+ [13] Wirth N.: The programming language PASCAL, Acta Informatica, 1971, 1,\r
+ pp. 35-63.\r
+1 - 139 -\r
+ \r
+ \r
+ Part B: The papers related to the general project LOGLAN-82\r
+ \r
+ [14] Aho A.V., Hopcroft J.E., Ullman J.D.: The design and analysis of\r
+ computer algorithms. Addison-Wesley. 1974.\r
+ \r
+ [15] Banachowski L., Kreczmar A., Mirkowska G., Rasiowa H., Salwicki A.: An\r
+ introduction to algorithmic logic. Mathematiccal investigations in the\r
+ theory of programs. In Banach Center publications, Warsaw 1977.\r
+ \r
+ [16] Bartol W.M.: The definition of the semantics of some statements of a\r
+ block structured language with type prefixing. To appear in: Lect.Notes in\r
+ Comp. Sc. Proc. Poznan 1980, Symp. on algorithmic logic and LOGLAN.\r
+ \r
+ [17] Burkhard H.D.: On priorities of parallelism: Petri nets under the\r
+ maximum firing strategy. To appear in Lect. Notes in Comp.Sc. Proc. Poznan\r
+ 1980, Symp. on algorithmic logic and LOGLAN.\r
+ \r
+ [18] Dahl O-J., Dijkstra E.W., Hoare C.A.R.: Structured programming.\r
+ London. Academic Press 1972.\r
+ \r
+ [19] Muldner T.: On the semantics of parallel programs. ICS PAS report 348,\r
+ 1979, extended version to appear in Fund. Informaticae.\r
+ \r
+ [20] Muldner T.: Implementation and properties of certain tools for\r
+ parallel programs. ICS PAS report 356, 1979. see also FCT' 77,\r
+ Lect.Not.Comp.Sc.56.\r
+ \r
+ [21] Oktaba H.: On the algorithmic theory of references. To appear in:\r
+ Lect.Not. in Comp.Sc. Proc. Poznan 1980, Algorithmic logic and LOGLAN.\r
+ \r
+ [22] Salwicki A.: Programmability and recursiveness, to appear.\r
+ \r
+ [23] Salwicki A.: Formalized algorithmic languages. Bull.Acad. Polon.Sci.\r
+ 18, 1970, pp.227-232.\r
+ \r
+ [24] Salwicki A.: Applied algorithmic logic. Proc. MFCS' 77. Lect.Not. of\r
+ Comp.Sc. 53, 1977, pp.122-134.\r
+ \r
+ [25] Salwicki A.: An algorithmic approach to set theory. Proc.FCT'77. Lect.\r
+ Not. in Comp. Sc. 56, 1977.\r
+ \r
+ [26] Salwicki A.: On the algorithmic theory of stacks. Proc. MFCS' 78\r
+ Lect.Not. in Comp.Sc. 64, 1978.\r
+1 - 140 -\r
+ \r
+ \r
+ \r
+ Index\r
+ #####\r
+ \r
+ \r
+ A D\r
+ actual paratemetr list, 76 deallocation, 17, 83\r
+ allocation statement, 75-81 - statement, 83\r
+ andif, 9 declaration list, 41\r
+ arithmetic expression, 64-66 detach, 86,104,108\r
+ array, 18,29,75,82 dotted variable, 60\r
+ - generation statement 18,75,82 dynamic compatibility\r
+ - object, 29 of parameters, 79\r
+ - type, 29 dynamic consistency\r
+ assignment statement, 72 of types, 55\r
+ attach, 20,86,104,108 dynamic control statements, 85\r
+ attribute, 11,30,42 dynamic instance, 11,13\r
+ dynamic location, 42,54\r
+ \r
+ B E\r
+ binary item, 126 evaluation statement, 71-73\r
+ block statement, 11-12,35,75 exception, 22,96\r
+ block structure,11 - handler, 22,97\r
+ - handling, 96\r
+ exit, 9,84,91\r
+ C expressions, 56\r
+ call statement, 13 external, 122-123\r
+ case statement, 10,87,89 external file, 129\r
+ character, 23\r
+ character expression, 67 F\r
+ class, 14,33 file, 129,136\r
+ - declaration, 33 - declaration, 130\r
+ - object, 14,17 - generation, 130\r
+ close, 22,40,45 formal\r
+ comment, 25 - function parameter, 38-39\r
+ compound statement, 8,71,87-88 - input parameter, 37-39\r
+ conditional statement, 8,87 - output parameter, 37-39\r
+ configuration statement, 71 - parameter, 37-39\r
+ consistency of types, 55 - procedure parameter, 38-39,41\r
+ constant ,31,57 - type, 30\r
+ - declaration, 31 - type parameter, 37-39\r
+ context properties, 56 function, 13\r
+ copy, 74 - call, 75-81\r
+ copying statement, 72,74\r
+ coroutine, 20,28,36,86\r
+ - object, 20\r
+ - statement, 86\r
+1 - 141 -\r
+ \r
+ \r
+ G O\r
+ garbage collection, 17 object, 14,48\r
+ get, 132 - deallocation, 75,83\r
+ - deallocator, 17\r
+ H - expression, 69-70\r
+ handler - generation, 75\r
+ - declaration, 40 - generator statement, 14\r
+ - execution, 101-102 orif, 8\r
+ - termination, 101-102\r
+ hidden, 22,40,43\r
+ \r
+ I P\r
+ identifier definition, 25 parallel statement, 105\r
+ illegal identifier, 44 prefix 15-16,36\r
+ inheritance list, 40 - sequence, 36\r
+ inner, 16,41,84 prefixing, 15,36\r
+ interface, 118 primitive statement, 71\r
+ internal file, 129 primitive synchronizing\r
+ iteration statement, 9,10,90-92 statement, 105,109\r
+ procedure, 13\r
+ K - call, 75-81\r
+ kill, 17,83 process, 21,28,36,104\r
+ - state transition, 105\r
+ L protection list, 40\r
+ languages, 118,121-123 protection of attributes, 22,43\r
+ last_will, 101-102 put, 132\r
+ - statement, 101-102\r
+ legal identifier, 44 Q\r
+ lexical entity, 25 qua, 70\r
+ library items, 115,117 qualified object expression, 69-70,76\r
+ linked item specification, 31\r
+ lock, 21,109 R\r
+ loop statement, 87,91 raise, 98\r
+ read, 134-135\r
+ M recompilation, 127\r
+ main, 28 reference variable, 14\r
+ monitor, 112 remote\r
+ - access, 14\r
+ N - function identifier, 76\r
+ none, 69 - procedure identifier, 76\r
+ repeat, 10,84,91\r
+ resume, 21,104,107-108\r
+ return, 84\r
+ run-time error, 22\r
+1 - 142 -\r
+ \r
+ \r
+ S T\r
+ scheduling, 21,105 taken, 40,44\r
+ semantic properties, 56 terminate, 101-102\r
+ semaphore, 27 textual control statement, 84\r
+ separate compilation, 22,115-128 this, 70\r
+ sequential statements, 71 ts, 21,109\r
+ signal, 96 type, 26\r
+ - declaration, 31 - class, 30\r
+ - handler, 97 - compound, 26,29\r
+ - raising, 98 - primitive, 26-27\r
+ - specification, 96\r
+ simple control statement, 84 U\r
+ simple variable, 58 unit, 13,25,31\r
+ sl-virtual, 118,122-123 - attributes, 42\r
+ statement list, 41 - body, 40-41\r
+ static attribute, 46 - declaration, 31\r
+ static compatibility unlock, 21,109\r
+ of parameters, 77\r
+ static consistency V\r
+ of types, 55 variable, 32,57\r
+ static container, 46 - declaration, 31\r
+ static location, 42,46 virtual\r
+ storage management, 17 - attribute, 49-53\r
+ stop, 21,104,107-108 - chain, 49-53\r
+ string, 27 - subprogram, 49-53\r
+ - constant, 68 visibility rules, 42,44\r
+ - expression, 68\r
+ subprogram declaration, 34 W\r
+ - body, 40 wait, 21,107-108\r
+ subscripted variable, 59 wind, 101-102\r
+ synchronization, 21,105 write, 134-135\r
+ syntactic writeln, 134-135\r
+ - entity, 42\r
+ - father, 12\r
+ - unit, 13,42\r
+ system signals, 103\r
+ system variable, 61\r
projects / loglan.git / commitdiff
