MDL(ID:556/mdl001)LISP with data types and arraysfor More Data structures than Lisp (originally "Muddle"). C. Reeve, C. Hewitt & G. Sussman, Dynamic Modeling Group, MIT ca. 1971. Intended as a successor to Lisp, and a possible base for Planner-70. Basically LISP 1.5 with data types and arrays. Many of its features were advanced at the time (I/O, interrupt handling and coroutining), and were incorporated into later LISP dialects ("optional", "rest" and "aux" markers). In the mid 80's there was an effort to use bytecoding to make the language portable. CLU was first implemented in MDL. Infocom wrote Zork in MDL, and used it as the basis for the ZIL interpreter. Implementations exist for ITS, TOPS-20, BSD 4.3, Apollo Domain, SunOS and A/UX. Singled out by Licklider as the best candidate for the "hieroglyph-embedded" superlanguage of the future Structures: Related languages
References: in Computers & Automation 21(6B), 30 Aug 1972 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 Computers & Automation 21(6B), 30 Aug 1972 view details in Computers & Automation 21(6B), 30 Aug 1972 view details graphics, schematic and p i c t o r i a l . It considers briefly the trends of the technology and of the market, what the uses and who the users of user-oriented interactive computer graphics will be, and who will do the orienting of the technology toward the users. Then it examines: the concept of stepwise learnability; abstracting graphics functions from graphics applications; the idea of 'dynamic hieroglyphs'; graphics projected onto the r~e~ina; graphics embedded in LISP- and APL-like languages; knowledge based graphics; gr~aphic input devices; highly realistic graphics; computer-based arts and crafts; and some possible side effects of advanced applications of computers and graphics. Extract: Graphics Embedded in LISP and APL-Like Languages Graphics Embedded in LISP and APL-Like Languages Graphics has dominated most of the computer systems (such as systems for computer aided design and systems for the layout of LSI chips) that have made extensive use of interactive graphics, and the languages through which users have interacted with such systems have been primarily graphical languages. The languages in which such systems have been implemented, however, have usually been ordinary programming languages with little or no graphics capability of their own. It seems to me that there is an important middle ground, a place for systems that employ both graphical and alphanumeric input and output and that are operated or controlled through mixed media. It seems to me, also, that there is a need for languages that can serve both as programming and interaction languages and that incorporate the essential graphic forms and graphics operations along with the data structures, control structures, and basic operations required in programming systems and in interacting with systems that have been programmed. My favorite candidate language for the role just described is a derivative of LISP called "MDL" ("More Data-structures than Lisp"). But instead of pushing it, particularly, I want to point in the general direction of LISP and APL, languages that have implementations with both interpreters and compilers, the interpreters being in fact complete programming systems with built in libraries, documentation subsystems, debugging aids, and so on -- and the compilers being already reasonably efficient in some instances and in principle very amenable to high optimization. I think that some characteristics of LISP and APL are of the essence of user orientation, and I think that interactive computer graphics can correct some of the characteristics that are not. Some of the good features of LISP are the simplicity of its data and control structures, the essential modularity of LISP programs (functions), the fact that LISP programs are processible as data by other LISP programs, and the fact that a single program can include both interpreted and compiled parts. Some of the good features of APL are its abundance of array operators and the terseness with which complex procedures can be expressed. A few bad features should be acknowledged: LISP has too many parentheses and too many terms that are not properly selfexplanatory, and APL reads backwards, but graphical representation could cure those ills. What I advocate, then, is a graphics-augmented LISP-like or APL-like language that can be used both to program and to operate interactive graphics systems. For nonprogrammer users, some of the more sophisticated parts of the language would ordinarily be held back, but essentially there would be a single, uniform language for graphics and nongraphics, for programming and operation. The main consideration that forces me to qualify my claims for the value of such a language is that both LISP and APL complications require much further development before they can provide the efficient code required in the final stages of system development. However, as Bruce Daniels is arguing very convincingly [3], the greatest optimization can be achieved with the highest-level language, and the future therefore looks good for efficiently compiled code from such a language as I am advocating. in Computers & Automation 21(6B), 30 Aug 1972 view details in Computers & Automation 21(6B), 30 Aug 1972 view details in Computers & Automation 21(6B), 30 Aug 1972 view details |