14 van Wijngaarden, et al.0.3.4. Modes of multiple valuesA new class of modes is introduced, for multiple values whose elementsare themselves multiple values. Thus one may now write the declarer [ ]siring.Moreover, multiple values no longer have "states" to distinguish theirflexibility. Instead, flexibility is now a property of those names whichrefer to multiple values whose size may change, such names havingdistinctive modes of the form 'reference to flexible ROWS of MODE'.0.3.5. Identification of operatorsNot only may two operators, related to each other by the modes oftheir operands, not be declared in the same range, as before, but now, iftwo such operators be declared in different reaches, any attempt toidentify from the inner reach the one in the outer reach will fail. Thisgives some benefit to the implementer and removes a source of possibleconfusion to the user.0.3.6. RepresentationsThe manner in which symbols for newly defined mode-indications andoperators are to be represented is now more closely defined. Thus it isclear that the implementer is to provide a special alphabet of bold-faced,or "stropped", marks from which symbols such as person may be made,and it is also clear that operators such as >> are to be allowed.0.3.7. Standard preludeIn order to ease the problems of implementers who might wish toprovide variants of the language suitable for environments where Englishis not spoken, there are no longer any field-selectors known to the user inthe standard-prelude, with the exception of re and im of the mode ¢ompl.The identifiers and other indicators declared in the standard-preludecould, of course, easily be defined again in some library-prelude, but thiswould not have been possible in the case of field-selectors.0.3.8. Line length in transputThe lines (and the pages also) of the "book" used during transput maynow, at the discretion of the implementer, be of varying lengths. Thismodels more closely the actual behaviour of most operating systems andof devices such as teleprinters and paper-tape readers.0.3.9. Internal transputThe transput routines, in addition to sending data to or from externalmedia, may now be associated with row-of-character-variables declared bythe user.0.3.10. Elaboration of formatsALGOL <strong>68</strong> Revised Report 15The dynamic replicators contained in format-texts are now elaboratedas and when they are encountered during the formatted transput process.This should give an effect more natural to the user, and is easier toimplement.0.3.11. Features removedCertain features, such as proceduring, gommas and formal bounds,have not been included in the revision.0.4. Changes in the method of descriptionIn response to the directive from the Working Group "to make its studyeasier for the uninitiated reader", the Editors of this revision haverewritten the original Report almost entirely, using the same basicdescriptional technique, but applying it in new ways. It is their hope thatless "initiation" will now be necessary.The more significant changes in the descriptional technique areindicated below.0.4.1. Two-level grammara) While the syntax is still described by a two-level grammar of thetype now widely known by the name "Van Wijngaarden", new techniquesfor using such grammars have been applied. In particular, the entireidentification process is now described in the syntax using the metanotion"NEXT", whose terminal metaproductions are capable of describing, and ofpassing on to the descendent constructs, all the declared informationwhich is available at any particular node of the production tree.b) In addition, extensive use is made of "predicates". These arenotions which are deliberately made to yield blind alleys when certainconditions are not met, and which yield empty terminal productionsotherwise. They have enabled the number of syntax rules to be reduced inmany cases, while at the same time making the grammar easier to followby reducing the number of places where a continuation of a given rulemight be found.c) It has thus been possible to remove all the "context conditions"contained in the original Report.0.4.2. Modesa) In the original Report, modes were protonotions of possibly infinitelength. It was assumed that, knowing how an infinite mode had beenobtained, it was decidable whether or not it was the same as ~ome otherinfinite mode. However, counterexamples have come to light ,vhere this
van wljngaaraen, et al.was not so. Therefore, it has been decided to remove all infinities from theprocess of producing a finite program and, indeed, this can now be done ina finite number of moves.b) A mode, essentially, has to represent a potentially infinite tree. Todescribe it as a protonotion of finite length requires the use of markers{'MU definition's} and pointers back to those markers {'MU application's}within the protonotion. However, a given infinite tree can be "spelled" inmany ways by this method, and therefore a mode becomes an equivalenceclass comprised of all those equivalent spellings of that tree. Theequivalence is defined in the syntax using the predicates mentionedearlier.0.4.5. TranslationsALGOL <strong>68</strong> Revised Report 17The original Report has been translated into various natural languages.The translators were not always able to adhere strictly to the descriptionalmethod, and so the opportunity has been taken to define more clearly andmore liberally certain descriptional features which caused difficulties (see1.1.5).{True wisdom knows it must comprisesome nonsense as a compromise,lest fools should fail to find it wise.Grooks,Piet Hein.}0.4.3. ExtensionsThe need for many of the extensions given in the original Report hadbeen removed by language changes. Some of the remainder had been aconsiderable source of confusion and surprises. The opportunity hastherefore been taken to remove the extension as a descriptionalmechanism, all the former extensions now being specified directly in thesyntax.0.4.4. Semanticsa) In order to remove some rather repetitious phrases from thesemantics, certain technical terms have been revised and othersintroduced. The grammar, instead of producing a terminal productiondirectly, now does so by way of a production tree. The semantics isexplained in terms of production trees. Paran'otions, which designateconstructs, may now contain metanotions and "hypernotions" have beenintroduced in order to designate protonotions.b) A model of the hypothetical computer much more closely related toa real one has been introduced. The elaboration of each construct is nowpresumed to take place in an "environ" and, when a new range is entered(and, in particular, when a routine is called), a new "locale" is added tothe environ. The locale corresponds to the new range and, if recursiveprocedure calls arise, then there exist many locales corresponding to onesame routine. This supersedes the method of "textual substitution" usedbefore, and one consequence of this is that the concept of "protection" isno longer required.c) The concept of an "instance" of a value is no longer used. Thissimplifies certain portions of the semantics where, formerly, a "newinstance" had to be taken, the effects of which were not always clear tosee.1. Language and metalanguage1.1. The method of description1.1.1. IntroductionPARTIPreliminary definitionsa) ALGOL <strong>68</strong> is a language in which algorithms may be formulatedfor computers, i.e., for automata or for human beings. It is defined by thisReport in four stages, the "syntax" {b}, the "semantics" {c}, the"representations" {d} and the "standard environment" {e}.b) The syntax is a mechanism whereby all the constructs of thelanguage may be produced. This mechanism proceeds as follows:(i) A set of "hyper-rules" and a set of "metaproduction rules'" are given{1.1.3.4, 1.1.3.3}, from which "production rules" may be derived:(ii) A "construct in the strict language" is a "production tree" {1.1.3.2.f}which may be produced by the application of a subset of thoseproduction rules; this production tree contains static information {i.e..information known, at "compile time"} concerning that construct: it iscomposed of a hierarchy of descendent production trees, terminating atthe lowest level in the "symbols"; with each production tree isassociated a "nest" of properties, declared in the levels above, which ispassed on to the nests of its descendents;Off) A "program in the strict language" is a production tree for the notion'program' {2.2.1.a}. It must also satisfy the "environment condition"{10.1.2}.
- Page 2 and 3: van Wijngaarden, et al.1.1.4.2. Par
- Page 4: Acknowledgements{Habent sua fata li
- Page 10 and 11: . . . . . . . 4 " ' 0 . . . . . . .
- Page 12 and 13: 22 van Wijngaarden, et al.• let P
- Page 14 and 15: 26 van Wijngaarden, et al.{Since so
- Page 16 and 17: 30 van Wijngaarden, et aLloperandfo
- Page 18 and 19: 34 van Wijngaarden, et al.j) WHETHE
- Page 20 and 21: 38 van Wijngaarden, et al.A protono
- Page 22 and 23: 42 van Wijngaarden, et al.d) If N i
- Page 24 and 25: 46 van Wijngaarden, et al.c) {There
- Page 26 and 27: 50 van Wijngaarden, et al.c) The ph
- Page 28 and 29: 54 van Wijngaarden, et al.3.1.1. Sy
- Page 30 and 31: 58 van Wijngaarden, et al.where (RO
- Page 32 and 33: 62 van Wijngaarden, et al.1) SOlD N
- Page 34 and 35: 66 van Wijngaarden, et al.ALGOL 68
- Page 36 and 37: 70 van Wijngaarden, et el.For each
- Page 38 and 39: 74 van Wijngaarden, et al.If 'MODE"
- Page 40 and 41: 78 J van Wijngaarden, et al.C) SECO
- Page 42 and 43: 82 van Wijngaarden, et al.ALGOL 68
- Page 44 and 45: 86 van Wijngaarden. et al.ALGOL 68
- Page 46 and 47: 90 van Wijngaarden, et al.5.4.4.1.
- Page 48 and 49: 94van Wijngaarden, et al.ALGOL 68 R
- Page 50 and 51: 98 van Wijngaarden, et al.Assignati
- Page 52 and 53: 102 van Wijngaarden, et at.{A nest,
- Page 54 and 55: 106 van Wijngaarden, et al.'HEAD's
- Page 56 and 57: 110 van Wijngaarden, et al.ALGOL 68
- Page 58 and 59:
114van Wijngaarden, et al.ALGOL 68
- Page 60 and 61:
118 van Wijngaarden, et al.ALGOL 68
- Page 62 and 63:
122 van Wijngaarden, et al.style ii
- Page 64 and 65:
126 van Wijngaarden, et al.b) The c
- Page 66 and 67:
130van Wijngaarden, et al.ALGOL 68
- Page 68 and 69:
134van Wijngaarden, et al.ALGOL 68
- Page 70 and 71:
138d)e)f)g)h)i)J)k)1)m)n)van Wijnga
- Page 72 and 73:
142 van Wijngaarden, et al.physics
- Page 74 and 75:
146 van Wijngaarden, et al.gg) On s
- Page 76 and 77:
150van Wijngaarden, et al.ALGOL 68
- Page 78 and 79:
154/van Wijngaarden, et al.ALGOL 68
- Page 80 and 81:
158 van Wijngaarden, et el.fi;ref p
- Page 82 and 83:
162van Wijngaarden, et al.ALGOL 68
- Page 84 and 85:
166van Wijngaarden, et al.ALGOL 68
- Page 86 and 87:
170/van Wijngaarden, etal.ALGOL 68
- Page 88 and 89:
174J)K)L)M)N)O)P)a)b)c)d)e)van Wijn
- Page 90 and 91:
178/van Wijngaarden, et al.ALGOL 68
- Page 92 and 93:
182 van Wijngaarden, et al.• let
- Page 94 and 95:
186van Wijngaarden, et al./ALGOL 68
- Page 96 and 97:
190 van Wijngaarden, etal.composed
- Page 98 and 99:
194h)i)J)van Wijngaa(rden, et al.pr
- Page 100 and 101:
198 van Wijngaarden, et al.¢ strin
- Page 102 and 103:
202tvan Wijngaarden, et al.ALGOL 68
- Page 104 and 105:
206 van Wijngaa~den. et al.10.3.6.1
- Page 106 and 107:
210 van Wijngaarden, et al.!ALGOL 6
- Page 108 and 109:
214 van Wijngaarden, et al.inoperat
- Page 110 and 111:
218fvan Wijngaarden, et al.¢ move
- Page 112 and 113:
222 van Wijngaarden, etaL{overflow}
- Page 114 and 115:
226 van Wijngaarden, et al.ALGOL 68
- Page 116 and 117:
230max int 10.2.1.cmax real 10.2.l.
- Page 118 and 119:
234 van Wijngaarden, et al.ALGOL 68