Programming Paradigms- Chapter-1

Concepts of Programming Languages

by
Robert W. Sebesta -Addison Wesley (2005)

Refer to complete Chapter-1

Robert W. Sebesta - Concepts of Programming Languages-Addison Wesley (2005)
Pages: 1- 20 and 25 to 33
Table of contents

Overview of Programming Languages

Domains
Language evaluation
Criteria and Introduction to compilation methods.
 Overview of Programming Languages

Reasons to study concepts of PLs

1. Increased capacity to express programming concepts

2. Improved background for choosing appropriate languages

3. Increased ability to learn new languages

4. Understanding the significance of implementation

5. Increased ability to design new languages

6. Overall advancement of computing

1. Increased capacity to express ideas. It is widely believed that the
depth at which people can think is influenced by the expressive power of
the language in which they communicate their thoughts.
2. Improved background for choosing appropriate languages. Some
professional programmers have had little formal education in computer
science; rather, they have developed their programming skills
independently or through in-house training programs.
3.Increased ability to learn new languages. Computer programming is still
a relatively young discipline, and design methodologies, software
development tools, and programming languages are still in a state of
continuous evolution.
4. Better understanding of the significance of implementation: In
learning the concepts of programming languages, it is both interesting
and necessary to touch on the implementation issues that affect those
concepts
5. Better use of languages that are already known. Most
contemporary programming languages are large and complex.
6. Overall advancement of computing. Finally, there is a global view of
computing that can justify the study of programming language concepts.
Programming Domains
● 1. Scientific applications
● 2. Business applications
● 3. Artificial intelligence
● 4. Systems programming
● 5. Scripting languages
● 6. Special purpose languages
Scientific Applications:The first digital computers, which appeared
in the late 1940s and early 1950s, were invented and used for scientific
applications.
---Typically, the scientific applications of that time used relatively
simple data structures, but required large numbers of floating- point
arithmetic computations.
-The first language for scientific applications was Fortran. ALGOL 60
and most of its descendants were also intended to be used in this area,
although they were designed to be used in related areas as well.
Programming Domains

Business Applications: The use of computers for

business applications began in the 1950s.
-Special computers were developed for this purpose, along
with special languages. The first successful high-level
language for business was COBOL (ISO/IEC, 2002), the
initial version of which appeared in 1960
Programming Domains

Artificial Intelligence: Artificial intelligence (AI) is a broad

area of computer applications characterized by the use of
symbolic rather than numeric computations.
Symbolic computation means that symbols, consisting of names
rather than numbers, are manipulated.
Also, symbolic computation is more conveniently done with
linked lists of data rather than arrays.
Programming Domains
Web Software: The World Wide Web is supported by an
eclectic collection of languages, ranging from markup
languages, such as HTML, which is not a programming
language, to general-purpose programming languages, such as
Java.
This functionality can be provided by embedding programming
code in an HTML document. Such code is often in the form of a
scripting language, such as JavaScript or PHP .
Language Evaluation Criteria
Readability: One of the most important criteria for judging a
programming language is the ease with which programs can be read
and understood.
 Language Evaluation Criteria
1. Readability - The most important criterium
- Factors:
- Overall simplicity
- Too many features is bad
- Multiplicity of features is bad
- Orthogonality (Orthogonality in a programming language means that a relatively small set of primitive constructs can be combined in a relatively small number
of ways to build the control and data structures of the language. It is associated with simplicity; the more orthogonal the design, the fewer exceptions
operations change just one thing without affecting others.

- Makes the language easy to learn and read

- Meaning is context independent
- Control statements
- Data type and structures
- Syntax considerations
 Language Evaluation Criteria
1.1 Overall Simplicity: The overall simplicity of a programming language strongly affects
its readability.
1.2 Orthogonality
Orthogonality in a programming language means that a relatively small set of primitive
constructs can be combined in a relatively small number of ways to build the control and
data structures of the language.
1.3 Data Types:
The presence of adequate facilities for defining data types and data structures in a
language is another significant aid to readability.
1.4 Syntax Design
The syntax, or form, of the elements of a language has a significant effect on the
readability of programs.
2. Writability –
Factors:
- Simplicity and orthogonality
- Support for abstraction
- Expressivity
3. Reliability
- Factors: -
Type checking
- Exception handling
- Aliasing
- Readability and writability
 Language Evaluation Criteria
2.Writability: Writability is a measure of how easily a language can be used to create
programs for a chosen problem domain.
Most of the language characteristics that affect readability also affect writability.
2.1 Simplicity and Orthogonality:
If a language has a large number of different constructs, some programmers might not be
familiar with all of them.
This situation can lead to a misuse of some features and a disuse of others that may be
either more elegant or more efficient, or both, than those that are used.
2.2 Expressivity:
Expressivity in a language can refer to several different characteristics. In a language such
as APL (Gilman and Rose, 1983), it means that there are very powerful operators that
allow a great deal of computation to be accomplished with a very small program.
 Language Evaluation Criteria
3 Reliability
A program is said to be reliable if it performs to its specifications under all conditions.
3.1 Type Checking:
Type checking is simply testing for type errors in a given program, either by the compiler
or during program execution.
3.2 Exception Handling
The ability of a program to intercept run- time errors (as well as other unusual conditions
detectable by the program), take corrective measures, and then continue is an obvious aid
to reliability. This language facility is called exception handling.
 Language Evaluation Criteria
3.3 Aliasing
Loosely defined, aliasing is having two or more distinct names in a program that can be
used to access the same memory cell.
3.4 Readability and Writability
Both readability and writability influence reliability. A program written in a language that
does not support natural ways to express the required algorithms will necessarily use
unnatural approaches
4. Cost
Categories
Programmer training
Software creation
Compilation
Execution
Compiler cost
Poor reliability
Maintenance
5. Others:
portability
generality
well-definedness
Primary influences on language design
1. Computer architecture
We use imperative languages, at least in part, because we use
von Neumann machines
2. Programming methodologies
- 1950s and early 1960s: Simple applications; worry about machine
efficiency
- Late 1960s: People efficiency became important; readability, better
control structures
- Late 1970s: Data abstraction - Middle 1980s: Object-oriented
programming
Language Categories
1. Imperative
2. Functional
3. Logic
4. Object-oriented (closely related to imperative)

Language Design Trade-offs

1. Reliability versus cost of execution
2. Writability versus readability
3. Flexibility versus safety
Implementation Methods
1. Compilation
- Translate high-level program to machine code
- Slow translation
- Fast execution
2. Pure interpretation
- No translation
- Slow execution
- Becoming rare
3. Hybrid implementation systems
- Small translation cost
- Medium execution speed
Introduction to Compilation Methods

Ø Programming languages can be implemented by any of three general

methods. At one extreme, programs can be translated into machine
language, which can be executed directly on the computer. This method
is called a compiler implementation.
Ø The advantage of very fast program execution, once the translation
process is complete. Most production implementations of languages, such
as C, COBOL, and C++, are by compilers.
Introduction to Compilation Methods
Introduction to Compilation Methods
Introduction to Compilation Methods

Ø The language that a compiler translates is called the source

language. The process of compilation and program execution
takes place in several phases, the most important of which are
shown in Figure.
Ø The lexical analyzer gathers the characters of the source program
into lexical units. The lexical units of a program are identifiers,
special words, operators, and punctuation symbols.
Ø The lexical analyzer ignores comments in the source program
because the compiler has no use for them.
Introduction to Compilation Methods
Ø The syntax analyzer takes the lexical units from the lexical
analyzer and uses them to construct hierarchical structures called
parse trees. These parse trees represent the syntactic structure of
the program.
Ø The intermediate code generator produces a program in a
different language, at an intermediate level between the source
program and the final output of the compiler: the machine
language.
Ø Intermediate languages sometimes look very much like assembly
languages.
Introduction to Compilation Methods
Ø The semantic analyzer is an integral part of the intermediate code
generator.
Ø The semantic analyzer checks for errors, such as type errors, that
are difficult, if not impossible, to detect during syntax analysis.
Ø Optimization, which improves programs (usually in their
intermediate code version) by making them smaller or faster or
both.
Ø Because many kinds of optimization are difficult to do on machine
language, most optimization is done on the intermediate code.
Introduction to Compilation Methods
Ø The code generator translates the optimized intermediate code
version of the program into an equivalent machine language
program.
Ø The symbol table serves as a database for the compilation process.
The primary contents of the symbol table are the type and
attribute information of each user-defined name in the program.
Ø This information is placed in the symbol table by the lexical and
syntax analyzers and is used by the semantic analyzer and the
code generator.
Programming Environments
The collection of tools used in software development
1. UNIX - An old operating system and tool collection.
2. Borland C++ - A PC environment for C and C++.
3. Smalltalk - A language processor/environment.
4. Microsoft Visual C++ - A large, complex visual
environment.
 TextBook

Concepts of Programming
Languages, Robert W.
Sebesta, (10th edition),

Addison-Wesley Publishing
Company

Programming Paradigms-425 CCS 1

 Programming Paradigms- Chapter-2
Concepts of Programming Languages
by
Robert W. Sebesta -Addison Wesley (2005)

Refer to complete Chapter-2

Robert W. Sebesta - Concepts of Programming
Languages-Addison Wesley
Pages: 134-165

Programming Paradigms-425 CCS 2

 Topics
• Introduction
• The General Problem of Describing Syntax
• Formal Methods of Describing Syntax
• BNF and CFG and extended BNF
• Attribute Grammars
• Describing the Meanings of Programs:
• Dynamic Semantics

Programming Paradigms-425 CCS 3

 Introduction
• The task of providing a concise yet understandable
description of a programming language is difficult
but essential to the language’s success.
• ALGOL 60 and ALGOL 68 were first presented using
concise formal descriptions; in both cases, however,
the descriptions were not easily understandable,
partly because each used a new notation
• The study of programming languages, like the study
of natural languages, can be divided into
examinations of syntax and semantics.

Programming Paradigms-425 CCS 4

 Introduction
• Syntax: the form or structure of the expressions,
statements, and program units
• Semantics: the meaning of the expressions,
statements, and program units
• Syntax and semantics provide a language’s definition
– Users of a language definition
• Other language designers
• Implementers
• Programmers (the users of the language)

Programming Paradigms-425 CCS 5

 The General Problem of Describing Syntax:
Terminology
• A sentence is a string of characters over some
alphabet
• A language is a set of sentences
• A lexeme is the lowest level syntactic unit of a
language (e.g., *, sum, begin)
• The lexemes of a programming language include its
numeric literals, operators, and special words,
among others. One can think of programs as strings
of lexemes rather than of characters.
• A token is a category of lexemes (e.g., identifier)

Programming Paradigms-425 CCS 6

 The General Problem of Describing Syntax:
Terminology

• Lexemes are partitioned into groups— for example,

the names of variables, methods, classes, and so
forth in a programming language form a group called
identifiers.
• Each lexeme group is represented by a name, or
token. So, a token of a language is a category of its
lexemes.
• For example, the token for the arithmetic operator
symbol + has just one possible lexeme.

Programming Paradigms-425 CCS 7

 The General Problem of Describing Syntax:
Terminology
Consider the following Java statement:
index = 2 * count + 17;
The lexemes and tokens of this statement are
Lexemes Tokens
Index identifier
= equal_sign
2 int_literal
* mult_op
Count identifier
+ plus_op
17 int_literal
; semicolon
Programming Paradigms-425 CCS 8
 Formal Definition of Languages
• Recognizers
– A recognition device reads input strings over the alphabet
of the language and decides whether the input strings
belong to the language
– Example: syntax analysis part of a compiler
• Generators
– A device that generates sentences of a language
– One can determine if the syntax of a particular sentence is
syntactically correct by comparing it to the structure of the
generator

Programming Paradigms-425 CCS 9

 BNF and Context-Free Grammars
• Context-Free Grammars
– Developed by Noam Chomsky in the mid-1950s
– Language generators, meant to describe the syntax of
natural languages
– Define a class of languages called context-free languages
• Backus-Naur Form (1959)
– Invented by John Backus to describe Algol 58
– BNF is equivalent to context-free grammars

Programming Paradigms-425 CCS 10

 BNF and Context-Free Grammars
• The forms of the tokens of programming languages can be
described by regular grammars.
• The syntax of whole programming languages, with minor
exceptions, can be described by context- free grammars.
Origins of Backus-Naur Form:
• Shortly after Chomsky’s work on language classes, the ACM-
GAMM group began designing ALGOL 58. A landmark paper
describing ALGOL 58 was presented by John Backus.
• The new notation was later modified slightly by Peter Naur
for the description of ALGOL 60 (Naur, 1960). This revised
method of syntax description became known as Backus-Naur
Form, or simply BNF.

Programming Paradigms-425 CCS 11

 BNF Fundamentals
• In BNF, abstractions are used to represent classes of syntactic
structures -- they act like syntactic variables (also called
nonterminal symbols, or just terminals)
• Terminals are lexemes or tokens
• A rule has a left-hand side (LHS), which is a non-terminal, and
a right-hand side (RHS), which is a string of terminals and/or
non-terminals
• Non-terminals are often enclosed in angle brackets
– Examples of BNF rules:

<ident_list> → iden fier | iden fier, <ident_list>

<if_stmt> → if <logic_expr> then <stmt>

• Grammar: a finite non-empty set of rules

• A start symbol is a special element of the nonterminals of a
grammar
Programming Paradigms-425 CCS 12
 BNF Fundamentals
For example, a Java if statement can be
described with the rules
<if_stmt> → if ( <logic_expr> ) <stmt>
<if_stmt> → if ( <logic_expr> ) <stmt> else
<stmt>
or with the rule
<if_stmt> → if ( <logic_expr> ) <stmt>
| if ( <logic_expr> ) <stmt> else <stmt>

Programming Paradigms-425 CCS 13

 BNF Rules
• An abstraction (or nonterminal symbol) can
have more than one RHS

<stmt> → <single_stmt>
| begin <stmt_list> end

Programming Paradigms-425 CCS 14

 Describing Lists
• Syntactic lists are described using recursion
<ident_list> → ident
| ident, <ident_list>
• This defines <ident_list> as either a single
token (identifier) or an identifier followed by a
comma and another instance of <ident_list>.
• A derivation is a repeated application of rules,
starting with the start symbol and ending with
a sentence (all terminal symbols)
Programming Paradigms-425 CCS 15
 Grammars and Derivations:
• A grammar is a generative device for defining
languages. The sentences of the language are
generated through a sequence of applications
of the rules, beginning with a special
nonterminal of the grammar called the start
symbol.
• This sequence of rule applications is called a
derivation

Programming Paradigms-425 CCS 16

 Derivations
• Every string of symbols in a derivation is a
sentential form
• A sentence is a sentential form that has only
terminal symbols
• A leftmost derivation is one in which the
leftmost nonterminal in each sentential form
is the one that is expanded

Programming Paradigms-425 CCS 17

 An Example Grammar & Derivation

<program> → <stmts> <program> => <stmts> => <stmt>

<stmts> → <stmt> |
<stmt> ; <stmts> => <var> = <expr>

<stmt> → <var> = <expr> => a = <expr>

<var> → a | b | c | d
=> a = <term> + <term>
<expr> → <term> + <term> |
<term> - <term> => a = <var> + <term>

<term> → <var> | const

=> a = b + <term>

=> a = b + const
Programming Paradigms-425 CCS 18
 An Example Derivation
<program> => <stmts> => <stmt>
=> <var> = <expr>
=> a = <expr>
=> a = <term> + <term>
=> a = <var> + <term>
=> a = b + <term>
=> a = b + const

Programming Paradigms-425 CCS 19

An Example of Grammar &Derivation
A Grammar for a Small Language
<program> → begin <stmt_list> end
<stmt_list> → <stmt>
| <stmt> ; <stmt_list>
<stmt> → <var> = <expression>
<var> → A | B | C
<expression> → <var> + <var>
| <var> – <var>
| <var>

Programming Paradigms-425 CCS 20

An Example of Grammar &Derivation
A derivation of a program in this language follows:
<program> => begin <stmt_list> end
=> begin <stmt> ; <stmt_list> end
=> begin <var> = <expression> ; <stmt_list> end
=> begin A = <expression> ; <stmt_list> end
=> begin A = <var> + <var> ; <stmt_list> end
=> begin A = B + <var> ; <stmt_list> end
=> begin A = B + C ; <stmt_list> end
=> begin A = B +C ; <stmt> end
=> begin A = B + C ; <var> = <expression> end
=> begin A = B + C ; B = <expression> end
=> begin A = B + C ; B = <var> end
=> begin A = B + C ; B = C end
Programming Paradigms-425 CCS 21
 An Example of Grammar &Derivation
A Grammar for Simple Assignment Statements
<assign> → <id> = <expr>
<id> → A| B | C
<expr> → <id> + <expr>
| <id> * <expr>
| ( <expr>)
| <id>
For example, the statement
A = B * ( A + C ) is generated by the leftmost derivation:
<assign> => <id> = <expr>
=> A = <expr>
=> A = <id> * <expr>
=> A = B * <expr>
=> A = B * ( <expr>)
=> A = B * ( <id> + <expr>)
=> A = B * ( A + <expr>)
=> A = B * ( A + <id>)
=> A = B * ( A + C )
Programming Paradigms-425 CCS 22
 Parse Tree
• A hierarchical representation of a derivation
• One of the most attractive features of grammars is that they
naturally describe the hierarchical syntactic structure of the
sentences of the languages they define. These hierarchical
structures are called parse trees.

Programming Paradigms-425 CCS 23

 Parse Tree

Programming Paradigms-425 CCS 24

 Ambiguity in Grammars
• A grammar is ambiguous if and only if it generates a
sentential form that has two or more distinct parse trees
• some string that it can generate in more than one way
• semantic information is needed to select the intended parse
• For example, in C the following:
– x * y ; can be interpreted as either:
• the declaration of an identifier named y of type pointer-to-x, or
• an expression in which x is multiplied by y and then the result is
discarded.

Programming Paradigms-425 CCS 25

 Ambiguity in Grammars

Programming Paradigms-425 CCS 26

 An Ambiguous Expression Grammar

Programming Paradigms-425 CCS 27

 Associativity of Operators
• Operator associativity can also be indicated by a grammar

Programming Paradigms-425 CCS 28

 Extended BNF
• Optional parts (0 or one) are placed in
brackets [ ]
<proc_call> → ident [(<expr_list>)]
• Alternative parts of RHSs are placed inside
parentheses and separated via vertical bars
<term> → <term> (+|-) const
• Repetitions (0 or more) are placed inside
braces { }
<ident> → le er {letter|digit}
Programming Paradigms-425 CCS 29
 BNF and EBNF

Programming Paradigms-425 CCS 30

 Semantics
• BNF in the form of CFG is used to describe the syntax
of a programming language
• It can not describe the semantics (meaning) of the
programming language statements, expressions,
etc.
• There are two categories of semantics:
– Static semantics: semantic rules that can be checked
during compile time (i.e., prior to runtime). As an example,
variables in a program must be "declared" before they are
referenced.
– Dynamic semantics: semantic rules that apply during the
execution of a program.

Programming Paradigms-425 CCS 31

 Attribute Grammars

• Attribute grammars (AGs) have additions to

CFGs to carry some semantic info on parse
tree nodes

• Primary value of AGs:

– Static semantics specification
– Compiler design (static semantics checking)

Programming Paradigms-425 CCS 32

 Attribute Grammars : Definition
• Def: An attribute grammar is a context-free
grammar G = (S, N, T, P) with the following
additions:
– For each grammar symbol x there is a set A(x) of
attribute values
– Each rule has a set of functions that define certain
attributes of the nonterminals in the rule
– Each rule has a (possibly empty) set of predicates
to check for attribute consistency

Programming Paradigms-425 CCS 33

 Attribute Grammars: Definition
• Let X0 → X1 ... Xn be a rule
• Functions of the form S(X0) = f(A(X1), ... , A(Xn))
define synthesized attributes
• Functions of the form I(Xj) = f(A(X0), ... , A(Xn)),
for i <= j <= n, define inherited attributes
• Initially, there are intrinsic attributes on the
leaves

Programming Paradigms-425 CCS 34

 Attribute Grammars: An Example
• Syntax
<assign> -> <var> = <expr>
<expr> -> <var> + <var> | <var>
<var> A | B | C
• actual_type: synthesized for <var> and
<expr>
• expected_type: inherited for <expr>

Programming Paradigms-425 CCS 35

 Attribute Grammar (continued)
• Syntax rule: <expr> → <var>[1] + <var>[2]
Semantic rules:
<expr>.actual_type ← <var>[1].actual_type
Predicate:
<var>[1].actual_type == <var>[2].actual_type
<expr>.expected_type == <expr>.actual_type

• Syntax rule: <var> → id

Semantic rule:
<var>.actual_type ← lookup (<var>.string)

Programming Paradigms-425 CCS 36

 Attribute Grammars (continued)
• How are attribute values computed?
– If all attributes were inherited, the tree could be
decorated in top-down order.
– If all attributes were synthesized, the tree could
be decorated in bottom-up order.
– In many cases, both kinds of attributes are used,
and it is some combination of top-down and
bottom-up that must be used.

Programming Paradigms-425 CCS 37

 Attribute Grammars (continued)
<expr>.expected_type ← inherited from parent

<var>[1].actual_type ← lookup (A)

<var>[2].actual_type ← lookup (B)
<var>[1].actual_type =? <var>[2].actual_type

<expr>.actual_type ← <var>[1].actual_type
<expr>.actual_type =? <expr>.expected_type

Programming Paradigms-425 CCS 38

 Semantics
• There is no single widely acceptable notation
or formalism for describing semantics
• Several needs for a methodology and
notation for semantics:
– Programmers need to know what statements mean
– Compiler writers must know exactly what language constructs do
– Correctness proofs would be possible
– Compiler generators would be possible
– Designers could detect ambiguities and inconsistencies

Programming Paradigms-425 CCS 39

 Operational Semantics

• Operational Semantics
– Describe the meaning of a program by executing
its statements on a machine, either simulated or
actual. The change in the state of the machine
(memory, registers, etc.) defines the meaning of
the statement
• To use operational semantics for a high-level
language, a virtual machine is needed

Programming Paradigms-425 CCS 40

 Denotational Semantics
• Based on recursive function theory
• The most abstract semantics description
method
• Originally developed by Scott and Strachey
(1970)

Programming Paradigms-425 CCS 41