8/2/2019 Go to Harmful

1/4

G o T o S t a t e m e n t C o n s i d e r e d H a r m f u lKey Words and Phrases: go to statement, jump instruction,branch instruction, conditional clause, alternative clause, repet-itive clause, program intelligibili ty, program sequencingCR Cate gor ies: 4.22, 5.23, 5.24EDITOR :

For a nu mber of years I have been familiar with the observationthat the quality of programmers is a decreasing function of thedensity of go to statements in the progra ms they produce. Mor erecently I discovered wh y the use of the go to statement has suchdisastrous effects, and I became convinced that the go to state-ment should be abolished from all "higher level" pro gra mmi nglanguages (i.e. verything except, perhaps, plain machin e Code).At'that time I did not attach too mu ch importance to this dis-covery; I no w s ubmit my considerations for publication becausein very recent discussions in which the subject turned up, I havebeen urged to do so.

My first remark is that, although the programmer's activityends when he has constructed a correct program, the processtaking place under control of his program is the true subjectmatter of his activity, for it is this process that has to accomplishthe desired effect; t is this process that in its dyn ami c behaviorhas to satisfy the desired specifications. et, once the pr og ram hasbeen made, the " ma king " of the corresponding process is dele-gated to the machine.

My second remark is that our intellectual pow ers are rathergeared to mas ter static relations and that our powers to visualizeprocesses evolving in time are relatively poorly developed. Forthat reason we should do (as wise programmer s aware of ourlimitations) our ut most to shorten the conceptual gap betweenthe static progra m and the dynamic process, to ma ke the cor-respondence betwe en the program (spread out in text space) andthe process (spread out in time) as trivial as possible.

Let us no w consider ho w we can characterize the progress of aprocess. (You ma y think about this question in a very concretemanner: suppose that a process, considered as a time successionof actions, is stopped after an arbitrary action, what data do wehave to fix in order that we can redo the process until the verysam e point?) If the pro gram text is a pure concatenation of, say,assignment statements (for he purpose of this iscussion regardedas the descriptions of single actions) it is sufficient o point in theprogram text to a point between two successive action descrip-tions. (In the absence of go to statements I can permit myself thesyntactic ambiguity in the last three words of the previous sen-tence: if we parse th em as "successive (action descriptions)" w eme an successive in text space; if we parse as "(successive action)descriptions" we me an successive in time.) Let us call such apointer to a suitable place in the text a "textual index."

Wh en we include conditional clauses (if B then A), alternativeclauses (if B th en AZ else A2), choice clauses as introduced byC. A. R. Hoare (case[i] f(At, A2, ... , n)), or conditional expres-sions as introduced by J. Mc Ca rt hy (Bi -~ El, B2 --~ E2, ... ,B n ---~ n), the fact remains that the progress of the process re-mains characterized by a single textual index.

As soon as we include in our language procedures we mus t admitthat a single textual index is no longer sufficient. n the case thata textual index points to the interior of a procedure body the

dynamic progress is only characterized wh en we also give to whichcall of the procedure we refer. With the inclusion of procedureswe can characterize the progress of the process via a sequence oftextual indices, the length of this sequence being equal to thedyn ami c depth of procedure calling.

Let us now consider repetition clauses (like, hi le B rep eat Aor repeat A until B). Logically speaking, such clauses are no wsuperfluous, because w e can express repetition with the aid ofrecursive procedures. For reasons of realism I don't wish to ex-clude them: on the one hand, repetition clauses can be imple-mented quite comfortably with present day finite equipment; onthe other hand, the reasoning pattern known as "induction"makes us well equipped to retain our intellectual grasp on theprocesses generated by repetition clauses. With the inclusion ofthe repetition clauses textual indices are no longer sufficient todescribe the dynamic progress of the process. With each entry int oa repetiti on clause, however we can associate a so-called "dy-namic index," inexorably counting the ordinal number of thecorresponding current repetition. As repetition clauses (just asprocedure calls) may be applied nestedly, we find that now theprogress of the process Can always be uniquely ch aracterized by a(mixed) sequence of textual and/or dynamic indices.

The main point is t hat the values of these indices are outsideprogrammer's control; they are generated (either by the write-upof his program or by th e dynamic ev olut ion of the process) whetherhe wishes or not. They provide independent coordinates in whichto describe the progress of the process.Why do we need such independent coordinates? The reasonis--and this seems to be inherent to sequentiM processes--thatwe can interpret the value of a variable only with respect to theprogress of the process. If we wish to count the number, n say, ofpeople in an initially empty room, we can achieve this by increas-ing n by one whenever we see Someone entering the room. In thein-between moment that we have observed someone entering theroom but have not yet performed the subsequent increase of n,its value equals the number of people in the room minus one!The unbridled use of the go to statement has an immediateconsequence that it becomes terribly hard to find a meaningful setof coordinates in which to describe the process progress. Usually,people take into account as well the values of some well chosenvariables, but this is out of the question because it is relative tothe progress that the meaning of these values is to be understood lWith the go to statement one can, of course, still describe theprogress uniquely by a counter counting the number of actionsperformed since program star t (viz. a kind of normalized clock).The difficulty is that such a coordinate, although unique, is utterl yunhelpful. In such a coordinate system it becomes an extremelycomplicated affair to define all those points of progress where,say, n equals the number of persons in the room minus onet

The go to statement as it stands is just too primitive; it is toomuch an invitation to make a mess of one's program. One canregard and appreciate the clauses considered as bridling its use. Ido not claim that the clauses mention ed are exhaustive in the senseth at /h ey will satisfy all needs, but whatever clauses are suggested(e.g. abortion clauses) they should satisfy the requirement that aprogrammer independent coordinate system can be maintained todescribe the process in a helpful and manageable way.It is hard to end this with a fair acknowledgment. Am I to

Vo lum e 11 / N umb er 3 / Mar ch, 1968 Co m m un iea t io ns o f the ACM I4 7

8/2/2019 Go to Harmful

2/4

judge by whom my thinking has been influenced? It is fairlyobvious th at I am not unin fluen ced by Peter Landh~ a~d Chris~topher Str achey. Fin all y I s~muld like to record (as I remember i~qui te dis tin ctl y)h ow Heinz Zema:~ek a~ the pre-A~c~-oL meetingin early !959 in Copenhagen quite expli citly expressed his doubtswhether the go to statement should be treated on equM syntacticfooting with the ~signment statement. Tn a modest extent tblame mysel f for not ha vin g then drawn ~he eor~sequenees of hisremark.The re mark abo ut the u ndesira bility of the go to statemen t isfar from new. I remember having read the explicit recoam~enda*~[on ~o restrict the use of th e go to statement to alarm exits, butI have not been able to trace it; presumably, it has been made byC. A. R. Hoare. In {t, See. 3.Z1.] Wirth and Hoare togethermake a remark in the same direetion in motivating the caseeonst ruetio n: "Like the conditional, it mirrors die dynamicstructure of a program more eleaHy than go to statements a~dswitches, sad it eliminates the need for introducin g a large numbe rof labels i~ the program."In !2] Guiseppe aaeopini seems to have proved the (togieM)superfluousness of the go to state ment. The exercise to translatean arbit rary flow diagram more or tess meehanicMty into a jm np-less one, however, is not to be recommended. The~ the resultingflow diagram cannot be expected to be more trans pare nt than theoriginM one.

}'~gFNRE NCES :1. WIaT~LN~KL.-~'S~Axe> }{O.~a~, C A. R A co ntr ibu tio n to th edevelopmen~ of ALGOL. ('cram. A(\~.[ 9 (June 19~i), 413-432.2. B{JIH)d~ CORNADO, .aN[)J-kkCOP[N[, GUqS EPeE ,. Flow diagrams,

Turing macNnes and languages with only two formation>ties, Commo AC M ,9 (M ay lg@}), 3(~->-371.

EDSGER Wo I )U K S TRATechnogogicag UniversityEindhoven, The NegheHa~ds

l a n g u a g e P r o t e c t i o n b y T r a d e m a r k I l l - a d v i s e dKey Words and Phrsaes: T RAC languages, procedure-orientedlanguage, propriet ary software, protection of software, trade~marks, copyright pr otection, patent protection, standardization,

lice~sing, Mooers doctrb~eC[~' Categ orie s: 212, 2.2, 4.0, 42}:n~Toa :I would like to comment on a policy published 25 August 1967by the Rockford Research Inst itut e Inc., for trademark controlof ~he T}~Ac language "ori gina ted by C alvi n N. Mooers of tha teorp,r atio>.": "I~ is ~.he belief at Rockford t~meareh tha t anaggresa ive cour:~e of actio n can an d should be taker~ to pr otec t t hei~tegrity of its carefully desig~ed targuages." Mr. Mooers believesthat "well-drawn standards are not enough to prevent irrespon.-sib~e deviatio~v~ in computer ta~guages," and that. there%re"Rnek ford Research shall insi st ~ha~. all software and su ppor tingservices for its T:r{.~e languages arid re lated services be furnishe dfor a price by Rockford~ or by sources licensed and authorized byRockford in a cow, ract ar ra ng em en t" Mooers' policy, whichapplies in academic hastitutions ~s well as commercial ~sem,includes ":authorized use of the algorithm and prbnitives of aspecific T-~ae langua ge; aut hori zati on for experimentatior~ withthe language , 2'I ~hir~k th at ~hisattempt ~o protect a ia~guage a~d its softwareby eoatrotlb~g ffhe name is ve ry ill-advised. Orm is remi~ded ofthe Co ~r tz, ngaage, whose develo~:~r~ (under V. Yngve) reetriete d

its sour ced evel d ist rib uti on. As a resul t, tha t efforl5 was bypassedby the people at Bell Laborator ies who developed Srvonou Thislatter Ianguage and its software were iacvitM)ly superior, andwere imme dia tel y avail abl e to every~me, b~eluding the right tomake exte~sio~s. Later versions benefitted from "meritoriousextra,sie na" by "ir repre ssible young people " at universities, withthe result that Sxo~o~, today is an important and prominentlanguage, while Coast enjoys relative obscurity.

Mr. Mooers will find that; new Ta~cdike languages will appearwhose documentatimb because of the trademark restriction, can.not menti on Tm~c. Te xtbook references will be similar ly inhibited.It is unfortunate. B~:RNaeD A. Ga L ~

UaiversiQl of MichigagAnn Arbor, Mich. 4810~Mr. Manet's Reply

EDITOR: Profe ssor GMter's let.tar, com men tin g ca our Rockford Research policy st at em en t on software pr ote cti on of 25 Augu st 1967, opens the discussion of what may be a very significant developmeat to our computing profession. This policy statement applies to ourTIRAC CFM) compu ter-c ontro lling language s. The statement in.eludes a new doctrine of software pr otec tion which may be gen. era lly appli cabl e to a va ri et y of different kin ds of complex corn- purer systems, comp uter services, languages , and software, Already it is evide nt tha t this doctri ne has a num ber of interestinglegal and commercial implicat ions. It is accord ingly appropriate that it be subiect to critical discussion.The doctrin e is very simple. For speeif ieity, I shall describe itin regard to the Tm~c languages which we have developed: (1)Rockford Research has des ignated itse lf as the sole authority forthe development and publication of authentic standards andspecif icatio ns for o ur TRAC lan gua ges ; and (2) we have adoptedTaac as our commercial trademark (and service mark) for use inconnection with our eoraputer-eontrolling languages, our publica-tions providing standa rds for the language s and any other relatedgoods or services,

The power of this doc trine de rives from the u nique manner inwhieh :it serves the int eres ts of the cons umin g pub lic --t he people who wilt be using computer services. The visible and recognizedTe.~c trademark informs this public--the engineers, the soeiol0gyprofessors , the bu sine ss sys tem s people, an d the nonprogrammersevery wher e--t hat the language or computer capabili ty identified by this trad emar k adhere s authe ntie Mly and exactly to a carefully *drawn Rockford Research standar d for one of our TR:~c languages or some relat ed service. Th is is in accord with a long commercial and legal tradition.The evils of the pre sent situa tion and the need to find a suitable remedy are well known. An adequ ate basi s for propr ietar y soft- ware development and marketin g is urge ntly needed, particularlyin view of the doubd ul capabilities of copyright, pa tent, or "tradesecr et" metho ds when applied to software. Developers of vMuablesys tem s-- inc lud ing languages-~-deserve to hav e some vehicle togive them a re turn. On the user side the nonexiste nce of standardsin the computer systems area is a continuing nuisance. Thepro lif era tion of dialec ts ou wdua bte l ang uag es (e.g. SNOR0~ or .f' O~Tr~~.X) iS sheer madn ess. The la ym an user (read "nonprogram"mer") who now has access to any of several dozen computerfacilities (each with incom pati ble syste ms and diMects) needsrelief. It is my opinion that this new doctrirm of autonomoussta~dardizativm eoupled with resort to eontmereiat trademark canprovide a substangiM contribution to remedying a variety of ourproblems ia this area.Several points of Professor Galter's tatter deserve specificcomment Ih::, full impact of our Rockford Research policy (and

t 48 Co mm un i e a t l o ~s ~ )f t he ACid | Vo l ume 11 / Nu mbe r 3 / Mar c h , 1698

8/2/2019 Go to Harmful

3/4

J

indeed of this doctrine applied to other developments) uponacademic activities cannot be set forth in just a few words (cf.Rockford Memo V-202). It is my firm belief that academic ex-perimentation must be encourage d--indeed it c annot be stopped.Nevertheless, the aberrant or even possibly improved productscoming from the academic halls must not be permitted to confuseor mislead the consu ming public. Car eful use of, and respect for,trademark can ensure that this does not occur.~NOBOL was mentioned as illustrating a presumably desirablesituation regarding innovation. Yet according to the SnobolBuIlelin No. 3 (November 1967), we find already a deep concernregarding serious incompa tibilities among the man y "home-made"implementations of this language. In addition, there are seriouscomplaints over the profound lack of "upward compatibility"between the la tes t "SNOBOLS." The c onsequ ent ina bili ty of theusers to exchange or publish useful algorithms is cited. These areexactly some of the problems that our policy hopes to avoid.The future of our computing technology lies in service to thelayman users. Our pres ent chaos in interfaces, formats, lack ofstandards, proliferation of needless dialects, unreliable documen-tation, and all the other hazards and incompa tibilities is com-pletely intolerable to the users. The users know it. I t is about timewe knew it too.I believe that this doctrine of autonomous standa rdizat ion andtrademark identification is a long step forward in service to th euser public, and thus is in the right direction. According to thealmost uniformly favorable response we have received to date,many others seem to thi nk the same way. I expec t to see thedoctrine have wide application.

C AL VI N N. MOOERSRockford Research Institute Inc.Cambridge, Mass. 02138

No Tro u b l e w i t h A t l a s ! P ag e -Tu rn i n gM e c h a n i s mKey Words and Phrases: Atlas I, page- turning proceduresCR Categ ories : 4.2, 4.22EDITORThe editorial on "The Eur opean Computer Gap," Comm. ACM10 (April 1967), 203, tells of "pape r designs th at Could never beconverted into operational systems," and among these includes"the p age-tur ning procedures proposed with the original designof the Atlas."Not merely does this do injustice to Atlas, but it is in fact quitewrong. The Atlas I machine we have here has a one-level storemade up of 48K words of 2gs cores and 96K words on drums. Th epaging and pa ge-turning mechanism have worked without a nytrouble at all almost from the be ginning- -so well that it is some-thing we hardly ever think about. To give an idea of how in-tensively the system is used let me say tha t since 1964 we havebeen running a service for research workers in all British uni-versities with a very mixed load of programs in all the majorlanguages. We put about 2500 jobs through the machi ne each.week, a nd the syste m efficiency is ar ound 70 percent. By this lastfigure I mean that, of all the instructions obeyed by the machineover a long period, 70 perce nt goes into eit her the compiling orexecution of users' programs. The figure can rise to over 90 per-cent with a favorable job-mix. J. HOWLE'rTAtlas Computer LaboratoryChilton, DidcotBerkshire, England

O n P r a c t i c a l i t y o f S i e v i n g T e c h n i q u e s v s . t h eS i e v i n g A l g o r i t h mKey Words and Phrases: prime numbers, sieving algorithmssieving techniques, indexing techniquesCR Categor ies: 3.15, 5.39EDITOR:After reading the remarks on the sieving algorithms in the Septemb er 1967 issue of Communications of the ACM [p. 569], i shouldlike to point out the fact that these algorithms are presentedin ALGOL solely for the purpose of comm unic atin g he idea of thealgorithm, and tha t the published runn ing times for the sievinalgorithms are not re presen tative of the sieving process.For practical use these algorithms are usually implemented inassembly language on machines with high speed index registerssince the sieving technique is essentially an indexing techniqueFor example, an algorithm which, when given an array of lengthn, sieves between p and p+2n was implemented in the assembllanguage for an IBM 360 model 40. This algorithm assumes onlthat the even numbers between p and p+2n have already beecrossed out; it does not inc orporate any of the special features oAlgorithms 310 and 311. The time required to compute the first mprimes is given !n the following table.

m Time (see)10,O00 7100,000 87500,000 5251,000,000 11491,250,(100 1487

The va lue of n used in prep arin g the above t abl e was n = 16,(10The average time for sieving over an inter val of le ngth 32,000 wa2.46see.Thus, while it may appear that the sieving algorithms are tooslow to be pract ical when imple mented ill a compiler language, thabove times indicate tha t the sieving technique can be practicawhen implemented in a n assembly language.JOHN E. HOWLANDUniversity of Oklahoma

Norman, Oklahoma 7806

D e a l i n g w i t h N e e l y ' s A l g o r i th m sKey Words and Phrases: algorithm, computa tion of stat is t ics

truncat ion error, Neely's comparisonsCR Categor ies : 4.0, 5.5, 5.11EDITOR :When we decided to use the method of Welford [1] inour FORTRAN programs we made some compar isons, b ut arr ivedat a conclusion which contradicts Peter Neely' s [2]. This was aninvi tati on to us to scrutinize Neely's work. His remark, "T heinaccura cy noted for M2 may be due to IBM-FORTRAN,which doenot compile a floating round," is one pointer to the source oinaccuracy. Indeed, with a compiler which does compile a floatinround, Welford's method gives results equivalent to those obtained with the two-pass method recommended by Neely. If floating round is not compiled, the use of Kahan's trick [3] wilgive excellent results even on those machines, such as an IBM1620 which truncate s before normalizing a floating point sum.Another source of inaccuracy, however, is due to the way Welford's formulas are programmed. In particular we found that theformulas as given by Welford and programmed by Neely are nothe best available.

11 / Num be r 3 / Mar c h , 1968 Com mun i c a t i o ns o f t he ACM 14 9

8/2/2019 Go to Harmful

4/4

The best versions for programming purposes seem to be thefollowing:m0 = 0; m i = m i - t + ( x i - m i - O / i , i = 1, n; M ~= m,, (1)so = 0; si = si-~ + (xl--m~-O a - - ( z i - m~- ~ ) V i , i = 1, n;and Pa similar to (2). Of these equatio ns (1) is most impor tant an daddition using Kahan's trick will give an error-free answer.Not u sing Kah an' s trick will give results for variabl e z,, ~ no~as good as those obtained with the two-pass method, but sincewe thit~k this kind of variable is not likely to occur in practicalwork, we recommend (1) and (;2) for cal cula tion of the mea~ andcorrected sum of squares, Since we found that from (1) and (2)Zx and Zx ~ are more acc uratel y r etrieved tha n when computeddirectly, we think that (1) can be used in numerical integrationtoo, if the result afterwards is multiplied by the number of in-tervals.

I:~,EFERENCES:1. W~Lr'O~n, B. P. Note on a method for calc ulatin g correctedsums of squares and products. Technomeb~ics IV (H~2),

419-420.2. N~ELY, PF~TnR M. Compa riso n of seve ral algo rith ms forcomputation of means, stand ard deviations and correlation

coefficients, Comm, A CM 9, 7 (July I~2~), 4%-4{N.3, KaHaN, W. Fur the r remark on reducing trunca tion errors.Comm. ACM 8, 1 (Jan, 1%5), 40.

A. J. van REEKENReke-ncen~rumKa~hoIieke HogeseheolTilburg, The :Ve~hertands

A b b r e v i a t i o n s f o r C o m p u t e r a n d M e m o r y S i z e sKey Words and Phrases: memory, thousandCR Categories: 2.44, 6.34EDITOa:

Th e fact, th at 2 ~ an d 10~ are almr ~t bu t mot quite equM createsa log of trivial confusion in the computing world and around itsperiphery. One hears, for example, of doubling the size of a 32Kmemory and getting a 65K (not. 64K) memory, Doubling againyields a 131K (not 130K) memory. People who use powers of twoall the time know that these are approximations to a number theycould eompute exactly if they wanted ~o, but they seldom takethe trouble, In conversations with outsiders, much time is waistedexplaining that we really can do simple arithmetic and we didn%mean exactly what we said.The confusion arises beeause we use K, which traditionallymeans 1000, as an ap proxi mation for 1024. If we had a ha ndy namefor 1024, we wouldn'g have to approxima te, I suggest ghag(kapp a) be w~ed for this pu~r~ose. Th us a 32~ memory means onewith exactly 32,768 words. Doubling it pr{aduces a ~N~ memorywhich is to say one with exactly 65,536 words. As memories getlarger and go in to th e rni/lior~s of words, o~e car~ speak of a 32~~(33,5&i,432-word) memor y and dou blin g it, wilt y ield a64~ ~(67,108,864-word) memory. Use rs of the lang uag e will need to haveat their fi ngertips only the first nine powers of 2 and wilt not needto explain the dis crepanc ies between what the)' ~aid and what the}"m e a n t . Do~a~rA> R~ Mo ~ t s o ~

Camp~Nr Science, D@izion 5256Sandia C~porat i (m, Sandia BaneA ~buquerque, N . Me w

1~0 Com rau~ieat ious o f the ACM

I n D e f e n s e o f L a n g d o n ' s A l g o r i t h m *Key Wo~ls and Phra:aes: lexicographie permu{,ationC R Categories: 5,~9

()rd-Smi~h {Letter o ~he Editor, Cumin. ACM I0 , 11 (Nov.19W), (iS41 makes some imp er tin en t r emarks (m the subject 0ft,angdon's Mgoritbm {tL The main poi~t of the letter "that theredoes not a ppear ~o he an3 combi nator ial a dvan tage of circularordering over icxicographic ordering" is hardly relevant. Theproblem attacked by Laagdon is no~ !~) fimt combinatorial ad.vantage but rather compz~lagiona! advantage, which Langd0n'sMgori~hm m