Typology of Programming Languages E Early Languages E

Total Page:16

File Type:pdf, Size:1020Kb

Load more

Typology of program m ing languages

e Early Languages E

Typology of program m ing languages

Early Languages

1 / 71

The Tower of Babel

Typology of program m ing languages

Early Languages

2 / 71

Table of Contents

1

Fortran

2

ALGOL

3

COBOL

4

The second wave

5

The finale

Typology of program m ing languages

Early Languages

3 / 71

IBM Mathematical Formula Translator system

Fortran I, 1954-1956, IBM 704, a team led by John Backus.

Typology of program m ing languages

Early Languages

4 / 71

IBM 704 (1956)

Typology of program m ing languages

Early Languages

5 / 71

IBM Mathematical Formula Translator system

The m ain goal is user satisfaction (econom ical interest) rather than academ ic. Com piled language.

a single data structure : arrays com m ents arithm etics expressions DO loops subprogram s and functions I/O m achine independence

Typology of program m ing languages

Early Languages

6 / 71

FORTRAN’s success

Because: program m ers productivity easy to learn by IBM the audience was m ainly scientific sim plifications (e.g., I/O)

Typology of program m ing languages

Early Languages

7 / 71

FORTRAN I

CC
FIND THE MEAN OF N NUMBERS AND THE NUMBER OF VALUES GREATER THAN IT

DIMENSION A(99) REAL MEAN

READ(1,5)N

FORMAT(I2)

5
READ(1,10)(A(I),I=1,N)

  • FORMAT(6F10.5)
  • 10

SUM=0.0 DO 15 I=1,N

  • 15
  • SUM=SUM+A(I)

MEAN=SUM/FLOAT(N)

NUMBER=0

DO 20 I=1,N
IF (A(I) .LE. MEAN) GOTO 20

NUMBER=NUMBER+1
CONTINUE

20 25

WRITE (2,25) MEAN,NUMBER

FORMAT(11H MEAN = ,F10.5,5X,21H NUMBER SUP = ,I5)

STOP

Typology of program m ing languages

Early Languages

8 / 71

END

Fortran on Cards

Typology of program m ing languages

Early Languages

9 / 71

Fortrans

Typology of program m ing languages

Early Languages

10 / 71

Table of Contents

1

Fortran

2

ALGOL

3

COBOL

4

The second wave

5

The finale

Typology of program m ing languages

Early Languages

11 / 71

ALGOL, Demon Star, Beta Persei, 26 Persei

Typology of program m ing languages

Early Languages

12 / 71

ALGOL 58

Originally, IAL, International Algebraic Language.

1

Usable for algorithm publications in scientific reviews

2

As close as possible to the usual m athem atical notations

3

Readable without assistance

4

Autom atically translatable into m achine code

Meeting between 8 Am ericans and Europeans in Zurich. ALGOL 58.

Typology of program m ing languages

Early Languages

13 / 71

ALGOL 58

IAL was considered ”unspeakable and pom pous acronym ”

Introduced the fundam ental notion of com pound statem ent

I

restricted to control flow only not tied to identifier scope

I

Used during 1959 for publication Prim ary contribution was to later languages: a basis for JOVIAL ꢀick, MAD, and NELIAC.

Early com prom ise design soon superseded by ALGOL 60

Typology of program m ing languages

Early Languages

14 / 71

JOVIAL

”Jules Own Version of the International Algorithm ic Language.”

Developed to write soſtware for the electronics of m ilitary aircraſt by Jules Schwartz in 1959.

Runs the Advanced Cruise Missile, B-52, B-1, and B-2 bom bers, C-130, C-141, and C-17 transport aircraſt, F-15, F-16, F-18, and F-117 fighter aircraſt, LANTIRN, U-2 aircraſt, E-3 Sentry AWACS aircraſt, Special Operations Forces, Navy AEGIS cruisers, Arm y Multiple Launch Rocket System (MLRS), Arm y UH-60 Blackhawk helicopters, ..

Typology of program m ing languages

Early Languages

15 / 71

ALGOL 60

Figure: John Mac Carthy, Fritz Bauer, Joe Wegstein. Boꢁom row: John Backus, Peter Naur, Alan Perlis

Typology of program m ing languages

Early Languages

16 / 71

ALGOL 60: Novelties

Use of BNF to describe the syntax Inform al sem antics Block structure Dynam ic arrays Advanced control flow (if, for…) Recursivity

Typology of program m ing languages

Early Languages

17 / 71

ALGOL 60: One syntax, three lexics

Reference language (used in the ALGOL-60 Report)

a[i+1] := (a[i] + pi x r^2) / 6.021023;

Typology of program m ing languages

Early Languages

18 / 71

ALGOL 60: One syntax, three lexics

Reference language (used in the ALGOL-60 Report)

a[i+1] := (a[i] + pi x r^2) / 6.021023;

Publication language

ai+1 ← {ai + π × r2}/6.02 × 1023;

Typology of program m ing languages

Early Languages

18 / 71

ALGOL 60: One syntax, three lexics

Reference language (used in the ALGOL-60 Report)

a[i+1] := (a[i] + pi x r^2) / 6.021023;

Publication language

ai+1 ← {ai + π × r2}/6.02 × 1023;

Hardware representations – im plem entation dependent

a[i+1] := (a[i] + pi * r^2) / 6.02E23; or a(/i+1/) := (a(/i/) + pi * r ** 2) / 6,02e23; or A(.I+1.) .= (A(.I.) + PI * R 'POWER' 2) / 6.02'23.,

Typology of program m ing languages

Early Languages

18 / 71

Recommended publications
  • Computer Managed Instruction in Navy Training. INSTITUTION Naval Training Equipment Center, Orlando, Fla

    Computer Managed Instruction in Navy Training. INSTITUTION Naval Training Equipment Center, Orlando, Fla

    DOCUMENT RESUME ED 089 780 IR 000 505 AUTHOR Middleton, Morris G.; And Others TITLE Computer Managed Instruction in Navy Training. INSTITUTION Naval Training Equipment Center, Orlando, Fla. Training Analysis and Evaluation Group. REPORT NO NAVTRADQUIPCEN-TAEG-14 PUB DATE Mar 74 NOTE 107p. ERRS PRICE MF-$0.75 HC-$5.40 PLUS POSTAGE DESCRIPTORS *Computer Assisted Instruction; Computers; Cost Effectiveness; Costs; *Educational Programs; *Feasibility Studies; Individualized Instruction; *Management; *Military Training; Pacing; Programing Languages; State of the Art Reviews IDENTIFIERS CMI; *Computer Managed Instruction; Minicomputers; Shipboard Computers; United States Navy ABSTRACT An investigation was made of the feasibility of computer-managed instruction (CMI) for the Navy. Possibilities were examined regarding a centralized computer system for all Navy training, minicomputers for remote classes, and shipboard computers for on-board training. The general state of the art and feasibility of CMI were reviewed, alternative computer languages and terminals studied, and criteria developed for selecting courses for CMI. Literature reviews, site visits, and a questionnaire survey were conducted. Results indicated that despite its high costs, CMI was necessary if a significant number of the more than 4000 Navy training courses were to become individualized and self-paced. It was concluded that the cost of implementing a large-scale centralized computer system for all training courses was prohibitive, but that the use of minicomputers for particular courses and for small, remote classes was feasible. It was also concluded that the use of shipboard computers for training was both desirable and technically feasible, but that this would require the acquisition of additional minicomputers for educational purposes since the existing shipboard equipment was both expensive to convert and already heavily used for other purposes.
  • A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book)

    A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book)

    A Politico-Social History of Algolt (With a Chronology in the Form of a Log Book) R. w. BEMER Introduction This is an admittedly fragmentary chronicle of events in the develop­ ment of the algorithmic language ALGOL. Nevertheless, it seems perti­ nent, while we await the advent of a technical and conceptual history, to outline the matrix of forces which shaped that history in a political and social sense. Perhaps the author's role is only that of recorder of visible events, rather than the complex interplay of ideas which have made ALGOL the force it is in the computational world. It is true, as Professor Ershov stated in his review of a draft of the present work, that "the reading of this history, rich in curious details, nevertheless does not enable the beginner to understand why ALGOL, with a history that would seem more disappointing than triumphant, changed the face of current programming". I can only state that the time scale and my own lesser competence do not allow the tracing of conceptual development in requisite detail. Books are sure to follow in this area, particularly one by Knuth. A further defect in the present work is the relatively lesser availability of European input to the log, although I could claim better access than many in the U.S.A. This is regrettable in view of the relatively stronger support given to ALGOL in Europe. Perhaps this calmer acceptance had the effect of reducing the number of significant entries for a log such as this. Following a brief view of the pattern of events come the entries of the chronology, or log, numbered for reference in the text.
  • Standards for Computer Aided Manufacturing

    Standards for Computer Aided Manufacturing

    //? VCr ~ / Ct & AFML-TR-77-145 )R^ yc ' )f f.3 Standards for Computer Aided Manufacturing Office of Developmental Automation and Control Technology Institute for Computer Sciences and Technology National Bureau of Standards Washington, D.C. 20234 January 1977 Final Technical Report, March— December 1977 Distribution limited to U.S. Government agencies only; Test and Evaluation Data; Statement applied November 1976. Other requests for this document must be referred to AFML/LTC, Wright-Patterson AFB, Ohio 45433 Manufacturing Technology Division Air Force Materials Laboratory Wright-Patterson Air Force Base, Ohio 45433 . NOTICES When Government drawings, specifications, or other data are used for any purpose other than in connection with a definitely related Government procurement opera- tion, the United States Government thereby incurs no responsibility nor any obligation whatsoever; and the fact that the Government may have formulated, furnished, or in any way supplied the said drawing, specification, or other data, is not to be regarded by implication or otherwise as in any manner licensing the holder or any person or corporation, or conveying any rights or permission to manufacture, use, or sell any patented invention that may in any way be related thereto Copies of this report should not be returned unless return is required by security considerations, contractual obligations, or notice on a specified document This final report was submitted by the National Bureau of Standards under military interdepartmental procurement request FY1457-76 -00369 , "Manufacturing Methods Project on Standards for Computer Aided Manufacturing." This technical report has been reviewed and is approved for publication. FOR THE COMMANDER: DtiWJNlb L.
  • Simula Mother Tongue for a Generation of Nordic Programmers

    Simula Mother Tongue for a Generation of Nordic Programmers

    Simula! Mother Tongue! for a Generation of! Nordic Programmers! Yngve Sundblad HCI, CSC, KTH! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad! Inspired by Ole-Johan Dahl, 1931-2002, and Kristen Nygaard, 1926-2002" “From the cold waters of Norway comes Object-Oriented Programming” " (first line in Bertrand Meyer#s widely used text book Object Oriented Software Construction) ! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad! Simula concepts 1967" •# Class of similar Objects (in Simula declaration of CLASS with data and actions)! •# Objects created as Instances of a Class (in Simula NEW object of class)! •# Data attributes of a class (in Simula type declared as parameters or internal)! •# Method attributes are patterns of action (PROCEDURE)! •# Message passing, calls of methods (in Simula dot-notation)! •# Subclasses that inherit from superclasses! •# Polymorphism with several subclasses to a superclass! •# Co-routines (in Simula Detach – Resume)! •# Encapsulation of data supporting abstractions! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad! Simula example BEGIN! REF(taxi) t;" CLASS taxi(n); INTEGER n;! BEGIN ! INTEGER pax;" PROCEDURE book;" IF pax<n THEN pax:=pax+1;! pax:=n;" END of taxi;! t:-NEW taxi(5);" t.book; t.book;" print(t.pax)" END! Output: 7 ! ! KTH - CSC (School of Computer Science and Communication) Yngve Sundblad – Simula OctoberYngve 2010Sundblad!
  • Internet Engineering Jan Nikodem, Ph.D. Software Engineering

    Internet Engineering Jan Nikodem, Ph.D. Software Engineering

    Internet Engineering Jan Nikodem, Ph.D. Software Engineering Theengineering paradigm Software Engineering Lecture 3 The term "software crisis" was coined at the first NATO Software Engineering Conference in 1968 by: Friedrich. L. Bauer Nationality;German, mathematician, theoretical physicist, Technical University of Munich Friedrich L. Bauer 1924 3/24 The term "software crisis" was coined at the first NATO Software Engineering Conference in 1968 by: Peter Naur Nationality;Dutch, astronomer, Regnecentralen, Niels Bohr Institute, Technical University of Denmark, University of Copenhagen. Peter Naur 1928 4/24 Whatshouldbe ourresponse to software crisis which provided with too little quality, too late deliver and over budget? Nationality;Dutch, astronomer, Regnecentralen, Niels Bohr Institute, Technical University of Denmark, University of Copenhagen. Peter Naur 1928 5/24 Software should following an engineering paradigm NATO conference in Garmisch-Partenkirchen, 1968 Peter Naur 1928 6/24 The hope is that the progress in hardware will cure all software ills. The Oberon System User Guide and Programmer's Manual. ACM Press Nationality;Swiss, electrical engineer, computer scientist ETH Zürich, IBM Zürich Research Laboratory, Institute for Media Communications Martin Reiser 7/24 However, a critical observer may notethat software manages to outgrow hardware in size and sluggishness. The Oberon System User Guide and Programmer's Manual. ACM Press Nationality;Swiss, electrical engineer, computer scientist ETH Zürich, IBM Zürich Research Laboratory, Institute for Media Communications Martin Reiser 8/24 Wirth's computing adage Software is getting slower more rapidly than hardware becomes faster. Nationality;Swiss, electronic engineer, computer scientist ETH Zürich, University of California, Berkeley, Stanford University University of Zurich. Xerox PARC.
  • Language-Parametric Methods for Developing

    Language-Parametric Methods for Developing

    Gabriël Ditmar Primo Konat was born in The Language-Parametric Methods for Developing Interactive Programming Systems Language-Parametric Methods for Developing Interactive Programming Hague, the Netherlands. In 2009, he received his BSc in Computer Science from the Institute of Ap- Invitation plied Sciences in Rijswijk. In 2012, he received his MSc in Computer Science from Delft University of Technology (TUDelft). From 2012 to 2018, he was Language-Parametric a Ph.D. student with the Programming Languages Methods for Developing group at TUDelft, under supervision of Eelco Viss- Interactive Programming er and Sebastian Erdweg. His work focuses on lan- Systems guage workbenches and incremental build systems. Gabriël Konat [email protected] You are cordially invited to the public defense of my dissertation on Monday, November 18th, 2019 at 3pm. At 2:30pm, I will give a brief presentation summarizing my dissertation. The defense will take place in the Senaatszaal of the Delft University of Technology Auditorium, Mekelweg 5, 2628 CC Delft, the Netherlands Afterwards, there will be a Gabriël Konat Language-Parametric Methods for reception. Developing Interactive Programming Systems Gabriël Konat Propositions accompanying the dissertation Language-Parametric Methods for Developing Interactive Programming Systems by Gabriël Ditmar Primo Konat 1. Language-parametric methods for developing interactive programming sys- tems are feasible and useful. (This dissertation) 2. Compilers of general-purpose languages must be bootstrapped with fixpoint bootstrapping. (This dissertation) 3. Manually implementing an incremental system must be avoided. (This dissertation) 4. Like chemists need lab assistants, computer scientists need software engineers to support them in research, teaching, and application in industry. 5.
  • Oral History Interview with John Brackett and Doug Ross

    Oral History Interview with John Brackett and Doug Ross

    An Interview with JOHN BRACKETT AND DOUG ROSS OH 392 Conducted by Mike Mahoney on 7 May 2004 Needham, Massachusetts Charles Babbage Institute Center for the History of Information Processing University of Minnesota, Minneapolis Copyright, Charles Babbage Institute John Brackett and Doug Ross Interview 7 May 2004 Oral History 392 Abstract Doug Ross and John Brackett focus on the background of SofTech and then its entry into the microcomputer software marketplace. They describe their original contact with the University of California at San Diego (UCSD) and licensing the p-System which had been developed there. They discuss the effort required to bring the program to production status and the difficulties in marketing it to the sets of customers. They talk about the transition from 8 bit to 16 bit machines and how that affected their market opportunities. They conclude with a review of the negotiations with IBM and their failure to get p-System to become a primary operating environment. That, and the high performance of Lotus 1-2-3, brought about the demise of the p- System. [John Brackett requested that the following information from Wikipedia, the free encyclopedia, be provided as an introduction to this oral history interview: “UCSD p-System or UCSD Pascal System was a portable, highly machine independent operating system based upon UCSD Pascal. The University of California, San Diego Institute for Information Systems developed it in 1978 to provide students with a common operating system that could run on any of the then available microcomputers as well as campus DEC PDP-11 minicomputers. UCSD p- System was one of three operating systems (along with PC-DOS and CP/M-86) that IBM offered for its original IBM PC.
  • Type Extensions, Wirth 1988

    Type Extensions, Wirth 1988

    Type Extensions N. WIRTH lnstitut fijr Informatik, ETH, Zurich Software systems represent a hierarchy of modules. Client modules contain sets of procedures that extend the capabilities of imported modules. This concept of extension is here applied to data types. Extended types are related to their ancestor in terms of a hierarchy. Variables of an extended type are compatible with variables of the ancestor type. This scheme is expressed by three language constructs only: the declaration of extended record types, the type test, and the type guard. The facility of extended types, which closely resembles the class concept, is defined in rigorous and concise terms, and an efficient implementation is presented. Categories and Subject Descriptors: D.3.3 [Programming Languages]: Language Constructs-data types and structures; modules, packuges; D.3.4 [Programming Languages]: Processors-code generation General Terms: Languages Additional Key Words and Phrases: Extensible data type, Modula-2 1. INTRODUCTION Modern software development tools are designed for the construction of exten- sible systems. Extensibility is the cornerstone for system development, for it allows us to build new systems on the basis of existing ones and to avoid starting each new endeavor from scratch. In fact, programming is extending a given system. The traditional facility that mirrors this concept is the module-also called package-which is a collection of data definitions and procedures that can be linked to other modules by an appropriate linker or loader. Modern large systems consist, without exception, of entire hierarchies of such modules. This notion has been adopted successfully by modern programming languages, such as Mesa [4], Modula-2 [8], and Ada [5], with the crucial property that consistency of interfaces be verified upon compilation of the source text instead of by the linking process.
  • Simulation Higher Order Language Requirements Study

    Simulation Higher Order Language Requirements Study

    DOCUMENT RESDEE ED .162 661 IB 066 666 AUTHOR Goodenough, John B.; Eraun, Christine I. TITLE Simulation Higher Order ,Language Reguiresents Study. INSTITUTION' SofTech, Inc., Waltham, Mass. SPONS'AGENCY Air Force Human Resources Lab., Broca_APE,' Texas. REPORT NO AFHPI-TE-78-34 PUB DATE ,Aug 78 NOTE 229.; Not available in hard' copy due to iarginal legibility of parts of document AVAILABLE FROM'Superintendent of Docusents, U.S. Government Printing' Office, Washington, L.C. 20402 (1978-771-122/53) EDRS PRICE MF-$0.83 Plus Postage. EC Not Availatle from EDRS. DESCRIPTORS *Comparative Analysis; Computer Assisted Instruction; *Computer Programs; Evaluation Criteria; Military Training; *Needs Assessment; *Prograaing Iangbaqes; *Simulation IDENTIFIERS FORTRAN; IRCNMAN; JOVIAL; PASCAL ABSTRACT The definitions provided for high order language (HOL) requirements for programming flight/ training simulators are based on the analysis of programs written fcr.a variety of simulators. Examples drawn from these programs are used to justify' the need for certain HOL capabilities. A description of the general 'K..structure and organization of the TRONEAN requirements for the DOI) Common Language effort IS followed-tyditailed specifications of simulator HOL requirements., pvi, FORTRAN, JCVIAI J3E, JCVIAL.J73I, and PASCAL are analyzed to see how well" each language satisfies the simulator HOL requirements. Results indicate that PL/I and JOVIAL J3D are the best suited for simulator programming, chile TOBIRANis clearly the least suitable language. All the larguages failed to satisfy some simulator requirements and improvement modificationsare specified Analysis of recommended modifications shows:that PL/I is the m st easily modified language. (CMV) *********************************************************************** Reproductions suppliid by EDRS are the best that can be made from the original dccumett.
  • Reception of Pascal in the History of Sciences

    Reception of Pascal in the History of Sciences

    Reception of Pascal in the history of sciences... Camille Akmut April 27, 2020 Abstract In particular computer science and technologies. With references to the history of philosophy and the social sciences. 1 I - Crown jewel computers, and sciences The computer scientist Niklaus Wirth, creator of the Pascal programming language, has said of the origins of his creation : I named it after the French philosopher and mathematician, who in 1642 designed one of the first gadgets that might truly be called a digital calculator.1 This is how Wirth remembered Pascal, and explained his choice of the philosopher for his namesake language in 1993 as part of a large conference organized by the ACM on the history of programming languages (the second HOPL); as a pioneer in a line from which { it is either implied, or we interpret too strongly { he ultimately descended. Another notable computer scientist, Friedrich Bauer, known for the stack ADT and his participation in the making of ALGOL 602 among others, in his 'Historical notes on computer science' (one of his last books, if not the last) expressed the following judgment on Pascal and Schickard : \We would not do Schickard any justice by exaggerating : his cal- culating machine was no 4-type ["Vier-Species"] machine, like that of Leibniz, but only a 2-type like Pascal's, but with the difference of having come twenty years earlier. Kepler was said to have been most happy with it. And, perhaps its mechanism was superior. But, that would be a detail."3 [trans.] Ergo : the real machine was Leibniz's { as it could (really) do all four operations of arithmetic { and as for the earlier, partial or lesser, ones Schickard's 1Found in History of programming languages, vol.
  • Evolution of the Major Programming Languages

    Evolution of the Major Programming Languages

    COS 301 Programming Languages Evolution of the Major Programming Languages UMaine School of Computing and Information Science COS 301 - 2018 Topics Zuse’s Plankalkül Minimal Hardware Programming: Pseudocodes The IBM 704 and Fortran Functional Programming: LISP ALGOL 60 COBOL BASIC PL/I APL and SNOBOL SIMULA 67 Orthogonal Design: ALGOL 68 UMaine School of Computing and Information Science COS 301 - 2018 Topics (continued) Some Early Descendants of the ALGOLs Prolog Ada Object-Oriented Programming: Smalltalk Combining Imperative and Object-Oriented Features: C++ Imperative-Based Object-Oriented Language: Java Scripting Languages A C-Based Language for the New Millennium: C# Markup/Programming Hybrid Languages UMaine School of Computing and Information Science COS 301 - 2018 Genealogy of Common Languages UMaine School of Computing and Information Science COS 301 - 2018 Alternate View UMaine School of Computing and Information Science COS 301 - 2018 Zuse’s Plankalkül • Designed in 1945 • For computers based on electromechanical relays • Not published until 1972, implemented in 2000 [Rojas et al.] • Advanced data structures: – Two’s complement integers, floating point with hidden bit, arrays, records – Basic data type: arrays, tuples of arrays • Included algorithms for playing chess • Odd: 2D language • Functions, but no recursion • Loops (“while”) and guarded conditionals [Dijkstra, 1975] UMaine School of Computing and Information Science COS 301 - 2018 Plankalkül Syntax • 3 lines for a statement: – Operation – Subscripts – Types • An assignment
  • ALGOL 60 Programming on the Decsystem 10.Pdf

    ALGOL 60 Programming on the Decsystem 10.Pdf

    La Trobe University DEPARTMENT OF MATHEMATICS ALGOL 60 Programming on the DECSystem 10 David Woodhouse Revised, August 1975 MELBOURNE, AUSTRALIA ALGOL 60 Programming on the DECSystem 10 David Woodhouse Revised, August 1975 CE) David Woodhouse National Library of Australia card number and ISBN. ISBN 0 85816 066 8 INTRODUCTION This text is intended as a complete primer on ALGOL 60 programming. It refers specifically to Version 4 of the DECSystem 10 implementation. However, it avoids idiosyncracies as far as possible, and so should be useful in learning the language on other machines. The few features in the DEC ALGOL manual which are not mentioned here should not be needed until the student is sufficiently advanced to be using this text for reference only. Exercises at the end of each chapter illustrate the concepts introduced therein, and full solutions are given. I should like to thank Mrs. K. Martin and Mrs. M. Wallis for their patient and careful typing. D. Woodhouse, February, 1975. CONTENTS Chapter 1 : High-level languages 1 Chapter 2: Languagt! struct.ure c.f ALGOL 6n 3 Chapter 3: Statemp.nts: the se'1tences {'\f the language 11 Chapter 4: 3tandard functions 19 Chapter 5: Input an~ Outp~t 21 Chapter 6: l>rray~ 31 Chapter 7 : For ane! ~hil~ statements 34 Chapter 8: Blocks anr! ',: ock sc rll,~ turr. 38 Chapter 9: PrOCe(:l1-:-~S 42 Chapter 10: Strin2 vp·jaLlps 60 Chapter 11: Own v~rj;lI'.i..es clOd s~itc.hef, 64 Chapter 12: Running ~nd ,;ebllggi"1g 67 Bibliography 70 Solutions to Exercises 71 Appendix 1 : Backus NOlUlaj F\:q'm 86 Appendix 2 : ALGuL-like languages 88 Appenclix 3.