Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
STRUCTURFD CONTROL IN PRCGRAMMING LANGUAGES*. Charles T. Zahn, Jr. Computation Research Group. Stanford Linear Accelerator Center. Stanford, California.
Typology: Exercises
1 / 9
This page cannot be seen from the preview
Don't miss anything!
Charles T. Zahn, Jr. Computation Research Group Stanford Linear Accelerator Center
*This work supported by the U.S. Atomic Energy Commission under contract
Conceptual Distance Solving a problem with the aid of a computer involves the construction and execution of a program described by a linear piece of text. First,^ the^ problem- solver (programmer) translates his problem into a precedural solution embodied in a static program text, written in a programming language. Then^ a^ computer is caused to perform a dynamic sequence of actions in accordance with the com- mands in the program text. The reliability of this two-stage problem solution
( i.e.,^ the^ likelihood^ that^ the^ actions^ performed^ really^ provide^ a^ solution^ of the problem) depends on the degree to which the program text mirrors the pos- sible action sequences that it causes, as well as the problem solution that it purports to implement. It is useful to speak of the tlconceptual distance" be- tween program text and action sequences or between problem definition and pro- gram text. The programmer who wants some measure of confidence in the reli- ability of his program must bridge both these conceptual distances. It follows that a major goal of programming language design should be to help reduce both these distances. Structured Control Structured programming' (^) is a systematic step-wise method of program com- position which can be used to conquer the distance between problem and program by chopping it into bite-sized pieces and employing abstraction as a mental aid to control the problem of complexity. It reduces the distance between program text and action sequence by employing in the program text only those forms of sequence control which allow an easy visualization of the possible action se- quences from an inspection of the static linear program text. The control structure includes sequential grouping of commands as well as command selection
-l-
The special case (N=2, Cl=true, C2=false^ and^ T evaluates^ a^ logical^ ex- pression B) represents the familiar control form (^) - if B then Sl else S2. The case (Ck=+ for 15 k 5 N and T selects that constant Ck equal to the value of an integer expression E) represents Hoare's integer case"statement with the syntax case E s (Sl;S2;.,..;SN). This^ expression-driven^ case^ statement^ has been generalized' and implemented in PASCAL.3 By allowing^ constants^ Ck and expression E to correspond to any finite type (especially programmer defined types like Color whose 4 constant values might be Green, Blue, Red, Black), the conceptual distance between problem and program can be greatly reduced. There remain situations in which the selection is not conveniently reduced to an expression evaluation, and T must be a compound command which returns a value Ck' It also naturally occurs that at certain places within T, it be- comes clear which value should be selected and an immediate termination of T
extend the restricted control by allowing any compound statement to be labeled; then a statement of the form (^) --leave L with E, causes immediate termination of the enclosing statement labeled L and returns E as its value. It^ is,^ therefore, easy to implement the more general selection
of the form
mechanism T within BLISS. A more is an event-driven case statement
until Cl E C2... E CN _do^ T then^ case^ (Cl:Sl;...;CN:SN) with event statements CF within T, causing immediate termination of T and selection of Ck. Each Ck is an identifier or name created by the programmer to provide a problem-oriented description of what the program is doing. The syntax for this generalized case statement was motivated by considerations of writing and reading programs in a top-down fashion. The number of similar pro- posals for a termination mechanism (see the survey by Knuth7) shows the uni-
versa1 need for such a programming device. Other common situations requiring an explicit termination mechanism are repetitions of a command sequence where the detection of the termination condition naturally occurs midway through the sequence and the handling of error conditions which haveI' various degrees of severity. Repetitions with a Control Value : It is a common need in programming to repeat a given compound command once for each of a well-defined finite sequence of values, where that value is accessable (but'not changeable) within the repeated command. When the^ pro- grammer's intent is exactly reflected in this special form of repetition, there is a great gain in clarity when the program text employs a special syn- tax to indicate the repetitive pattern. Certainly,^ there^ should^ be^ a repetition like repeat for V from El. [upthru/downthru]E2 do S(V) where V is a variable of ordered finite type and El, E 2 are^ expressions^ of^ that type. This^ is^ the^ form^ (with^ slight^ differences^ in^ syntax)^ of^ for^ statement
Serious consideration should be given to extensions of the for statement to cater for progressions of values defined by more general successor functions. For example, the programmer who builds sequences using records and references is helped immensely by statements like repeat (^) --for R from Start 9 Next upto--- null do S(R). where R is a reference variable whose values are Start, Next (Start), Next (Next(Start)), etc., up^ to^ but^ not^ including^ null.^ The use^ of^ words^ upthru, downthru, upto is an attempt to reduce the ambiguity that results from not making explicit the distinction between inclusion or exclusion of the final item.
The program text of a procedure or function should indicate all those global (i.e., non-local, non-parameter) variables which are referenced within it-with-a textually clear distinction of those which are potentially alterable by the procedure. No functions should alter any globals. i' Whether this addi- tional program documentation is made the responsibility of the programmer or a helpful compiler -- in either case it provides crucial textual evidence to aid the programmer in visualizing the possible dynamic actions caused by a given invocation of the procedure or function. Another important restriction is the disjointness of the set of alterable parameters and global variables. Failure to comply with this restriction may cause very nasty and subtle errors. It has recently been proposed by Hardgrave^10 that^ a^ keyword,^ rather^ than positional notation for the correspondence between formal and actual parameters, would have several nice advantages, one of which is the obvious textual clarity of the programmer's intent. In the case of procedures and functions with long parameter lists, there is a disturbing potential for erroneous parameter com- munication even in a highly typed language. By allowing default actual par- ameters" (^) for certain formal parameters to be explicitly given within the procedure declaration, the textual length of the invocation can often be kept reasonably small in spite of the apparent verbosity of the keyword notation. It is also possible to add. a new parameter without altering previously written invocations of the procedure -- a potentially non-trivial advantage in a large software project requiring modifications through time. Recursive procedures and functions should be allowed since they reflect problem solutions whose reprogramming without recursion involves considerable conceptual distortion and, therefore, increases the conceptual distance be- tween problem and program. In a similar way, there are certain problems which are most natura lly solved by two or more procedures whose relationships to one
I
another are more symmetric than the normal hierarchical procedure relation- ships. 11 Such procedures are known as coroutines or semi-coroutines and they dsffer from normal procedures in that each time they are invoked from another coroutine they resume execution where they last left off. Their cooperative behavior is understandable in terms of an anthropomorphic model in which each coroutine is executed by a different person who simply goes to sleep when he resumes one of the other coroutines, but when his own coroutine is resumed again he awakens in the same state as before he went to sleep. Coroutines^ can be used to obta,in the conceptual advantages of a multi-pass algorithm without the actual need for secondary storage and data format specifications usually implied by a literal implementation of the separate passes. 12 Especially com- pelling examples of the conceptual correctness of coroutines are to be found in Dahl. (^11) The coroutines discussed here are never in simultaneous or inter- leaved execution so their correct behavior doesn't involve the deeper problems of mutual exclusion, deadlock, etc. Conclusion An attempt has been made to discuss various issues involved in the design of control for a programming language by relating these design issues to the goal of reducing Wconceptual distance". A slight compromise to the strict structured control seems justifiable to obtain a more problem-oriented control. More research would be worthwhile in the area of "safe" iterations, parameter mechanisms and coroutines.
