PANCODE(ID:5293/)Generalised structured programming sytem that expresses all structures in terms of do, if, repeat, else, and also, as well as the "sentence markers" { and } All structural extents are indicated with whitespace Draws on tradition of executable notation and flowcharts (Nassi-Scheidermann, FLowcharts etc)to produce a matching kind of charting system, the Boxchart. Dan Jonsson, Univ. of Goeteborg, 1987 Related languages
References: Introduction Following Boehm and Jacopini's [1] work on the representation of control flow in terms of if...then...else.., and while...do.., structures, and inspired by the debate over the use of goto-statements [2, 3], the problem of control structures for programming languages has received much attention, especially during the 1970's. Principles and methods for 'structured programming', based on selected control structures, have been proposed by Dahl, Dijkstra and Hoare [4], Wirth [5], Jackson [6] and others. At present, however, control structures seem to be somewhat out of fashion. The debate over the proper definition and use of control structures appears to have reached a dead end. 'In theory', it is maintained, while...do.., and if...then...else.., suffice as structuring devices. On the other hand, however, it is tacitly or explicitly admitted that 'in practice' structured programs require not only additional control structures such as repeat...until.., and loop...exit.., but also Boolean variables, state variables, duplication of code, and various other devices. This uneasy compromise, with its unfortunate separation of 'theory' and 'practice', should not be allowed to block further progress in this area. In this article, I intend to provide some evidence that with more adequate control constructs theoretical and practical solutions coincide, and no a d hoc control structures or contrived solutions will be needed. Another reason for reconsidering control structures is their relation to the problem of graphical representation of program structure. Originally, control structures appear to have been developed without regard to how they might be represented graphically. It is true that many types of 'structured flowcharts' supporting selection and iteration constructs have also been proposed [6, 7], but mostly as an afterthought. Especially in graphical programming applications [8, 9, 10], however, it is essential that there is a close and harmonious relationship between the constructs of the programming language employed and those of the charts used to visualize programs. To achieve this, control structures and charts for representing program structure should be developed together and regarded almost as two sides of the same coin. In this paper, then, I present some new ideas concerning control structures, program charts, and the relationship between the two. Although they did not serve as sources of inspiration, Elliott's [11] 'Executable Program Notation' and Leinbaugh's [12] notion of 'indenting for the compiler' may be cited as examples of previous contributions relating to the present theme. Extract: Conclusions Conclusions The concepts discussed in this article concern or have implications for a large number of subjects, including structured programming; the design of programming languages; the representation of algorithms; program structure analysis and program restructuring; syntax directed program editing and program formatting; structured flowcharts, graphical editors, and graphical programming. In conclusion, I shall indicate several features that make pancode and boxcharts significant in the context of structured programming: in SIGPLAN Notices 22(08) August 1987 view details Guidelines for introducinq new control words Ever since the qoto became anathema [Dijk 68], programming language designers have busied themselves finding ever more clever ways of writing jumps without saying "qoto'. In the beginning, a hundred flowers bloomed, but as a community we have gradually learned, by experience, some things about desirable qualities that proposed new control constructs should have. I would suggest the following five criteria. First, following the example of Dijkstra [Dijk 76] and Wirth (a convert) [Wirt 85]: 1) Control-block structures should be terminated by a closing control word. For example, an if block will be closed by a f_L (or endif). The use of a closing control word avoids both the problem of beqin...end clutter and the confusion of "dangling" intermediate control words in nested blocks. It also clearly delineates (lexically) the block from beginning to end, which greatly enhances the readability of a (real) program. The next two criteria need no commentary: 2) It should be lexically crystal clear where a control word jumps to. 3) A new control construct should not result in a lexical clutter worse than that of the problem being cured. And the last two criteria are social, favouring evolution over revolution: 4) Preferably, new control words should add to, not supplant, the existing widely accepted set of control structures. 5) The smaller the number of new control words, the better. Extract: Conclusions Conclusions The embedded loop exit command (a la C or Ada) is powerful, simple, and clear. It has not been demonstrated that a loop repeat command is more advantageous. The fail (Elliott's SKIP) control command is useful for programming nested if blocks that have intrinsic "afterthoughts". The fail command fits in a block structure with a closing control word, causes a lexically clear jump, does not cause clutter, only adds to the existing control structure mechanisms without supplanting any of them, and is a minimal (single) addition. It is a simple, clear, and elegant control mechanism. in SIGPLAN Notices 23(12) December 1988 view details It is somewhat unfortunate that (with one exception) notations published prior to 1977 are not included in the survey, so that justice is not done to some people who did early, seminal work on graphical program notations. As noted by Botting [2}, this applies to Jackson [5] and Warnier [13], and another omission is Nassi and Schneiderman's 1973 contribution [9]. Several box notations discussed by Tripp seem to be inspired by Nassi- Schneiderman diagrams. I would also like to add some comments on Boxcharts [6]. DOI in SIGPLAN Notices 24(07) July 1989 includes Proceedings of the SIGPLAN '87 symposium on Interpreters and interpretive techniques view details in SIGPLAN Notices 24(03) March 1989 view details - Yes, but this one is different... In his assessment of Pancode control constructs, Kovats [4] seems to argue that there is no need to introduce radically new control constructs, since the traditional constructs, if amended as described by Kovats, have sufficient expressive power. I feel that Kovats' analysis is somewhat biased in favor of traditional control constructs at the expense of radical alternatives such as Pancode, and to support that claim I shall briefly review some important differences between Pancode control constructs and the set of control constructs proposed by Kovats Extract: Pancode control constructs Pancode control constructs Since it was first described [2], Pancode has been augmented with so-called panstack labels. It has also been refined in other respects. A revised formal syntax is presented below. The undefined symbols used in this specification of Pancode syntax may be divided into four goups. (a) (b) { and }, two explicit brackets surrounding panstacks regarded as pan units; and (c) do and done, two brackets enclosing panstack units, optionally used to improve Pancode readability. (The brackets |