MIRFAC(ID:440/mir005)2dimensional maths compilerfor Mathematics in Recognizable Form Automatically Compiled Gawlik, RMRE 1963 2dimensional maths compiler system developed at the RMRE to enable intuitive mathematical programming for mathematicians. One of the languages to receive an ill-flavoured and ill-considered rebuke from Dijkstra (who liked it his way or no way and who was of the opinion that an ad hoc assemblage of mathematical notation put together by a committee of computer enthusiasts was superior to 4,000 years of mathematical intellectual endeavour. In this he was wrong.). Places
People: Samples: References: The name stands for Mathematics in Recognizable Form Automatically Compiled, and thus constitutes in itself an announcement of the aims and purposes of the system. The chief features of the system, which is intended for the solution of scientific problems, are the presentation of mathematical formulas entirely in standard textbook notation. The use of plain English for organizational instructions, automatic error diagnosis indicating the actual location of the error in the uncompiled program, and an attempt to minimize that fragmentation of the original problem statement which is a normal feature of programming systems. MIRFAC has been developed to satisfy the basic criterion that its problem statements should be intelligible to non-programmers, with the double aim that the user'should not be required to learn any language that he does not already know and that the problem statement can be checked for correctness by somebody who understands the problem but who may know nothing of programming. If an average program written either in machine language or in most compiler languages is examined in the light of these considerations, it becomes evident that there are three aspects which call for treatment. They are Dear Editor, Recently H.J. Gawlik [1] has published an article on project MIRFAC: A Compiler Base on Standard Mathematical Notation and Plain English. Its author is aware of earlier projects along analogous lines (MADCAP and COLASL [2]). When I heard of these earlier projects I was filled with some amazement for what they aimed to seemed to me hardly a sensible thing to do. I did not raise my voice then, convinced and trusting that people would discover this for themselves in a very short time. Now, two and a half years later I am faced with the fact that the movement has not died its natural death as I had supposed it would do. This discovery has cause me some disappointment and I can only regret my earlier silence on the subject. The justification for the project MIRFAC seems the opinion that what is right for communication from man to man should also be right for communication from man to machine. (This is the only interpretation which allows me to attach a meaning to Gawlik's statement "that a compiler should aim not merely to simplify programming, but to abolish it.") But this opinion should not pass unchallenged! If we instruct an "intelligent" person to do something for us, we can permit ourselves all kind of sloppiness, inaccuracies, incompleteness, contradictions etc., appealing to his understanding and common sense: he is not expected to perform literally the nonsense he is ordered to do, he is expected to do what we intended to order him. And a human servant is therefore useful by virtue of his "disobedience". This may be of some convenience for the master who dislikes to express himself clearly; the price paid is the non-negligible risk that the servant performs, on his own account, something completely unintended. If, however, we instruct a machine to do something we should be aware of the fact that for the first time in the history of Mankind we have a servant to our disposal who really does what he has been told to do. In man-computer communication there is not only a need to be unusually precise and unambiguous, there is, at last, also a point in being so, if at least we wish to obtain the full benefits of the powerful obedient mechanical servant. Efforts aimed to conceal this new need for preciseness -for the supposed benefit of the user- will in fact be harmful: for at the same time they will conceal the equally new possibilities of automatic computing, of having intricate processes under complete control. I go on quoting Mr. Gawlik: "... MIRFAC has been developed to satisfy the basic criterion that its problem statements should be intelligible to non-programmers, with the double aim that the user should not be required to learn any language that he does not already know and that the problem statement can be checked for correctness by somebody who understands the problem but who may know nothing of programming." I do not see the point of Mr. Gawlik's "basic criterion". Elsewhere (see [3]) I have warned against the "...tendency to design programming languages so that they are easily readable for a semi-professional, semi-interested reader. (Symptoms of this tendency are languages the vocabulary of which includes a wild variety of English words to be used in a nearly normal sense, and some translators that even allow a steadily expanding list of synonyms and misspellings for these words. Particularly, languages designed under commercial pressure have suffered seriously from this tendency.) It looks so attractive: "Everybody can understand it immediately." But giving a plausible semantic interpretation to a text which one assumes to be correct and meaningful, is one thing; writing down such a text[.....]expressing exactly what one wishes to say, may be quite a different matter!" On comparable grounds, John McCarthy calls "COBOL .. a step up a blind alley on account of its orientation towards English which is not well suited to the formal description of procedures" [4]. Furthermore, to set Mr. Gawlik's double aim is fooling oneself. Standard mathematical notation has been designed to describe relations and now we have to define processes. Plain English has grown out of a need of interhuman communication, to be vague and ambiguous, to tell jokes and to sing nursery rhymes, but is obviously unfit to express what has to be expressed now. One can borrow mathematical notations, one can borrow English words, but completely new semantics must be attached to them and despite its superficial similarity one creates a new language. And I think the similarity more misleading than clarifying. This fear is confirmed by Mr. Gawlik's second aim, viz. "that the problem statement can be checked for correctness by somebody who understands the problem but who may know nothing of programming." Of course he can check it, but the crucial point is whether he will find the errors! And of course he will not find them: for in human communication EWD68 - 4 one is constantly trained to try to understand the others intentions and not to notice the nonsense. The corrector who understands the problem but knows nothing of programming, will be misled by the familiarity of the characters and the words and he will, in all probability, be satisfied if he recognizes the problem. I am all in favor of clear and convenient Algorithmic Languages, but, please, let them honestly be so: to disguise them in clothes which have been tailored to other purposes can only increase the confusion. E.W. Dijkstra Department of Mathematics Technological University Postbox 513 EINDHOVEN The Netherlands References: Gawlik, H.J. MIRFAC: A Compiler Based on Standard Mathematical Notation and Plain English. Comm. ACM 6, 9 (Sep.1963). Wells, Mark B. MADCAP: A Scientific Compiler is a Displayed Formula Textbook Language. Comm. ACM 4, 1 (Jan. 1961). Dijkstra E.W. On the Design of Machine Independent Programming Languages. In Goodman, R. (Editor): Annual Review in Automatic Programming, Vol. III Pergamon Press, 1961. McCarthy, John. A Basis for a Mathematical Theory of Computation, Preliminary Report. Western Joist Computer Conference, 1961. External link: Online copy at Dijkstra Archive in [ACM] CACM 7(03) March 1964 view details Dear Editor: Since Professor Dijkstra [1] has misunderstood the aims of MIRFAC, I should like to try to clarify them. Some time ago, I found myself in charge of a computer which was not being used by many of the people to whom it could be useful because they lacked either the time or the ability to learn how to express their problems in our very simple machine language. It was clear to me that the situation would have been unchanged by the introduction, for instance, of ALGOL; and I may add that I believe this state of affairs to be a common one. The idea of MIRFAC thus arose from an attempt to go as far as possible to meet the needs of a not inconsiderable body of potential users. It was in the sense that I spoke of an aim of evolving a compiler to "abolish programming," and I should remind Professor Dijkstra that I myself described this as a counsel of perfection. The reasons for the first part of my "basic criterion" (that the user should not be required to learn any language that he does not already know) should thus be clear enough. With regard to the second part, Professor Dijkstra has committed himself to the sort of forthrightly dogmatic statement which is very easy to refute. On the proposition that a MIRFAC statement can be examined for errors by somebody who understands the mathematics but is not a programmer, he says "Of course such a person can check it, but the crucial point is whether he will find the errors! Of course he will not find them . . . . " But of course he will, in very many cases for which one simple example will suffice. A programmer, dealing with a problem containing a definite integral for a Bessel function, makes an error in stating the form of the integrand. This could be seen at a glance by any mathematician if the statement were written in MmFAC, and it is a fact that most errors made in programming consist of blunders at this level rather than of esoteric errors in numerical analysis. In my view, the pragmatic approach adopted by Wells and myself is more realistic (and, if I may say so, the more modest) than Professor Dijkstra's attempt to deduce Omega from our imperfect knowledge of Alpha. No compiler yet devised will deal with all problems, but there are circumstances in which it is more fruitful to have a compiler which makes many problems very easy to handle rather than one which makes a larger range of problems moderately difficult. This is my situation, and it is this which MmFAC aims to do. in [ACM] CACM 7(10) October 1964 view details in [ACM] CACM 7(10) October 1964 view details The basic instructions are synthetic enough to make a program understandable at first glance, but it seems that the study of the language (for the writer, not for the reader) must be as difficult as for other existing languages of the same power of expression. A pilot compiler is in operation on the computer AMOS. in ACM Computing Reviews 5(01) January-February 1964 view details At the risk of belaboring the point, I would like to enter into the discussion which has been generated by publication of the article on MIRFAC [1]. Before proceeding, I admit to a programmer's bias. First, I agree with Mr. Gawlik: something must be done to permit more widespread communication with computers by persons not trained as programmers. Second, I agree with Professor Dijkstra: English is, because of its inherent ambiguity, eminently unsuited as the means of communication [2]. It seems that Mr. Gawlik has missed the point. He ignores the discussion of the suitability of English, and he denies Professor Dijkstra's point that errors will not be uncovered by someone ignorant of programming techniques. In refuting the latter point, Mr. Gawlik uses the example of an erroneous statement by the programmer of the integrand of a Bessel function [3]. This, I am sure, is not the sort of error to which the professor referred. Errors of this type are discovered and corrected easily and quickly in the early stages of program debugging, and cause minimal time loss. It is the rather more subtle errors in thinking and logic--those which characterize everyday speech--which are so difficult to find. Any programmer can relate tales of the havoc wrought by a single erroneous bit in a program containing literally millions of correct ones. While I do not presume to insist that one must be trained as a programmer in order to communicate effectively with a computer, it is nay strong belief that one must understand the nature of the beast--and this includes a realization of the necessity for precise thinking. There is more to programming than the ability to code a mathematical expression. REFERENCES : 1. GAWLIK, lcI. J. MIRFAC: a compiler based on standard mathematical notation and plain English. Comm. ACM 6, 9 (Sept. 1963), 545-547. 2. DIJKSTRA, E.W. Some comments on the aims of MIRFAC. Comm. ACM 3, 7 (Mar. 1964), 190. 3. GAWLIK, H. J. MIRFAC: A reply to :Professor Dijkstra. Comm. ACM 10, 7 (Oct. 1964), 571. JOHN M. SCOFIELD IBM Corporation White Sands M in [ACM] CACM 7(12) December 1964 view details in [ACM] CACM 7(06) June 1964 view details in [ACM] CACM 9(08) August 1966 view details in Proceedings of the IBM scientific computing symposium on digital simulation of continuous systems 1965 view details in Proceedings of the IBM scientific computing symposium on digital simulation of continuous systems 1965 view details in Proceedings of the IBM scientific computing symposium on digital simulation of continuous systems 1965 view details in Proceedings of the IBM scientific computing symposium on digital simulation of continuous systems 1965 view details [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know. Register of the 74 computer companies; Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented; Sequence of the manufacturing firms after the number of used programming languages.] in Proceedings of the IBM scientific computing symposium on digital simulation of continuous systems 1965 view details in Proceedings of the SIGPLAN symposium on Two-dimensional man-machine communication 1972 , Los Alamos, New Mexico, United States view details Mirfac is a two-dimensional typewriter based language developed in England [Gawlik, 1972; Sammet, 1969]. It makes use only of simple subscripting and exponentiation. While it is considerably less sophisticated than Madcap or Colasl, it does illustrate the tremendous gain in notational clarity possible with only minimal use of two dimensions. 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 A language called MIRFAC was developed in England by H. J. Gawlik. It used the Dura Mach 10 machine for I/O. It also used paper tape and allowed subscripts and superscripts. in Annals of the History of Computing, Spring 1987 view details |