ON THE DESIGN OF PROGRAMMING LANGUAGES* N. WIRTH by transparence and clarity of its f Utnoet concieen Language designer's probless and dilemns In order to prevent misunderstanding or even dleappointment, I should like to warn the reader not to interpret this title as en announcement of 'e general critique of com only used languages. Although this might be f vary entertaining subject, probably ell thet can be seid about it hae been said and heard by those willing to listen. There ie Ro reason to repeat it now. Neither do T Intend to present an objective sssesament of ‘the generel situation in the development of Programing languages, the technical trends, the conmercial influences, and the psychology of their users. The activities in this field were enormous over the past years, and it Mould’ be presumptuous to believe that Single person could present # comprehensive, objective picture. Moreaver, many aspects have bean aptly reviewed and commented el: where (1-3) 1 hold Like to convey 2 view of development of design attitudes, of the shirt of enphasie in design goals over the past decade. Also, 1 will try to provige Some inaight into’ the multitude of probleas sepecte, and demands that the designer of « Language is facing, and to woo gently for Fecogniticn of the difficulties of this profession. Let me start by recalling sone Of my own Teminiscences of incidents that Caused me to and up in this role of language Sesigner. ‘AN EXCURSION INTO "HISTORY" in computers had been avakene: fan engineering student in the Tate 1950s; 1 was fascinated on the one hand by simplicity ana inherent reliability of the baaic building blocks, the digital Eircuite, and on the other hand by the tounding variety of effacte that could be obtained by combining many of them in differ fent ways. Moreover, these combinations could be varied not by extensive and cumbersome Use of the soldering ion, but by merely Composing ingenious sequences of hexadecimal Sigite placed ons magnetic drum. Ae the jeneral task of an engineer is the improve- want of hie technical gadgate, I perceived ‘thet computers vei ‘*Reprinted from Proc. IFIP Congress 74, 386-393, North: Holland, Amsterdam, North-Holland Publishing Company. The author is with the Institut fur Informatil ‘Technische Hochschule, Zurich, Switzerland. Eig, past experinents in the design of programming langvag snte the view thet # Language should be simple, and that simplicity must be achieved tures and by @ reguler structure, rather than by The poper contain an overview of the ‘and unwanted generality and ends with sone Pinte drewn from past It anginsering activities, and felt that there “ae ample room for further improvement. This fesesament turned out to be correct up to the present day. But how was progress to be achieved? One way was by enhancing the reo. Liability ond sffectivenees of their elec= trenie components, The other ~ havily defin path = seemed to be to make computers more Eanvenigntly ugable, to make then less of an exclusive domain of the highly trained Specialist. This was the situstion when I entered gredu= fate school at Berkeley: In one room there Stood s huge prototype of @ computer with a bewildering nurber of wires and tubes. In @ much smaller room nearby there were a few Such specialists, talking about a "language" and e "translater". Luckily for me, a student Relping to bring the big monster of « com puter into operation didn't report tee enthusiastically about that project, and T perceived the feeling that the future of Computer herdware design did not lie in a University department anyway. Hence, T decided to explore the other olley, although that group was surrounded by skepticism, as word passed that sone of these people did either xeow Ohm's lawner Maxwell's equations, The new and fascinating project under the direction of H.D, Muskey consisted in adding facilities to the programming language NELIAC by extending the trensiator program. This, program was, remarkably, coded in the very Language that it was compiling and, in retzo= spect, quite edvanced for ite time (4). Indeed, the fascination of the project originated much more from the of Sdventurovsness than from the setisfaction of achieved pexfection. For, although pro- gramming in NELIAC proved to be considerably more convenient than exercises in the Cryptology of hexadecimal codes, the room for still further improvements continued to appeer unlimited, Looking at it from the Gistence, that compiler wae a horror; the excitement coma precisely from having insight into e machinesy thet nobody understood folly, There wes the distinet eit of sorcery, Then Algo: 60 appeared in the Literature and = after the difficulties of leering the new ayntactic fornalion were mastered — began to Provide sone relief ron the oppressive feeling that there was no way to bring order into large languages and compilers. Yet even then, the task of constructing en Algal24 Programming Languages: History and Good Design compiler generating acceptably good code fppeared enormous. The more the Algol com Daler project neared completion, the more Vanished order end clarity of purpose. It ‘then that [clearly felt the distinct er simpler tasks before tackling big” ones, and that we need to be equipped with uch’ batter Linguistic and mental tools. But ‘pperently "useful" languages had to be big. SIMPLICITY IN GENERALITY In this eituation, Av van Wijngaarden ap peered Like # prophet with hie idee of Generalised Algol (5). His point was that Languages were not only too complex, but due to this very complexity aleo too restrictive. "io order that « Lenguage be powerful and elegant it should not contain sary concepts Gnd it shoule not be defined with many worde! The new trend was to discover the fundamental concepts of algerithes, to extract them from their various incarnations in different Language features, end to present then ino pure, distilled form, frae from arbitrary land reatrictive rules of applicability. The following short exemple may illustrate the principle. In Algol 60, the concept of a subprogram eppears in two featur dee Clered procedure, and as rane paraneter to Drocedures. The passing of « parameter is Fealisad a0 an assignment of an object (the actual pareneter) to a variable (the formal Deraneter). A simplification and concurrent {nerease in power end flexibility of Algal can therefore be obtained by unifying the notions of procedure and paraneter, by Letting then become objects that can be ase signed to variables Like numbers or logical Values, Let such an object ba denoted by the progrem text enclosed by quote marke; the Correspondence between constructs of Algol 60 and the gererelised notation exe shown by the following table: Atgot 60 Generalisation “catatenent? son" ) a(¢cexpre The gain in sinplicity of language is obvious and the resulting gain in flexibility ie ‘Fiking. For example, it ie now possible to Steign different subroutines to # variable ft different timen, or evan to replace a function subroutine by « constant! We are suddantly offered the power so far reserved fo the assembly language coder letting his program modify some of its own instructions. Implementation of such fer reaching general- Asations were on open challenge. I decided te investigate, whether these concepts could be condensed inte a minimal Language and compiler, #2 « language without compiler Seemed ta be of marginal value to me. This effort resulted in my firet programaing (5). Te wane success jarel ways, certainly if measured by fF Of subsequent implementations on variety of computer. The lengua Mas accepted as an intellectual challeng flexible and powerful vehicle. Ite simplicity snd compactnons made it an ideal implemen tation exerciee for many prospective compiler engineare. [te grestest value, however, Ley in revealing how simplicity should ngt be under too and achieved. The premise that = language should not be burdened by (syntactical) rules thet define meaningful texte (5) led tos language where it won difficult and almost impossible to detect © flaw in the logic of @ program. It fed to what I like to call high-level Turing machine. Making mistakes is human (particularly in programming), and we need all the help possible to avoid committing them. But how can one expect @ language to eid in avoiding mintaken, if it is even Incapable of assisting in their detection. The Lesson is, then, that if we try to achieve simplicity through generality of Language we may end up with programs that through their very concisenase and lack of redundancy elude cur linited intellectual grasp. Tt iss mistake to conaider the prime Eheractariatic of MgheLevel lenguages to b that they allow to express programs merely in their shortest possible form and in terme of Letters, words, and mathematical symbole "of coded numbers. Instead, the Language is to provide a framework of abstractions and structures thet are appro priately adapted to our mental habits, Cope Bilitios, and linitations, The "dlatance” oF these abstractions from the actual realis~ ation in terms of # computer is an esteblished jure for the "height" of » language's level. The key, then, Lies not so much in minimising the number of basic features of a languages but rather in kesping the included facilities simple to understand in all their consequenci Of usage and free from unexpected interactions whan they are combined. A farm aust be found for these facilities which is convenient to Femenber and intuitively clear tos progreme mer, and which acts as a natural guidance in the formulation of his ideas, (he Lenguage should not be burdened with syntactice® rules, it must be upported by then, They must there: fore be purposeful, and prohibit the canatruce tion of anbiguitiea It isa good ides to employ adequate, concise key words, and to farbid that they can be used in any ather way. Prolixity is to be avoided, as it Introduces @ wrong kind af redundancy. LEVELS OF ABSTRACTIONS One of the most crucial ateps in the design of @ language is the choice of the abetracy ian upon which progr con be selected only if the designer h clesr picture of the purpose of his Language, of the aren of its intended applications But 11 too often that purpose is not neatly specified and includes so many diverse japects thet a designer ie given only inede equate guidance from prospective users. But at leant he should restrict his selection to et Sone sense compatible with should Like to offer thr topic. t examples to thieA1gol 60 has chosen # well-defined set of abstract objects of computstion: numbers and logical velues, replacing bite and words uted on a lower lavel. The operations thet are sppliceble to than are governed by Bathametical Lave and axioms which can be Understood without referring to the number's Fepresentation in terms of bite and words. In the reelm of control structures, the language: Introduces the operations of salectiv. execution and repetition in the fore of But their form war not sufficiently flexible = 9,9. rep= stition is intimately coupled with » variable Progressing through an arithmetic series of Values, and selection i¢ only provided snong To provide the user with 2 not covered by these control structures, the designers of Algol Fesorted to borrowing the universally applicable jump order from the lower Level of machine coding. The gote statement is but a Polished form of the jump. Thie may not seem too serious in itealf. But consider thet now the programmer is able to Use these facilities combined. The following exemple — which an honest Algol progranmer Will refrain from using, or otherwise will at Teast get bed conscience = shows the point. for i t= 1 stop 1 until 100 do begin Sif p Shen goto tang The whole purpore of the for clause is to proclanate to the reader: "the qualified Statement is going to be executed once for every i= 1,2,3,-4,100%. The jump, however, ‘Sneekily Cause thie promiae to be broken! Whereas jumping out of a substructure may be considered to be # matter of morale only, Jumping back into « structure even ralees "al problens. They require the estab= nt of protective rules and restrictions which are afflicted by the etigne of inpro- Visation and afterthought. They complicate the language by burdening ite definition, ite comprehension, and its compiler. The second exemple concerns the notion of pointere or zeferences in high-level Tengueges. When programming in essembly code, probably the most powerful pitfall is the possibility to compute the address of Storage cell that is to be changed, The effective address may range aver the entire Store (and even be that of the instruction Steelf). A very essential feature of highy Level lenguages ie that they permit « conceptual dissection of the atore into dis~ joint perte by declaring distinct variabli The programe may then rely on the a that every assignment affacts only that variable which explicitly appears to the Left of the asoignnent operator in hie program. Me fnay then focus hie attention to the change of ‘that single variable, whereas in machine coding he elways hes = in principle ~ to Conaicer the entire store as the state of the computation. The necessary prerequisite for Being able to think in terms of safely in pendent variable ie of courae the condition that no part of the stor jue more, than a single name. Wherees, thie highly desirable property ie sacrificed in Fortran by the use of the “equivalence” statement, (On The Design of Programming Languages Aigol loses it through ite generality of pareneter mechenien and rule of scope. Even if the sensible rule is observed that = procedura’s parameters nust denote disjoint Variables, one and the same variable may be referred to under more than one name, aa shown, by the following example. ‘bapin integer 0 ‘oxocedure S(x): inteaer x: bagin ete eet; x te wiz Sta): wrdteta) This deaign partly stems from the failure to jeparate the roles of textual abbreviation and of parenetric program decomposition, both projected onto the same facility of the pro- edure. For mere textual abbreviations, one ight be more willing to refrain from the use Of parameters: in the case of program decompo= ition, communication with the environment tricted to explicit the notion of simplicity and. frugality was rather counterproduetive Shen viewed from the point of programming ter (x), In the spirit of gener= slisation it appeared ae highly logical te admit the address into the society of com Puteble objects, The address of a variable a now called a reference = was thus introduced in the language Euler and denoted by Te can ned to any other variable, x. The variables is then openly available Under two names, ® end x.y and there ia no Lisit to the number of further names thet can be given to. os This experiment of reopening Pandora's box of storage addresses in Euler provided a cleer warning of their undesir~ ability, but didn’t prevent the introduction Of references into Algol 68 in their fullest flexibility, The concept of date type provides addes security insofar ase compiler mey check apeinet inedvertant use of incompatiole Veriables in, for instance, sssignments. This In iteelf, introducing another restsiction uninown at the level of machine code, where avery cell cen be loaded with s copy of every Other cell's content. The idea of winplicity through gonerelity again Led to the eliaine ation of restrictive type rules, and of the data type in general. It wes edoptad by « fanity of languages designed to fill th apparent gap between high-level languages and Stnembly code, which ere now Known as aechine Grlented higher order languages (Hohols]. They permit the construction of expressions with Rintyped™ operands and the application Of both azitheetic and Logical operations on tha sane variables. The result of progrema weltten in auch Languages can only be under ‘Stood through knowledge of the particular Storage Fepronentation of dats in terme of Bite ang worde, Although effects may be produced that turn aut to be the Geised ones, they force the progranner to Leave the Feaim of abstsection that a Lenguege ie pre Banding to offer him. 2s26 Programming Languages: History and Good Design So much for the third exemple of trans= on of levels of abstraction in TWE THREE EXAMPLES REVISITED 1 do not deny thet there are situations in programming which call for facilities not present in Algol-Like Languages, But they should not be mat by compromising on the level of abstraction. The anesky reintroduce tion of patently pernicious facilities from the ara of machine coding is not an accepteble solution, In order to entablish remedies, ve must discover the true reasons far the prom QFenaere wish of auch facilities, The Language designer must not ask “what do you nev, but rather *how does your problem arise?® For, the anaver to the firet question wil inevitably be "Jump fand addres To convey an idea of the apirit in which « designer ought to approach such problens, I Mill "tkateh possible solutions to the thret mentioned cases, The prt Features 30 ‘ARE provide the full flexibility inherent in Jumps, type-less operends, and free addr manipulation. But this is precisel ‘they still impose certain Festrictions of usage, and help maintain « programming discipline. In particular, they do not compromise the language's high Level of abstraction; they do not introduce notions ‘hich can be explained only in terme of an Underlying sachin In the case of the for statement, what the really needs is not necessarily « but merely « more flexible way to Tetmination of @ repetition. The expres Solution consiate in providing » ainpler form Of repatitive statement whose termination nd on a vari moving through Tha important point is that now the total effect of the composite statement can be Gaduced solely from the properties of the Fepaated companent. The pertinent deduction role can be formeliy expressed, for instance in Moata's formalien (7). If P and Q denote any assertions on the state of the computation, then PIS|Q neane: if P holds before the execution of Sy and thie execution terminates, then "holds after termination. The two deduction rules govern= Ang the above statement forme ere (8)1 pas Isl. Plubibe Bde S] Paw Pisia , ~waatsia Plxapeat 5 until 2} GAB Another aituation requiring the u in Algol arises whan one etatement hi selected among many, A feature invented by. Hoare in exactly the same spirit, thet not only replaces # jump and a switch declaretion, but expresues the selection of one cese among many in a structured, orderly way, ie the Cave statement (5). As for the second ‘only in « considerably tamed form. Security in pointer handling can be improved drastically by the following 1, Every pointer variable is allowed to point to objecte of a aingle type anly (or to none); it in eaid to be bound to thet ty; This rule allows to maintain « compiler’ capability of full type checking 2, Pointers may only refer to variables that have no explicit name declared in the prow gram, that isy they point exclusively to anonymous variables allocated when needed during execution. This rule protects, the programser from the dangers arising when Variables are acceseible under different 3. The programmer must explicitly specify whether he refers to « pointer itself or to the object to which the pointer refers (no automatic "eoercion®). thie rule helps to avoid ambiguous constructs and compli cated default conventions Liable to aie: Understanding. deat with typ. fare sore aif ficult to pinpoint. The most frequent one is probably the necessity to pack different kinds of date densely into e single word, which the available Language always regerds fs an indivisible entity. For instance, we Might have to pack « triple r- sey a file deucriptor - consisting of @ name x of 6 character, a S-bit status information # » fond @ 2-digit length count. (The 5 statue bits may, for example, indicate « tape's loadpoint, end of tape, and end of record positions, ite density mode and parity check atatua.) A pictorial representation might be a Te] and a common way to denote the value of such 4 triple ie es an octel (or hexadecimal) num ber, because the word is available in the Language under the misnomer "integer". In or der to determine this number, the programmer must forget hie original abstractions end Perform the binary encoding *by hand*. If he is lucky, he obteins «[Recoer 36 F = 01020304050642314 or r= 042004146809, « Part of the true information is arithmetic in ite nature (n), another is logical (a), and a third alphabetic (x). Nance, ell kindsapplicable. But this ie Af the operend ia not reatrice ted by ite cheracterisation through an a sociated type. whet the. programmer really in thie case te ¢ date structuring facility relieving him from the tedious and errorprone Labor of dete encoding and pecking, Ae an (luetration, in the programing Pascal the triple r cen be directly fe structured variable, yielding the denae pecking indicated by the picture above (10). The fizet component of ria daclared to be an array of 6 characters, the second to be « set of statue indicators, and ‘the third a number in the range of D to 99. fume string = gackad azzaul[0..5] of che Indicator © (losdpoint, eof, cor pchk, nighdanaity) sak ++ nackad xanaid xt strings St gat of indicators mr Onn 3 and Assignments, instead of involving obscure arithmetic operations expressing shifts etc. are simply written ree tm TABCDEF'S Ela t= (loadpoint.highdenssty]: Fin ie 89) Each of the three components has # distinct name and # distinct type. Its proper usage Can be completely checked by compiler and program resder alike. Naturally, such = Structuring facility complicates « compiler Considerably, much depending on the quality of the underlying hardware azchitecture. It even increases the "volume" of @ langua but significantly, it dose not reduce ite conceptual simplicity. The proposed solutions to the three mentioned problem areas lis in introducing restrictive fe contrary to the spirit of ‘power through sinplicity® and "simplicity through generality". But they have already ‘to be wisely chosen precautions and have aided tremendously in practical pro— Granming. The edditional burden of type Checking by the compiler hes been much more than compensated by the amount of confidence gained in the final programe. And this is het good language design should mainly aim for. COMBINING FEATURES INTO A LANGUAGE A characterietic of # well-designed ia that in dows not imply any unexpected, hidden inefficiencies of inplewentetion. The eked record atructure shown above displays this property: « compiler has full. knowled Of the addrese of each such variable and of the position of the componente within « word. It'can therefore generate appropriate and efficient instructions for acc fand unpacking. The whole « Schone, however, innedietely vanishes, if; for example, we introduce s0mcalled dynamic azrays, thet ie, if ve allow information about the actual dimensions of an errey to (On The Design of Programming Languages 27 be withheld from the ci scan of the progr th Gnount of storage needed) ass consequence: dynamic allocation must be used involving indirect addressing, Thie not only imps: the efficiency of the c importantly = destroys the whole achene of storage economy. ler. The textual This de but one exenple for many thet could be Listed to show how the combination of two ‘and well=un A capable Language designer must not only be able to select appropriate features, but must lao be able to foresee ell effects of thelr Being used in combination. Naturally, one might suggest that « compiler be designed that efficient an dense code when the component aizes are know fond less effective code othervise. But this attitude leads to the optinising monster Compilers so well known for their bulkin and unrelisbility, Even more significant ie the consideration that # good language should not only aid the programmer in avoiding mintak idee of the complexity and effectiven the features it offers. However, if the ul of the same feature under only alightly different circumstances yields widely different factors of economy, then the Language clearly lacks thia highly desirable property. It is very important that the basic method of implementation of each feature can be explained independently from all other features ins manner sufficiently Precise to give the programmer 2 good timate of the conputationel effort involved, Some modern languages fail miserably when messured on this criterion, but that it must elso give him an oF Traneparance is particularly vitel with respect to stor technique, since ator frequent operation that any unenticipete hidden complexity can have disastrous ef of the performance on a whole program. In fact, I found that a Large number of programs perform poorly because of the language's tendency to hide "what is going on” with the minguided intention of "not bothering the programmer with details". Transparence of access mechanism can be achieved by neatly Categorising date structuring Faciiiti with respect to applicable sccess technique, This rule was taken ans guiding principle in tha design of the language Pascel, which offers the following structuring facilities: Arrays. Components are selected by computable index, Their offeet calculation must in general be deferred until exe- Cution time (using index registers if available). 2. Records. Componente are selected by # fixed selector nam ean therefore be evaluated entirely et compile time. Aa the compiler may retain their effects individually ine table, the Components are not restricted to be of the‘7% Programming Languages: History and Good Design 2. Sates Components are not individually selectable et all. Instead, the menber= hip operator ip ellowe to tast for their Presence or abeance, If the aize of {a auftictently amail, they can resented by their cheracteriatic function fitting into « single werd, 4, Fiten (aequencea). Since the Length of & yquenca may vary during program execution ‘dynemic allocetion mechanian i a But dt ie conaiderably simplified, beceu only sequential access ie peraitted through a”"eindow" displaying the component at the current position. Variables of thes fundamental structur either be declared explicitly, of they me Invoked dynamically, in the firet cose they ere known by their identifier, in the Letter thay must be accessed vie pointer. be Knowledge of these access cheracteristicn is Vital for the programmer, an it is indispene= Ible for the selection of date representation suitable for the algorithm. Ragrettably, the Current trend in language design seems to move in the opposite direction, namely to Obscure these diffarances. The common excuse ia that through the development of more suitable and more efficient hardware th Gifferences would gradually disappear. fact romaine, howaver, that supposedly more suitable hardware becomes phenomenally Complex. It is no longer economical to realis it directly in terms af electronic circuitry, and a new technique has therefore been Invented = microprogranming. The essence of this davelopaent. is thet complicated features become the standard with their weird complexity well disguised, and that the pro Grammer in denied the possibility to solve Aig teaks by simpler meane. He doesn't even haves possibility to measure the builtein inefficiencies through quantitative compariaons! LANGUAGE DESIGN 1S DECISION MAKING From the foregoing it may appear thet the secret of good Language design Lies in a few rules and a sound attitude, In pracitce, of igner is confronted with @ bewildering variety of demands from various agents ranging from theoreticians to prac= Utlonere, from novices to exparts, from revolutionaries ezying for innovations to Conservatives emphasising compatibility, Let mma lint « few of the most frequently ancoure Uered demands. = The Language must be any to use. ¥y to Learn and = It munt be safe from misinterpretation and iauee. = It must be extensible without change of existing featur = There must be a rigorous, mathematical definition, based on axioms and withatanding ‘the acrutiny of logicians. = The notation must Able with widely us 0 logics) etendarde, = The definition must be machine indeper convenient and compat= (and ometines not nt that ie without reference to a particular nachaniem, = The Language must allow to make efficient use of the facilities of the available computer. = The compiler must be able to generate efficient code end sconomise storage = The compiler must be fast and compacts it should be void of complex optimisation routines that are rarely used. = The definition aust be self-contained and complete, A reader must easily be able to Ldentity the feckliti ed for hie purpose. = The implementation must provide coady access to other facilities available on the Syeten, such ae program libraries and (therefore) subprograms written in different Lengueg = The Language and ite compiler must be adepteble to different environments vith different character sate and different operating ayeten facilities. iy = The compiler must be ensily portable to other computers. Almost all of it should be conceived without specific reliance on a Given order code and storage organisation, = Time and cost for developing compiler and documentation must be minimal. It is plain that several of these points are contradictory, but certainly not sil of them. The designer must decide where he wishes to place emphasis. It is nis task to find « Carefully Balanced compromise. In fact, the Feconciliation of conflicting demands by well chosen compronians is an essential part of every engineering prof ‘Language Gorign should therefore be regarded ae typical engineering discipline, It can be mastered only by experience, and experiance Le usually gained only after « few failures! The designer's task is even aggravated by the fact that the conflicting demands come from differant paople whom he is supposed to serve. Whatever he deciden, he should never axpact Unanimous approval. However, I do not wish to convey the ime lon that sytiefying one criterion must ily mean sacrificing snother. True progress appeara through the invention of facilition that cater to saverel seamingly contradictory sims. The thees examples mentioned before demonstrate thet auch Progress is indeed feasible. LANGUAGE DESIGN 1S COMPILER CONSTRUCTION In practice, » programming language is ae 900d ae ite compiler(e).the believe that it Should iret be deaigned entirely in the abetract realm of, say, a set of axioms oF fan official document, is equally minteken ae tha opinion that it must grow aut of = practical experinent of implementation before Being neatly documented. A aucceseful Language must grow out of claer ideas of denign goals and of attempts to define At in terme of abatract structures, and to implement it ons computer, oF Prefarrably even on several computers. Itfollows that experience in conpiler construc= tion is « prerequieite to successful language ‘denign courses have ind nto be regarded the spitome of the software craft. Unfor= tunately” they aze often strongly bissed touerd the eepect of ayntex enelysis, since sauch theoretical work hae been done in this Penetration of ‘oven datrinental- ‘misled many language designers to believe that the conplexity of @ lenguage syntax wan of no concern, since an appropriste parsing algorithm, if not already available Could readily be found for any construction introduced. But it is avident thet « language that in simple to parse for the compiler, is alse simple to parse for the human programmer, and that can only be an asset. Moraover, the Foal chellenge in compiling is not the Qetection of correct sententiol forms, but coping with ill-formed, erronagus programs, in’ dlagnosing the mistakes and in being able to protead in a sensible way. The really essentiol prerequisite for successful compiler construction ie experi~ ance in the development of large, complex programa. This includes maatery of techniques in structuring programe and date in general, ang in selecting methods for various tasks in particular, such as for scanning of text, Construction end search of aymbol tables, end composition of code sequences, One is inclined to wonder whare the training of so many compiler and language designers MALL Load, and whether it is justified. Here T ahould like to point out that « general appreciation of compiler principles will help the understanding of computer operations and promote the etate of the art of programming et large. But there is no reason to believe ‘that the growth rate of the populetion of programming Languages ie thareby going to Gacrasse. The emphasis in cou developments however, {8 gradually shifting from general purpose tovard application oriented lengueg Te Le precisely toward this trend that design courses should be directed: exposition of features and presentation of tachniques that are common to mot areas amenable to algor— ithmic solution. Such features are, for instance, the fundamental control concepts of quencing, conditioning, aelection, rep atition, and racuraion. They form e well ‘tablished basis from which # designer can proceed to fill the given framework with cific facilities oriented touerd his particular task and area of application (11). concLustoNs. I have tried to convey a picture of the + challenges, and ordeals facing « 4 id to draw sone Lessons in the design of » ‘and compilers. To con lessons On The Design of Programming Languages 29 > Kap in ming that # programming language ie of no use without an afficient, reliable Compiler and = claer, readable documentation. Thie should provide sufficient incentive to keep the language as simple as ever possible. = Do not equate simplicity with Lack of structure or Limitless generality, but tather with transparance, clerity of Purpose, and integrity of concepts TiAdhere to @ syntactic structure that can be ‘analysed by simple techniques such recursive descent with one-eynbol lookahead, This not only sides compiler, but also the programmer, and is vitel for successful diagnosis of errors. = Identify the basic abstractions on which the language is to be based. Try to define the language in terms of « mathematical formalism. This may help to detect hidden inconsistencies and to eliminate notions thet cannot be understood in terms of the Given abstractions. = Do not consider the establishnent of « formal definition as an end in itself. In perticular, the formal definition cannot be @ substitute for an informe presentation and for tutorial material, It is mostly en Bid to the designer but not a user's document, in which mathematical rigor will contribute to volume Out seldom serves the programmer's needa, fon how to. repr: computer's order code and store, Be aware of the consequences arising fram the comxistance of all the various features. They can sometimes be surprising and disastrous, = Do not hesitate to exclude certain featurs that prove to be incompatible and too costly in ters of implenantation. The fact thet other Languages include then is no guarente for their indiapenaability. + Obtain a skatch of the complete language before starting work on the compiler. jefrain from adopting highly controversial features: language changes are usually costly in time and effort even during development, and are virtually impossible after # conpiler's releate, if the language is suceeserul. = Design the Language such that most chacking ‘operations can be performed at compile tis and need not be deferred until execution. The concept of static data types of ia easentiol in this respect, and enhances both programming security ani system efficiency: bility for the design of (and poseible changes) confined toe single person, If implementation work in delegated, keep closely in touch with it, ‘and maka sure to obtain adequate feedback. ware of progranmere uho will quietly find solutions no matter what they coats hen the project is at ite en it, recognine that many improved, and do it ell30 Programming Languages: History and Good Design REFERENCES. a) (a al (a (s) (6) Tse Cheath of programming og TL (ed. North-Holland Pubi. Co 1972, 298-313, Cav. Freinanny ‘Amsterdam, Js Sanmat, Programming Lengueges! Bletory and fundamentals, Prentics Englewood-Clifre, 1969. Moll, Nour, Programming Langue and trends. 1972, 36-38. = Status + Malainkd W.D, Muskeys Re Love, Ne Wirth, A syn- tactic description of BC NELIAC, Come, AGH vol. G. no. 7, 367375 (July 1963). A, van Wijngearden, Ganeraliaed ALGOL, AonstRevs in hutan. eoazaneisg 2. (1963) 17-26, - N. Wirth, H. Weber, EULER, A general- Azation of ALGOL, and its formal de- scription, Cosm, AGH vol. 9) no. 1 and 2, 13-23, 89-99, and no. 12, O78 (dene, Fov., Dec. 1966). m Ce] (9) (19) oy C.A.R, Hoare, An axiomatic basie for computer progranming, vol. 42+ mor iG, (Bees 1968) 57ers ae “ot C.AsRy Mowre, Ne Wixth, An axiomatic definition of the progtanming lengu Pascal, Acte Information vol. 2, (1913) 335-355, C.AsRe Hoare, Hints on programming Language design, SIGACT/SIGPLAN Sym posium on priciples of progresming Languages, Boston, Oct. 1913. N. Wizth, The programming Langusi Pascal, Acte Information vol. 1, (1971) 35-63.