COEN 171

1. COEN 171 Programming Languages Winter 2000 Ron Danielson

2. Coen 171 - Fundamentals • Overview of course • syllabus • assignments • Background survey • language experience • relevant courses • Motivation • Programming domains and language types • Evaluating programming languages • Influences on programming language design • Translation • Programming environments • Programming language history

3. Why Study Programming Languages? • Increased capacity to express programming concepts • Better able to select a language to solve a problem • Better able to learn and use a new programming language • Better able to understand the impact of other features (e.g., architecture) on a language • and vice versa

4. Why Study Programming Languages? (continued) • Greater understanding of significant implementation issues • Culture • programming languages have impact on almost everything about computing • Lots of opportunities to design small languages

5. Programming Domains • Scientific applications • execution efficiency, numerical accuracy • Business applications • decimal data types, I/O editing, record structures • Artificial intelligence • symbol manipulation, programs as data • Systems programming • efficiency, access to hardware features • Very high-level languages • perl, tcl/tk, PowerBuilder • Special purpose languages • RPG, GPSS

6. Basic Models of PL Design • Imperative • command driven, computer oriented • C, Pascal, Ada, etc. • OO (Smalltalk, C++, Java) as a subset • Functional • apply functions to arguments • process oriented • LISP • Declarative or relational • logical description of problem • specification, not process • Prolog

7. Criteria for Evaluating PLs - Design Reflects Tradeoffs • Readability (understandability) • simplicity • too many features • > 1 feature for same purpose • orthogonality • small number of primitives which can be combined in a relatively small number of ways • learning and use easier • ALGOL 68, LISP • control statements • enough for expressibility, not too many

8. Criteria for Evaluating PLs - Design Reflects Tradeoffs (continued) • Reliability (continued) • data types and structures • ditto • syntax • uniformity and expressiveness • Writeability • simplicity and orthogonality • abstraction mechanisms • expressibility

9. Criteria for Evaluating PLs - Design Reflects Tradeoffs (continued) • Reliability • type checking • mechanisms to minimize aliasing • exception handling • Cost • learning • program development • compilation • execution • maintenance • portability

10. Influences on PL Design • Computer architecture • vonNeumann architecture • parallel and network environments • PROLOG machines • Programming methodologies and paradigms • machine vs. human efficiency • shift from process to data orientation • data abstraction, object-oriented • concurrency

11. Influences on PL Design (continued) • Trade-offs • reliability vs. cost of execution • bounds checking • writability vs. readability • APL • flexibility vs. safety • strong type checking (e.g., Ada)

12. Fundamental Concepts for Describing PLs • Syntax • what is a grammatically correct construct • Semantics • what is the meaning of a PL statement • We separate these for discussion purposes, but they are closely related • the semantics should follow from the syntax • both are often intertwined in translators

13. Kinds of Translators • Compilers • translate source code into machine code one time and the machine code executes • Interpreters • translate each source code statement every time it executes • Hybrid systems • translate the source code into a simpler form once, then interpret the translated form • Compilers provide code that executes rapidly, interpreters provide flexibility

14. Compilation Process Source Program Lexical Analysis lexical units Symbol Table Syntax Syntax Analysis parse trees Optimization Intermediate Code Gen Semantics int. text Code Generation machine code Object Program

15. Lexical Analysis • Breaks input stream into tokens • reserved words • keywords • identifiers • operators • punctuation

16. Lexical Analysis (continued) • Information about tokens kept in symbol table • may contain • text string, type, location • block • number subscripts, upper/lower bounds • token is then represented as pointer to symbol table • syntax, semantics, code gen all use symbol table • requires easy insertion/deletion, rapid search

17. Syntax Analysis • Generated from grammar describing PL • Verifies correct syntax, produces internal representation • build parse trees • Two basic approaches • bottom up • start with tokens, reduce to nonterminals, continue until find start symbol • LR(k) • top down • begin with start symbol, guess at production applied, continue until terminal string produced • LL(k)

18. (Static) Semantic Analysis • Enters information in symbol table • Checks that symbol table information meets constraints of use • type compatibility, number of subscripts, number of parameters • Generate intermediate text • equivalent to assembly language • postfix, n-tuples, abstract parse trees • Associate semantic actions with productions in grammar • like attribute grammar

19. Optimization and Code Generation • Optimization • can occur on intermediate text or generated code • analyzes • redundant operations • code movement out of loop • unreachable blocks • takes advantage of target architecture • parallelism, superscalar • Code Generation • depends on target machine architecture • find patterns in intermediate text, match with templates, produce corresponding machine code • can produce machine code, assembly, high-level language (preprocessor)

20. Programming Environments • Editors • Debuggers • Version control systems • File systems • Test generators • Windows systems

21. PL History • First wave • Fortran (1957) • Algol-60 (1958 - 62) • Cobol (1960 - 62) • LISP (1958) • Second wave • PL/I (1964 - 65) • Algol-68

22. PL History (continued) • Third wave • Pascal (1971 - 73) • C (1972) • Prolog (1971 - 75) • Fourth wave • Smalltalk (1972 - 80) • Ada (1975 - 83) • C++ (1985) • Ada 95 (1988 - 95) • Java (1995)