MADCAP VI(ID:2763/mad010)Places
Related languages
References: MoT~RTs, JAMES B.' JR.; WET,LS, MARK B. 24,909 The specification of program flow in MADCAP 6. [ in Proc. ACM 1972 A~lnual Conf., ACM, New York, 755-762. See main entry CR 13, 12 (Dec. 1972), Rev. 24,148. ] This is a compact and well-written descriptive paper on the control structures available in the MADCAP 6 language. The scope of the paper is actually somewhat broader since it also deals with the specification of sets, sequences, matrices, and to some extent, trees. There are many examples which breathe life into the syntactic forms offered by the language. The "goto-less" issue is resolved by pointing out that MADCAP 6 eliminates references to programmer-defined labels (you can't define any labels), but that gotos in the form of "controlled jumps" are permitted. Controlled jumps are used to exit from recursive expressions ("nestexit") or to implement co-routining ("suspend"). >MADCAP 6 is an expression language in the sense that every statement in the language is evaluative and produces a value (which may or may not be assigned to a variable). "Deferred evaluation" is used to form subroutines or functions and since expression variables are explicitly permitted, it is possible to build an expression at execution time and then force its evaluation (notions taken from LISP, EUT,ER, and BT ISS). Very general iterative structures are permitted in the language and their existence allows the language to eliminate programmer-defined labels. These iterative forms, combined with set, sequence, or matrix notations, permit an astonishing brevity in the expression of otherwise hard to generate sequences. For example: if N = {j:0 ~ j < n} and p = (REAL: 0 ~ j < n) then the expression {treewalk 0 ~ ~ < n with node: forp; ~ N ~ Uo evaluates to the set of permutations of the integers 0, 1, . .. n -- 1X. The authors mention the fact that MADCAP' S regular structure (without programmer-denned labels) permits vastly simplified program flow analysis, but they do not elaborate. This reviewer hopes the authors will report their success in this direction, and perhaps also discuss how efficiently the compiler for the language can realize the complex computations which are so easily expressed. V. G. Cerf, LOS Angeles, Calif. in ACM Computing Reviews 13(05) May 1972 view details in ACM Computing Reviews 13(05) May 1972 view details in Courant Symposium on High Level Level Languages, Computer Science Department of the Courant Institute of Mathematical Sciences, May 22, 1972 view details in [ACM] Proceedings of the 1972 Annual Conference of the ACM view details in Computers & Automation 21(6B), 30 Aug 1972 view details in International Journal of Computing and Information Science 1(3) September 1972 view details Madcap 6 allows a generalized use of indentation: an indentation level and a parenthesis level are entirely equivalent. Since Madcap is an "expression language" and parentheses are used to group expressions into compound expressions as well as for normal arithmetic grouping [Morris and Wells, 1972], the programmer has the capability of displaying his programs in a very readable form without extraneous parentheses pairs. in Proceedings of the SIGPLAN symposium on Two-dimensional man-machine communication 1972 , Los Alamos, New Mexico, United States view details The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one. There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages. The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM. Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) . It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers. The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA). As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found. It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel. We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work. Graz / Austria, May, 1973 in Proceedings of the SIGPLAN symposium on Two-dimensional man-machine communication 1972 , Los Alamos, New Mexico, United States view details in [AFIPS] Proceedings of the 1977 AFIPS National Computer Conference Dallas, Texas, June 13-16, 1977 view details This paper discusses the function data type in the MADCAP programming language. The basic idea of such a data type is that "one may have variables of type function which assume different specific procedures as their value within their scope" (p. 389). As the author states, "The function data type concept appears in programming languages as early as LISP and EULER and is one of the advanced characteristics of ALGOL 68. It also appears unimplemented in the work of Burge and, in a somewhat different form using sets, in SETL" (p. 394). Several example program fragments are given which are somewhat difficult to follow for the non-MADCAPer. Much of the power and interest of these examples, such as easily written coroutines and stream functions, seems to come from the interaction of the function data type with the notion of activation record retention, which provides a mechanism such as the own-variable of ALGOL 60 or the initiation section of SIMULA 67 classes. If it is indeed true that "This concept [of function data types] has not received the attention befitting such an important unifying idea" (p. 394), this paper should contribute to spreading it. S. C. Shapiro, Amherst, N. Y. in ACM Computing Reviews 20(10) October 1979 view details |