Algol After FORTRAN Implementations Algol Report Algol's Objectives

Total Page:16

File Type:pdf, Size:1020Kb

Algol After FORTRAN Implementations Algol Report Algol's Objectives 9/19/13 After FORTRAN • International language is needed – 1964: New language is proposed to break Algol away from platform dependence – Preliminary spec: NPL (new programming language), then PL/I (programming CS4100 language 1) From Principles of Programming Languages: Design, Evaluation, and Implementation (Third Edition), by – PL/I is too big Bruce J. MacLennan, Chapters 3and 4, and based on • Dijkstra: If Fortran is an infantile disorder, then slides by Istvan Jonyer. PL/I is a fatal disease • Trying to be everything to everyone backfires 1 2 Chapter 3: Generality and Implementations Hierarchy: ALGOL-60 • Because of the hype, many started • An international language is needed implementation quickly – This resulted in many dialects – A single, universal language would be – JOVIAL (Jules’ Own Version of the International valuable Algebraic Language) – International (American and European) • Committee meets again in 1960 to committee is set up to make incorporate suggestions recommendations – Algol-60 is born and is very different from the ’58 report. – Algol-58 is created in 8 days in Zurich, as a – Report is 17 pages long: remarkable achievement, preliminary report mainly due to BNF notation (reports used to – Algol: Algorithmic Language stretch to hundreds or thousands of pages) 3 4 Algol Report Algol’s Objectives • 1959 UNESCO Conference on Information Processing • The language should be very close to – Backus presents a description of Algol ‘58 • Uses formal syntax he developed mathematical notation – Naur is editor of Algol Bulletin • Should be useful in publications to • Disagrees with some of Backus’ interpretation • Need for more precise description describe algorithms • Develops a variant of Backus’ formal syntax • Mechanically translatable to machine Backus-Naur Form, aka BNF used for 1960 Algol code Report 5 6 1 9/19/13 Structural Organization Constructs • Declarative or Imperative • Hierarchically structured language – (like in FORTRAN) – Nesting is introduced (Fortran did not use nesting) • Variable declarations – Control structures can also be nested – Types: integer, real, Boolean integer i, j, k • One can be made the body of the other – Lower bounds of arrays need not be 1 if N > 0 then real array Data[-50:50] for i := 1 step 1 until N do – Switch, like FORTRAN’s computed GOTO sum := sum + Data[i] • Subprogram declarations • Advantage: decreases the number of GOTOs required – Keyword: procedure and – Procedures can be typed (functions) and untyped • Reserved words real procedure dist(x1, y1, x2, y2); real x1, y1, x2, y2; dist = sqrt((x1 – x2)^2 + (y1 – y2)^2) 7 8 Imperative Constructs Imperative Constructs • Computational • Control-flow – Assignment: “variable := expression” – All imperative constructs alter flow of – Operators: control (except assignment) • Arithmetic: +, -, *, etc. – Has if-then-else • Relational: =, <, >, ≥, etc. – for-loop replaces do-loop • Logic: ∧, ∨, ¬, etc. – Why is assignment ‘:=’ and not ‘=’? • No input/output constructs • Assignment is different from definition and – I/O was left to be handled by platform- comparison dependent library calls • I = I + 1 ; I := I + 1 9 10 Name Structures Syntax - Program • Algol-60 introduces the compound statement • <program> ::= <block> | <compound statement> – Where 1 statement is allowed, more can be used, using begin-end • <block> ::= <unlabelled block> | <label>: <block> for i := 1 step 1 until N do • <compound statement> ::= <unlabelled compound> | <label>: sum := sum + Data[i] <compound statement> for i := 1 step 1 until N do • <unlabelled compound> ::= begin begin <compound tail> sum := sum + Data[i]; • <unlabelled block> ::= Print Real (sum) <block head> ; <compound tail> end – Also, the body of a procedure is a single statement 11 12 2 9/19/13 Syntax - Statement Syntax - Block • <compound statement> ::= <unlabelled compound> | <label>: <compound statement> • <block> ::= <unlabelled block> | • <unlabelled compound> ::= begin <compound tail> <label>: <block> • <compound tail> ::= <statement> end | <statement> ; <compound tail> • <unlabelled block> ::= • <statement> ::= <unconditional statement> | <conditional statement> | <block head> ; <compound tail> <for statement> • <block head> ::= begin <declaration> | • <unconditional statement> ::= <basic statement> | <compound statement> | <block> <block head> ; <declaration> • <basic statement> ::= <unlabelled basic statement> | • <compound tail> ::= <statement> end | <label>: <basic statement> <statement> ; <compound tail> • <unlabelled basic statement> ::= <assignment statement> | <go to statement> | <dummy statement> | <procedure statement> 13 14 Blocks Define Nested Scopes Name Binding • Fortran • Fortran binds a variable to a single memory – Had local and global declarations only location statically – Had to redeclare using COMMON to share • Algol-60 included the results of research done • Algol-60 on name structures, which were problematic – Introduces blocks in Fortran begin – Sharing of data between subprograms declarations; – Parameter passing modes statements end – Return values – Compound statements do not have ‘declarations’. – Dynamic arrays – All declarations are visible to all statements in the block • Result of research: block structure – Since statements can be blocks, scopes can be nested 15 16 Why do we need scopes? “COMMON” with Blocks • Reduce the context programmers have to keep in • The error-prone COMMON in Fortran can be mind implemented in a much better way using • Make understanding and maintenance of program blocks easier begin • Scopes reduce visibility of names integer array Name, Loc, Type[1:100]; procedure Lookup (n); – Declare variable only where needed and used . Lookup procedure . • Nested blocks inherit names from outside procedure Var (n, l, t); – It would be very inconvenient if they did not . Var procedure . procedure Array1 (n, l, t, dim1); . Array1 procedure . end 17 18 3 9/19/13 Too Much Access Contour Diagrams • Blocks provide “indiscriminate access” • Inner blocks implicitly inherit access to all variable in immediately surrounding block – Since functions must be accessible to • Names declared in a block are local to the block users, • Names declared in surrounding blocks are nonlocal – and data structures must be accessible to • Names declared in outermost block are global functions – à Data is also accessible to users • Violates information hiding principle 19 20 Contour Diagrams Dynamic vs Static Scoping • See Figure 3.3, page 102 • Static scoping – Procedure is called in the context of its declaration • Do Exercise 3-1, page 104 • Environment of Definition – Scope structure is determined at compile-time – Algol • Dynamic scoping – Procedure is called in the context of its caller • Environment of Caller – Scope structure is determined at run-time – LISP 21 22 Example Dynamic Scopes and Functions • Draw static contour diagram • Draw dynamic contour diagram for both calls to P • Dynamic scoping applies to all names (not just a:begin variables) integer m outer m procedure P • Advantage: m := 1; – We can write a general procedure that makes use of b:begin procedures in the caller’s environment integer m; inner m • No need to have all names defined in static context P inner call • Disadvantage: end – If caller’s environment provides a different function than P outer call what is intended to be used (see example page 109) end • Programmer has to think about envt when writing calls 23 24 4 9/19/13 Blocks Permit Which one is better? Efficient Storage Management • General rule: • Fortran used EQUIVALENCE – What is natural to humans will cause less problems in the – Not safe, since there is no guarantee of exclusive use of long run memory – If humans can understand static scoping better, than it will • Blocks permit reuse of memory result in higher quality programs in the long run a:begin integer m, n; • Dynamic scoping is confusing b:begin real array X[1:100], real y; – Generally rejected (not used in new languages) ... – Static scoping agrees more with the program’s dynamic end behavior ... c:begin integer k; real array M[0:50]; ... end 25 end 26 Run-Time Stacks Example • Variables in blocks b and c are never used at the same time • From previous program • When exiting b, its variables may be discarded y • Notice: Block entered last will be exited first M – LIFO (last-in first-out) order X – Can use a stack to organize activation records k – When block is entered, its AR is pushed onto stack n n n – When block is exited, its AR is popped off stack n n enter (a) enter (b) m exit (b) enter (c) m exit (c) m exit (a) – Assumption: No local variables are initialized m m … … … … … 27 28 Responsible Design Principles of Programming • Algol designers did not include • The Responsible Design Principle EQUIVALENCE – Do not ask programmers what they want, – Programmers might have asked for it… find out what they need. – Instead, they looked at the root of the problem – “Don’t ask what they want, ask how the problem arises” – Language designers are responsible for the features in the language, not programmers 29 30 5 9/19/13 Data Structures Why no complex? • Primitives • Not primitive – Mathematical scalars, like in Fortran – Can be constructed using other types easily (2 reals) – integer, real, Boolean • Is it easy to use reals for complex? – complex and double not included – Yes, but inconvenient • Double: platform dependent – Need supporting operations – Not portable • ComplexAdd(x, y, z), etc. – Why? Because we need to know the size of a • Designers’ choice:
Recommended publications
  • Typology of Programming Languages E Early Languages E
    Typology of programming languages e Early Languages E Typology of programming languages Early Languages 1 / 71 The Tower of Babel Typology of programming languages Early Languages 2 / 71 Table of Contents 1 Fortran 2 ALGOL 3 COBOL 4 The second wave 5 The finale Typology of programming languages Early Languages 3 / 71 IBM Mathematical Formula Translator system Fortran I, 1954-1956, IBM 704, a team led by John Backus. Typology of programming languages Early Languages 4 / 71 IBM 704 (1956) Typology of programming languages Early Languages 5 / 71 IBM Mathematical Formula Translator system The main goal is user satisfaction (economical interest) rather than academic. Compiled language. a single data structure : arrays comments arithmetics expressions DO loops subprograms and functions I/O machine independence Typology of programming languages Early Languages 6 / 71 FORTRAN’s success Because: programmers productivity easy to learn by IBM the audience was mainly scientific simplifications (e.g., I/O) Typology of programming languages Early Languages 7 / 71 FORTRAN I C FIND THE MEAN OF N NUMBERS AND THE NUMBER OF C VALUES GREATER THAN IT DIMENSION A(99) REAL MEAN READ(1,5)N 5 FORMAT(I2) READ(1,10)(A(I),I=1,N) 10 FORMAT(6F10.5) 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 20 CONTINUE WRITE (2,25) MEAN,NUMBER 25 FORMAT(11H MEAN = ,F10.5,5X,21H NUMBER SUP = ,I5) STOP TypologyEND of programming languages Early Languages 8 / 71 Fortran on Cards Typology of programming languages Early Languages 9 / 71 Fortrans Typology of programming languages Early Languages 10 / 71 Table of Contents 1 Fortran 2 ALGOL 3 COBOL 4 The second wave 5 The finale Typology of programming languages Early Languages 11 / 71 ALGOL, Demon Star, Beta Persei, 26 Persei Typology of programming languages Early Languages 12 / 71 ALGOL 58 Originally, IAL, International Algebraic Language.
    [Show full text]
  • 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.
    [Show full text]
  • BASIC Session
    BASIC Session Chairman: Thomas Cheatham Speaker: Thomas E. Kurtz PAPER: BASIC Thomas E. Kurtz Darthmouth College 1. Background 1.1. Dartmouth College Dartmouth College is a small university dating from 1769, and dedicated "for the educa- tion and instruction of Youth of the Indian Tribes in this Land in reading, writing and all parts of learning . and also of English Youth and any others" (Wheelock, 1769). The undergraduate student body (now nearly 4000) outnumbers all graduate students by more than 5 to 1, and majors predominantly in the Social Sciences and the Humanities (over 75%). In 1940 a milestone event, not well remembered until recently (Loveday, 1977), took place at Dartmouth. Dr. George Stibitz of the Bell Telephone Laboratories demonstrated publicly for the first time, at the annual meeting of the American Mathematical Society, the remote use of a computer over a communications line. The computer was a relay cal- culator designed to carry out arithmetic on complex numbers. The terminal was a Model 26 Teletype. Another milestone event occurred in the summer of 1956 when John McCarthy orga- nized at Dartmouth a summer research project on "artificial intelligence" (the first known use of this phrase). The computer scientists attending decided a new language was needed; thus was born LISP. [See the paper by McCarthy, pp. 173-185 in this volume. Ed.] 1.2. Dartmouth Comes to Computing After several brief encounters, Dartmouth's liaison with computing became permanent and continuing in 1956 through the New England Regional Computer Center at MIT, HISTORY OF PROGRAMMING LANGUAGES 515 Copyright © 1981 by the Association for Computing Machinery, Inc.
    [Show full text]
  • 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.
    [Show full text]
  • Die Gruncllehren Cler Mathematischen Wissenschaften
    Die Gruncllehren cler mathematischen Wissenschaften in Einzeldarstellungen mit besonderer Beriicksichtigung der Anwendungsgebiete Band 135 Herausgegeben von J. L. Doob . E. Heinz· F. Hirzebruch . E. Hopf . H. Hopf W. Maak . S. Mac Lane • W. Magnus. D. Mumford M. M. Postnikov . F. K. Schmidt· D. S. Scott· K. Stein Geschiiftsfiihrende Herausgeber B. Eckmann und B. L. van der Waerden Handbook for Automatic Computation Edited by F. L. Bauer· A. S. Householder· F. W. J. Olver H. Rutishauser . K. Samelson· E. Stiefel Volume I . Part a Heinz Rutishauser Description of ALGOL 60 Springer-Verlag New York Inc. 1967 Prof. Dr. H. Rutishauser Eidgenossische Technische Hochschule Zurich Geschaftsfuhrende Herausgeber: Prof. Dr. B. Eckmann Eidgenossische Tecbnische Hocbscbule Zurich Prof. Dr. B. L. van der Waerden Matbematisches Institut der Universitat ZUrich Aile Rechte, insbesondere das der Obersetzung in fremde Spracben, vorbebalten Ohne ausdriickliche Genehmigung des Verlages ist es auch nicht gestattet, dieses Buch oder Teile daraus auf photomechaniscbem Wege (Photokopie, Mikrokopie) oder auf andere Art zu vervielfaltigen ISBN-13: 978-3-642-86936-5 e-ISBN-13: 978-3-642-86934-1 DOl: 10.1007/978-3-642-86934-1 © by Springer-Verlag Berlin· Heidelberg 1967 Softcover reprint of the hardcover 1st edition 1%7 Library of Congress Catalog Card Number 67-13537 Titel-Nr. 5l1B Preface Automatic computing has undergone drastic changes since the pioneering days of the early Fifties, one of the most obvious being that today the majority of computer programs are no longer written in machine code but in some programming language like FORTRAN or ALGOL. However, as desirable as the time-saving achieved in this way may be, still a high proportion of the preparatory work must be attributed to activities such as error estimates, stability investigations and the like, and for these no programming aid whatsoever can be of help.
    [Show full text]
  • An Interview with Tony Hoare ACM 1980 A.M. Turing Award Recipient
    1 An Interview with 2 Tony Hoare 3 ACM 1980 A.M. Turing Award Recipient 4 (Interviewer: Cliff Jones, Newcastle University) 5 At Tony’s home in Cambridge 6 November 24, 2015 7 8 9 10 CJ = Cliff Jones (Interviewer) 11 12 TH = Tony Hoare, 1980 A.M. Turing Award Recipient 13 14 CJ: This is a video interview of Tony Hoare for the ACM Turing Award Winners project. 15 Tony received the award in 1980. My name is Cliff Jones and my aim is to suggest 16 an order that might help the audience understand Tony’s long, varied, and influential 17 career. The date today is November 24th, 2015, and we’re sitting in Tony and Jill’s 18 house in Cambridge, UK. 19 20 Tony, I wonder if we could just start by clarifying your name. Initials ‘C. A. R.’, but 21 always ‘Tony’. 22 23 TH: My original name with which I was baptised was Charles Antony Richard Hoare. 24 And originally my parents called me ‘Charles Antony’, but they abbreviated that 25 quite quickly to ‘Antony’. My family always called me ‘Antony’, but when I went to 26 school, I think I moved informally to ‘Tony’. And I didn’t move officially to ‘Tony’ 27 until I retired and I thought ‘Sir Tony’ would sound better than ‘Sir Antony’. 28 29 CJ: Right. If you agree, I’d like to structure the discussion around the year 1980 when 30 you got the Turing Award. I think it would be useful for the audience to understand 31 just how much you’ve done since that award.
    [Show full text]
  • CSE452 Fall2004 (Cheng)
    CSE452 Fall2004 (Cheng) Organization of Programming Languages (CSE452) Instructor: Dr. B. Cheng Fall 2004 Organization of Programming Languages-Cheng (Fall 2004) 1 Evolution of Programming Languages ? Purpose: to give perspective of: ? where we’ve been, ? where we are, and ? where we might be going. ? Take away the mystery behind programming languages ? Fun lecture. ? Acknowledgements: R. Sebesta Organization of Programming Languages-Cheng (Fall 2004) 2 Genealogy of Common Languages Organization of Programming Languages-Cheng (Fall 2004) 3 1 CSE452 Fall2004 (Cheng) History of Programming Languages http://www.webopedia.com/TERM/P/programming_language.html Organization of Programming Languages-Cheng (Fall 2004) 4 Zuse’s Plankalkül - 1945 ? Never implemented ? Advanced data structures ? floating point, arrays, records ? Invariants Organization of Programming Languages-Cheng (Fall 2004) 5 Evolution of software architecture ? 1950s - Large expensive mainframe computers ran single programs (Batch processing) ? 1960s - Interactive programming (time-sharing) on mainframes ? 1970s - Development of Minicomputers and first microcomputers. Apple II. Early work on windows, icons, and PCs at XEROX PARC ? 1980s - Personal computer - Microprocessor, IBM PC and Apple Macintosh. Use of windows, icons and mouse ? 1990s - Client-server computing - Networking, The Internet, the World Wide Web Organization of Programming Languages-Cheng (Fall 2004) 6 2 CSE452 Fall2004 (Cheng) Pseudocodes - 1949 ? What was wrong with using machine code? ? Poor readability ?
    [Show full text]
  • W-5835 E TABLE of CONTENTS (CONT'd~)
    I - THE MITRE CORPORATION Working Paper W- 5835 aedford, Massachusetts Sheet 1 of 26 Sheets 1.1 Subject: BIBLIOGR,\PHY OF XD-1 DOCt.MENTATION (U) i (Project 220) To: Distribution List From: XD-1 Facility Office Dept: Issued at: Bedford, Massachusetts ', .....- . Date: �.o.?��.· Approved:_�-.,.+-.....;....__ _.._._ ..___ ·.·. _______ -=-_;--:aa...._____.. � J. A. Ishihara Contract No. AF-19 ( 628) 2390 - Release to: Distribution List ABSTRACT A reasonably complete and accurate bibliographical listing of XD-1 documentation has been compiled by t.he XD-1 Facility Office. '.Illi::J bibliography has b�en arranged both by subject and by document number. A SUQject listing and a numerical listing is �.nclu,d.ed in this docu.ment. A third listing, con­ tain:t,ng abstracts of each document, has been com­ piled and is also }ncluded in the document·. t' ·j Approved for public release. Distribution unlimited. 18-0742. © 2018 The MITRE Corporation. All rights reserved. AF Case number: 2018-0541 This.Working Poper, prepared for Corporation internal use, does not represent a corporate position, Reproduction or further dissemination is not authorh:ed, It has not been reviewed by Office of Secu�ity Review, Deparmient. of Defense, and therefore - is not for public release. TABLE OF. CONTENTS Page 1.0 Introduction............. 1 2.0 Subject Listing.of XD-.l· Documentation" . 2 2.1 Facility Office Information 2 2.2 Operational Procedures. 2 2.3 Accounting; 2 2.4 Programming Information 2 2.5 Equipment Checkout Program Systems. 2 2.6 Facility Program Systems. 3 2·7 utility Program Systems .
    [Show full text]
  • Concepts of Programming Languages, Eleventh Edition, Global Edition
    GLOBAL EDITION Concepts of Programming Languages ELEVENTH EDITION Robert W. Sebesta digital resources for students Your new textbook provides 12-month access to digital resources that may include VideoNotes (step-by-step video tutorials on programming concepts), source code, web chapters, quizzes, and more. Refer to the preface in the textbook for a detailed list of resources. Follow the instructions below to register for the Companion Website for Robert Sebesta’s Concepts of Programming Languages, Eleventh Edition, Global Edition. 1. Go to www.pearsonglobaleditions.com/Sebesta 2. Click Companion Website 3. Click Register and follow the on-screen instructions to create a login name and password Use a coin to scratch off the coating and reveal your access code. Do not use a sharp knife or other sharp object as it may damage the code. Use the login name and password you created during registration to start using the digital resources that accompany your textbook. IMPORTANT: This access code can only be used once. This subscription is valid for 12 months upon activation and is not transferable. If the access code has already been revealed it may no longer be valid. For technical support go to http://247pearsoned.custhelp.com This page intentionally left blank CONCEPTS OF PROGRAMMING LANGUAGES ELEVENTH EDITION GLOBAL EDITION This page intentionally left blank CONCEPTS OF PROGRAMMING LANGUAGES ELEVENTH EDITION GLOBAL EDITION ROBERT W. SEBESTA University of Colorado at Colorado Springs Global Edition contributions by Soumen Mukherjee RCC Institute
    [Show full text]
  • THE DEVELOPMENT of JOVIAL Jules L Schwartz Computer
    THE DEVELOPMENT OF JOVIAL Jules L Schwartz Computer Sciences Corp. 1. THE BACKGROUND One of the significant things that got the JOVIAL lan- guage and compiler work started was an article on 1.1 The Environmental and Personnel Setting Expression Analysis that appeared in the 1958 ACM Communications (Wolpe 1958). The fact that this was The time was late 1958. Computers that those who were actually quite a revelation to us at that time seems involved with the first JOVIAL project had been using interesting now. Since that day, of course, there have included the JOHNNIAC (built at Rand Corporation), the been many developments in the parsing of mathematical IBM AN/FSQ-7 (for SAGE), 701, and 704. A few had and logical expressions. However, that article was the worked with board wired calculators. Some had never first exposure many of us had to the subject. Some of programmed. For those using IBM, the 709 was the us who had just finished work on some other projects current machine. There were various other manufactur- (including SAGE) began experimentation with the proc- ers at the time, some of whom do not exist today as essing of complex expressions to produce an interme- computer manufacturers. diate language utilizing the techniques described. There was no compiler language at the time in our plans, but The vacuum tube was still in vogue, Very large memo- the idea of being able to understand and parse complex ries, either high speed direct access or peripheral expressions in itself was of sufficient interest to moti- storage, didn't exist, except for magnetic tape and vate our efforts.
    [Show full text]
  • Exploring Languages with Interpreters and Functional Programming Chapter 2
    Exploring Languages with Interpreters and Functional Programming Chapter 2 H. Conrad Cunningham 25 September 2018 Contents 2 Programming Paradigms 2 2.1 Chapter Introduction . .2 2.2 Abstraction . .2 2.2.1 What is abstraction? . .2 2.2.2 Kinds of abstraction . .3 2.2.3 Procedures and functions . .3 2.3 What is a Programming Paradigm? . .4 2.4 Imperative Paradigm . .4 2.5 Declarative Paradigm . .6 2.5.1 Functional paradigm . .6 2.5.2 Relational (or logic) paradigm . .8 2.6 Other Programming Paradigms . .9 2.6.1 Procedural paradigm . 10 2.6.2 Modular paradigm . 11 2.6.3 Object-based paradigms . 13 2.6.4 Concurrent paradigms . 13 2.7 Motivating Functional Programming: John Backus . 13 2.7.1 Excerpts from Backus’s Turing Award Address . 13 2.7.2 Aside on the disorderly world of statements . 16 2.7.3 Perspective from four decades later . 16 2.8 What Next? . 16 2.9 Exercises . 17 2.10 Acknowledgements . 17 2.11 References . 18 2.12 Terms and Concepts . 18 Copyright (C) 2016, 2017, 2018, H. Conrad Cunningham Professor of Computer and Information Science 1 University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Browser Advisory: The HTML version of this textbook requires a browser that supports the display of MathML. A good choice as of September 2018 is a recent version of Firefox from Mozilla. 2 2 Programming Paradigms 2.1 Chapter Introduction The goals of this chapter are to: • introduce the concepts of procedural and data abstraction • examine the characteristics and concepts the primary programming paradigms, imperative and declarative (including functional and relational) • survey other paradigms such as procedural and modular programming 2.2 Abstraction Programming concerns the construction of appropriate abstractions in a pro- gramming language.
    [Show full text]
  • Comparative Programming Languages CM20253
    We have briefly covered many aspects of language design And there are many more factors we could talk about in making choices of language The End There are many languages out there, both general purpose and specialist And there are many more factors we could talk about in making choices of language The End There are many languages out there, both general purpose and specialist We have briefly covered many aspects of language design The End There are many languages out there, both general purpose and specialist We have briefly covered many aspects of language design And there are many more factors we could talk about in making choices of language Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important For example, can you easily join together code written in Java and C? The End Or languages And then the interopability of languages becomes important For example, can you easily join together code written in Java and C? The End Or languages Often a single project can use several languages, each suited to its part of the project For example, can you easily join together code written in Java and C? The End Or languages Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important The End Or languages Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important For example, can you easily
    [Show full text]