(1.1)

COEN 171

Programming Languages

Winter 2000

Ron Danielson

(1.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

(1.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

(1.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

(1.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

(1.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

(1.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

(1.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

(1.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

(1.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

(1.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)

(1.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

(1.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

(1.14)Compilation Process

Source Program

Lexical Analysis

Syntax Analysis

Intermediate Code Gen

Code Generation

Object Program

Optimization

lexical units

parse trees

int. text

machine code

Syntax

Semantics

Symbol Table

(1.15)Lexical Analysis

Breaks input stream into tokens– reserved words–keywords– identifiers–operators–punctuation

(1.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

(1.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)

(1.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

(1.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)

(1.20)Programming Environments

Editors Debuggers Version control systems File systems Test generators Windows systems

(1.21)PL History

First wave–Fortran (1957)–Algol-60 (1958 - 62)–Cobol (1960 - 62)– LISP (1958)

Second wave–PL/I (1964 - 65)–Algol-68

(1.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)