UNIT - I

PRELIMINARY CONCEPTS
1. Reasons for Studying Concepts of Programming Languages

Increased ability to express ideas.

It is believed that the depth at which we think is influenced by the expressive power of the language in
which we communicate our thoughts. It is difficult for people to conceptualize structures they cannot
describe, verbally or in writing. Language in which they develop S/W places limits on the kinds of
control structures, data structures, and abstractions they can use. Awareness of a wider variety of P/L
features can reduce such limitations in S/W development. Can language constructs be simulated in other
languages that do not support those constructs directly?

Improved background for choosing appropriate languages

Many programmers, when given a choice of languages for a new project, continue to use the language with
which they are most familiar, even if it is poorly suited to new projects. If these programmers were familiar
with other languages available, they would be in a better position to make informed language choices.

Greater ability to learn new languages

Programming languages are still in a state of continuous evolution, which means continuous learning is
essential. Programmers who understand the concept of OO programming will have easier time learning
Java. Once a thorough understanding of the fundamental concepts of languages is acquired, it becomes
easier to see how concepts are incorporated into the design of the language being learned.

Understand significance of implementation

Understanding of implementation issues leads to an understanding of why languages are designed the
way they are. This in turn leads to the ability to use a language more intelligently, as it was designed to
be used.

Ability to design new languages

The more languages you gain knowledge of, the better understanding of programming languages
concepts you understand.

Overall advancement of computing

In some cases, a language became widely used, at least in part, b/c those in positions to choose languages
were not sufficiently familiar with P/L concepts. Many believe that ALGOL 60 was a better language
than Fortran; however, Fortran was most widely used. It is attributed to the fact that the programmers
and managers didn’t understand the conceptual design of ALGOL 60.

2. Programming Domains

Scientific applications

– In the early 40s computers were invented for scientific applications.

– The applications require large number of floating-point computations.
– Fortran was the first language developed scientific applications.
– ALGOL 60 was intended for the same use.
Business applications
Dept. of CSE. MECS 10
– The first successful language for business was COBOL.
– Produce reports, use decimal arithmetic numbers and characters.
– The arrival of PCs started new ways for businesses to use computers.
– Spreadsheets and database systems were developed for business.
Artificial intelligence

– Symbolic rather than numeric computations are manipulated.

– Symbolic computation is more suitably done with linked lists than arrays.
– LISP was the first widely used AI programming language.
Systems programming

– The O/S and all the programming supports tools are collectively known as its system software.
– Need efficiency because of continuous use.
Scripting languages

– Put a list of commands, called a script, in a file to be executed.

– PHP is a scripting language used on Web server systems. Its code is embedded in HTML documents.
The code is interpreted on the server before the document is sent to a requesting browser.

3. Language Evaluation Criteria

3.1 Readability

- Software development was largely thought of in term of writing code “LOC”.

- Language constructs were designed more from the point of view of the computer than the users.
- Because ease of maintenance is determined in large part by the readability of programs, readability
became an important measure of the quality of programs and programming languages. The result is a
crossover from focus on machine orientation to focus on human orientation.
- The most important criterion “ease of use”
Overall simplicity

“Strongly affects readability”

– Too many features make the language difficult to learn. Programmers tend to learn a subset of the
language and ignore its other features. “ALGOL 60”

– Multiplicity of features is also a complicating characteristic “having more than one way to accomplish
a particular operation.”

– Ex “Java”:

count = count + 1
count += 1
count ++
++count
– Although the last two statements have slightly different meaning from each other and from the others, all
four have the same meaning when used as stand-alone expressions.

– Operator overloading where a single operator symbol has more than one meaning.

– Although this is a useful feature, it can lead to reduced readability if users can create their own
overloading and do not do it sensibly.

Orthogonality

Dept. of CSE. MECS 11

– Makes the language easy to learn and read.

– Meaning is context independent. Pointers should be able to point to any type of variable or data
structure. The lack of orthogonality leads to exceptions to the rules of the language.

– 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.

– Every possible combination is legal and meaningful.

– The more orthogonal the design of a language, the fewer exceptions the language rules
require.

– The most orthogonal programming language is ALGOL 68. Every language construct has a type, and
there are no restrictions on those types.

– This form of orthogonality leads to unnecessary complexity.

Control Statements

– It became widely recognized that indiscriminate use of goto statements severely reduced program
readability.

– Ex: Consider the following nested loops written in C

while (incr <20)

{
while (sum <= 100
{
sum += incr;
}
incr++;
}
if C didn’t have a loop construct, this would be written as follows:

loop1:
if (incr >= 20) go to out;
loop2:
if (sum > 100) go to next;
sum += incr;
go to loop2;
next:
incr++;
go to loop1:
– Basic and Fortran in the early 70s lacked the control statements that allow strong restrictions on the
use of goto’s, so writing highly readable programs in those languages was difficult.

– Since then, languages have included sufficient control structures.

– The control statement design of a language is now a less important factor in readability than it was in
the past.

Data Types and Structures

– The presence of adequate facilities for defining data types and data structures in a language is another
significant aid to reliability.

Dept. of CSE. MECS 12

– Ex: Boolean type.

timeout = 1 or

timeout = true

Syntax Considerations

– The syntax of the elements of a language has a significant effect on readability.


– The following are examples of syntactic design choices that affect readability:

Identifier forms: Restricting identifiers to very short lengths detract from readability. ANSI BASIC
(1978) an identifier could consist only of a single letter of a single letter followed by a single digit.

Special Words: Program appearance and thus program readability are strongly

influenced by the forms of a language’s special words. Ex: while, class, for. C uses braces for pairing
control structures. It is difficult to determine which group is being ended. Fortran 95 allows
programmers to use special names as legal variable names.

Form and Meaning: Designing statements so that their appearance at least partially indicates their
purpose is an obvious aid to readability.

Semantic should follow directly from syntax, or form.

Ex: In C the use of static depends on the context of its appearance.

If used as a variable inside a function, it means the variable is created at compile time.

If used on the definition of a variable that is outside all functions, it means the variable is visible only in
the file in which its definition appears.

3.2 Writability

It 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.

Simplicity and orthogonality

– A smaller number of primitive constructs and a consistent set of rules for combining them is much
better than simply having many primitives.

Support for abstraction

– Abstraction means the ability to define and then use complicated structures or operations in ways that
allow many of the details to be ignored.

– A process abstraction is the use of a subprogram to implement a sort algorithm that is required several
times in a program instead of replicating it in all places where it is needed.

Expressivity

– It means that a language has relatively convenient, rather than cumbersome, ways of specifying
computations.

Dept. of CSE. MECS 13

Ex: ++count

3.3 Reliability

A program is said to be reliable if it performs to its specifications under all conditions.

Type checking: is simply testing for type errors in a given program, either by the compiler or during
program execution.

– The earlier errors are detected, the less expensive it is to make the required repairs. Java requires type
checking of nearly all variables and expressions at compile time.

Exception handling: the ability to intercept run-time errors, take corrective measures, and then continue
is a great aid to reliability.

Aliasing: it is having two or more distinct referencing methods, or names, for the same
memory cell.

– It is now widely accepted that aliasing is a dangerous feature in a language.

Readability and writability: Both readability and writability influence reliability.

3.4 Cost

– Categories

– Training programmers to use language

– Writing programs “Writability”

– Compiling programs

– Executing programs

– Language implementation system “Free compilers is the key, success of Java”

– Reliability, does the software fail?

– Maintaining programs: Maintenance costs can be as high as two to four times as much as
development costs.

– Portability “standardization of the language”, Generality (the applicability to a wide range of

applications)

4. Influences on Language Design

Computer architecture: Von Neumann

We use imperative languages, at least in part, because we use von Neumann machines

– Data and programs stored in same memory

– Memory is separate from CPU
– Instructions and data are piped from memory to CPU
– Results of operations in the CPU must be moved back to memory
– Basis for imperative languages

Dept. of CSE. MECS 14

Variables model memory cells
Assignment statements model piping
Iteration is efficient

Programming methodologies

1950s and early 1960s: Simple applications; worry about machine efficiency

Late 1960s: People efficiency became important; readability, better control structures

– Structured programming

– Top-down design and stepwise refinement

Late 1970s: Process-oriented to data-oriented

– data abstraction

Middle 1980s: Object-oriented programming

5. Language Categories

Imperative

– Central features are variables, assignment statements, and iteration

– C, Pascal

Functional

– Main means of making computations is by applying functions to given parameters

– LISP, Scheme

Logic

– Rule-based

– Rules are specified in no special order

Dept. of CSE. MECS 15

– Prolog

Object-oriented

– Encapsulate data objects with processing

– Inheritance and dynamic type binding

– Grew out of imperative languages

– C++, Java

Language Design Trade-offs

Reliability vs. Cost of Execution

Example: Java demands all references to array elements be checked for proper indexing, which
leads to increased execution costs

Readability vs. Writability

- Example: provides many powerful operators (and a large number of new symbols),
allowing complex computations to be written in a compact program but at the cost of
poor readability

Writability (flexibility) vs. Reliability

Example: C++ pointers are powerful and very flexible but are unreliable

Language Implementation Methods

Compilation

Programs are translated into machine language

Pure Interpretation

Programs are interpreted by another program known as an interpreter

Hybrid Implementation Systems

A compromise between compilers and pure interpreters

Layered View of Computer

The operating system and language implementation are layered over machine interface of a
computer

Dept. of CSE. MECS 16

 Adopted from Concepts of Programming Languages – Robert W. Sebesta

Compilation Implementation Method

• Translate high-level program (source language) into machine code (machine language)
• Slow translation, fast execution
• Compilation process has several phases:
lexical analysis: converts characters in the source program into lexical units
syntax analysis transforms lexical units into parse trees which represent the syntactic structure
of program
Semantics analysis: generate intermediate code
code generation: machine code is generated
The Process of Compilation and program execution takes place in several phases. The
following figure specifies different phases of a general Compiler

Dept. of CSE. MECS 17

Pure Interpretation Implementation

• Programs are interpreted by another program called an interpreter,

with no translation.
• Advantage is easy implementation of many source-level debugging
operations.
• Disadvantage is this method is 10 to 100 times slower than compiled
systems.
• Statement decoding is the bottleneck of a pure interpreter.
• Another disadvantage is this method requires more space
(for including symbol table along with source code).
• Ex: Earlier versions of APL, SNOBOL, and LISP

Hybrid Implementation Method

• High-level programs are translated to an intermediate

language designed to allow easy interpretation.
• This method is better than pure interpretation as the
source language statements are decoded only once.
• Ex: Perl, Java and .NET

Preprocessor

• A preprocessor is a program that process a program

statements immediately before the program is compiled.
 Preprocessor directives like #include, #define
#include “stdio.h”
#define PI 3.144
• Preprocessor instructions are embedded in the program. It is commonly used to specify the
code from another file to be included into program.
• Ex: expression like x = max(a, b); => x = ( (a) > (b) ? (a) : (b) );

Programming Environments

• A collection of tools used in software development

File systems, Text editors, Linker/Loader, Compilers
• UNIX
An older operating system and tool collection
Nowadays often used through a GUI (e.g., CDE, KDE, or GNOME) that runs on top of UNIX
• Turbo C & C++
• Borland JBuilder
For Java development
• Microsoft Visual Studio.NET
A large, complex visual environment
Used to build Web applications and non-Web applications in any .NET language
• NetBeans, Eclipse
A visual environment for Java and Web applications development.
Dept. of CSE. MECS 18
Support for JavaScript and tomcat webserver


Genealogy of common high-level programming languages

Syntax and Semantics

To describe a language for a diversity of people, there should be a standard for describing every
concept of the programming language. (i.e. how to specify an expression, statement, and program
units)

The Study of programming languages is dived into examination of Syntax and Semantics of its
constructs.

Syntax – It is the form / structure of the expressions, statements, and program units.
Semantics – It is the meaning of the expressions, statements, and program units.

Example: while statement in C language

While(expression)
{
while(expression) statement1;
Syntax: statement; or statement2;
}

Dept. of CSE. MECS 19

Semantics: If the Boolean expression if true, statement or set of statement are executed,
otherwise the control continues after the while construct.

Who must use language definitions?

1. Initial Evaluators (Other language designers)

2. Implementors
3. Programmers (the users of the language)

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

A token is a category of lexemes (e.g., identifier)

In general, Languages can be formally defined in two distinct ways:

1. Recognizers - used in compilers (reads a string and determines whether it is the given
language or not)

2. Generators – used to generate the sentence of a language

Language recognizers:

Suppose we have a language L that uses an alphabet ∑ of characters. To define L formally using the
recognition method, we would need to construct a mechanism R, called a recognition device, capable of
reading strings of characters from the alphabet ∑. R would indicate whether a given input string was or
was not in L. In effect, R would either accept or reject the given string. Such devices are like filters,
separating legal sentences from those that are incorrectly formed. If R, when fed any string of characters
over ∑, accepts it only if it is in L, then R is a description of L. Because most useful languages are, for
all practical purposes, infinite, this might seem like a lengthy and ineffective process. Recognition
devices, however, are not used to enumerate all the sentences of a language—they have a different
purpose. The syntax analysis part of a compiler is a recognizer for the language the compiler translates.
In this role, the recognizer need not test all possible strings of characters from some set to determine
whether each is in the language.

Language Generators

A language generator is a device that can be used to generate the sentences of a language. The syntax-
checking portion of a compiler (a language recognizer) is not as useful a language description for a
programmer because it can be used only in trial-and-error mode. For example, to determine the correct
syntax of a statement using a compiler, the programmer can only submit a speculated version and note
whether the compiler accepts it. On the other hand, it is often possible to determine whether the syntax
of a statement is correct by comparing it with the structure of the generator.

Formal Methods to Describing Syntax:

Grammars are commonly used to describe the syntax of programming languages.

Context-Free Grammars

Dept. of CSE. MECS 20

  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 and regular Languages.

BNF: (Backus-Naur Form)

 A grammar is a finite nonempty set of rules.

 A rule has a left-hand side (LHS) and a right-hand side (RHS)
o LHS  RHS
 LHS is called as abstraction and contains one nonterminal symbol
 RHS consists of terminal and nonterminal symbols.
 An abstraction (or nonterminal symbol) can have more than one RHS
 Every grammar will have a start symbol

Example
<Stmt> -> <single_stmt>
| begin <stmt_list> end
Syntactic lists are described in BNF using recursion

<ident_list> -> ident

| ident, <ident_list>
A derivation is a repeated/ application of rules, starting with the start symbol and ending with a
sentence (all terminal symbols)

An example grammar:
<program> -> <stmts>
<stmts> -> <stmt> | <stmt>; <stmts>
<stmt> -> <var> = <expr>
<var> -> a | b | c | d
<expr> -> <term> + <term> | <term> - <term>
<term> -> <var> | const
An example derivation:

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

=> <var> = <expr> => a = <expr>
=> a = <term> + <term>
=> a = <var> + <term>
=> a = b + <term>
=> a = b + const
Each string in the derivation including start symbol is called 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.

A derivation may be rightmost i.e. a rightmost nonterminal in each sentential form is

expanded. Derivation order has no effect on the language generated by the grammar.

An example grammar:
<program> -> <stmts>
<stmts> -> <stmt> | <stmt> ; <stmts>
<stmt> -> <var> = <expr>
<var> -> a | b | c | d
<expr> -> <term> + <term> | <term> - <term>
<term> -> <var> | const
Dept. of CSE. MECS 21
An example derivation:

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

=> <var> = <expr> => a = <expr>
=> a = <term> + <term>
=> a = <var> + <term>
=> a = b + <term>
=> a = b + const

A parse tree is hierarchical representation of a derivation

EBNF: Extended BNF

<expr> -> <term> {(+ | -) <term>}
<term> -> <factor> {(* | /) <factor>}

Syntax Graphs - put the terminals in circles or ellipses and put the non-terminals in
rectangles; connect with lines with arrowheads

e.g., Pascal type declarations

Example: expressions of the form id + id - id's can be either int_type or real_type types of the two id's
must be the same type of the expression must match its expected type

BNF:

<expr> -> <var> + <var>

<var> -> id
Dept. of CSE. MECS 22
PARSE TREE:

Hierarchical representation of a derivation. Every internal node of a parse tree is labeled with a non-
terminal symbol; every leaf is labeled with a terminal symbol. Every subtree of a parse tree describes
one instance of an abstraction in the sentence

Ambiguous grammar

A grammar is ambiguous if it generates a sentential form that has two or more distinct parse trees An
ambiguous expression grammar:

<expr> -> <expr> <op> <expr> | const

<op> -> / | -
If we use the parse tree to indicate precedence levels of the operators, we cannot have ambiguity An
unambiguous expression grammar:

<expr> -> <expr> - <term> | <term>

<term> -> <term> / const | const

r> => <expr> - <term> => <term> - <term>

=> const - <term>
=> const - <term> / const
=> const - const / const
Operator associativity can also be indicated by a grammar

<expr> -> <expr> + <expr> | const (ambiguous)

<expr> -> <expr> + const | const (unambiguous)

Dept. of CSE. MECS 23

xtended BNF (just abbreviations):

1. Optional parts are placed in brackets ([]) <proc_call> -> ident [ ( <expr_list>)]

2. Put alternative parts of RHSs in parentheses and separate them with vertical bars
<term> -> <term> (+ | -) const

3. Put repetitions (0 or more) in braces ({}) <ident> -> letter {letter | digit}

The brackets, braces and parentheses are known as meta symbols

BNF

<expr>  <expr> + <term>

| <expr> - <term>

| <term>

<term>  <term> * <factor>

| <term> / <factor>

| <factor>

EBNF

<expr>  <term> {(+ | -) <term>}

<term>  <factor> {(* | /) <factor>}
Attribute Grammar

Static semantics (have nothing to do with meaning) (Syntax rather than semantics).

It has been introduced to specify some language rules which are not specified by using BNF rules.

Example: Floating point value cannot be assigned to integer type variable (context-free)

All variable must be declared before using them in program (noncontext-free)

So, many static sematic rules specify its type constraints.

Attribute Grammar (was designed by Knuth, 1968).

It is a device used to describe both the syntax and static semantic.

Used to describe more than the structure of a programming language.

CFGs cannot describe all the syntax of programming languages. So, it is an extension to CFG.
Dept. of CSE. MECS 24
- Additions to CFGs to carry some semantic info along through parse tree Primary value of AGs:

Attribute grammars are context-free grammars to which we have added attributes, attribute computation
functions, and predicate functions.

Attributes: are associated with grammar symbols (terminals and non-terminals) and are like variables.

Attribute computation function: semantic functions associated with grammar rules. They are used to
specify how attribute values are computed.

Predicate function: static semantic rules of the language that are associated with grammar rules.

Def: An attribute grammar is a cfg G = (S, V, T, P) with the following additions:

For each grammar symbol x there is a set A(x) of attribute values.

Each set A(x) consists of two disjoint sets S(x) and I(x), called synthesized and inherited attributes.

Each rule has a set of functions that define certain attributes of the non-terminals in the rule called
semantic functions.

Each rule has a (possibly empty) set of predicates to check for attribute consistency called predicate
function.

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

Attributes:

actual_type - synthesized for <var> and <expr>

expected_type - inherited for <expr>
Attribute Grammar:

Syntax rule: <expr> -> <var>[1] + <var>[2]

Semantic rules:

<var>[1].env  <expr>.env
<var>[2].env  <expr>.env
<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 (id, <var>.env)

How are attribute values computed?

1. 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.
Dept. of CSE. MECS 25
In many cases, both kinds of attributes are used, and it is some combination of top-down and bottom-up
that must be used

. <expr>.env  inherited from parent

<expr>.expected_type  inherited from parent

<var>[1].env  <expr>.env

<var>[2].env  <expr>.env

<var>[1].actual_type  lookup (A, <var>[1].env)

<var>[2].actual_type  lookup (B, <var>[2].env)

<var>[1].actual_type == <var>[2].actual_type

<expr>.actual_type  <var>[1].actual_type

<expr>.actual_type == <expr>.expected_type

General Problem of Describing Semantics: Dynamic Semantics

Describing dynamic semantic or describing the meaning of the expression, statement, and program units
of a programming language.

 No single widely/Universally acceptable notation or formalism for describing semantics.

 But there is a need of methodology and notation to describe semantics of a language
because, programmers need to know precisely what the statements of a language do before
using them.
 A complete specification of syntax and semantic of a programming language is used by a
tool to generate a compiler for the language automatically

Several reasons for the needs of a methodology and notation for describing semantics:

 Programmers need to know what statements mean

 Compiler writers must know exactly what language constructs do
 Correctness can be proven without testing
 Automatic Compiler generation is possible with some tools
 Designers could detect ambiguities and inconsistencies

S/W developers and compiler designers determine the semantics by reading the language
manual written in English, but such manuals are often imprecise and incomplete. A complete
specification of the syntax and semantics of a programming language could be used by a tool to
generate a compiler for the language automatically.

There are three approaches to describe the semantic for the imperative programming languages

Operational Semantics
Denotational Semantics
Axiomatic Semantics

Operational Semantics

Dept. of CSE. MECS 26

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. Operational semantics description is given by the compiled version of the program on
a computer.

Few problems in describing operational semantics

1. Steps in execution and change in state are to small and numerous

2. Machine language and real computers are not used for operational semantics (they are too
large and complex)

So, intermediate language and interpreters (virtual machine) are used.

 To use operational semantics for a high-level language, a virtual machine in needed

 A hardware pure interpreter would be too expensive
 A software pure interpreter also has problems:

The detailed characteristics of the particular computer would make actions difficult to understand

Such a semantic definition would be machine dependent

A better alternative: A complete computer simulation

The process:

Build a translator (translates source code to the intermediate code of an idealized computer)

Build a simulator for the idealized computer

Meaning
C Statement
expr1 ;
for (expr1; expr2;
loop: if expr2 == 0 goto out
expr3)
...
{
expr3 ;
...
goto loop
}
out: . . .
Intermediate language is meant to be convenient for virtual machine.

Different levels of uses of operational semantics

• Natural operational semantics: Highest Level, interest is in the result of complete program.
• Structural operational semantics: Lowest Level, precise meaning of program is specified with a
complete sequence of state changes when the program is executed.

Evaluation of operational semantics:

– It was first used to describe semantics of PL/I

– Good and effective mean of describing semantics if the description is kept simple and informal.
(language manuals, etc.)
– Extremely complex if used formally (e.g., VDL and PL/I)
– Operational semantics depends on programming languages of lower level not mathematics. i.e
semantics is specified in terms of lower language constructs.

Dept. of CSE. MECS 27

Denotational Semantics

It is the most rigorous and most widely used formal notation of describing the meaning of
program constructs
- Based on recursive function theory, the most abstract semantics description method Originally
developed by Scott and Strachey

- The process of building a denotational specification for a language:

- Define a mathematical object for each language entity

- Define a function that maps instances of the language entities onto instances of the corresponding
mathematical objects
- The meaning of language constructs is defined by only the values of the program's variables.

- The difference between denotational and operational semantics: In operational semantics, the state
changes are defined by coded algorithms; in denotational semantics, they are defined by rigorous
mathematical functions

• Like all functions in mathematics, mapping function have

a domain (collection of values that are parameters to function)
range (collection of objects to which parameters are mapped).
• Domain is called syntactic domain.
• Range is called semantic domain
Simple Examples: Parse tree for 110
<bin_num>
String representation of a binary number
<bin_num> → '0’
| '1’ <bin_num> 0
| <bin_num> '0’
| <bin_num> '1'
<bin_num> 1

1
Syntactic domain: set of {0,1}
Semantic domain: set of all nonnegative
decimal numbers
Function:
Mbin (‘0’) = 0
Mbin (‘1’) = 1
Mbin (<bin_num> ‘0’) = 2 * Mbin (<bin_num>) + 0
Mbin (<bin_num> ‘1’) = 2 * Mbin (<bin_num>) + 1

Example for describing the meaning of syntactic decimal number:

Description of syntactic decimal literals

<dec_num>  '0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9'
|<dec_num>('0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'|'8'|'9’)

Dept. of CSE. MECS 28

Function

Mdec ('0') = 0, Mdec ('1') = 1, …, Mdec ('9') = 9

Mdec (<dec_num> '0') = 10 * Mdec (<dec_num>)
Mdec (<dec_num> '1’) = 10 * Mdec (<dec_num>) + 1
.
.
.
.

Mdec (<dec_num> '9') = 10 * Mdec (<dec_num>) + 9

The State of a Program

Denotational semantics of a program could be defined in terms of state changes in an ideal computer. It
is defined in terms of only the values of all the program’s variables.

- The state of a program is the values of all its current program variables

State changes are defined by mathematical functions

s = {<i1, v1>, <i2, v2>,…, <in, vn>}

Each i is the name of a variable, and associated v’s are the current values of these variables.

Let VARMAP be a function that, when given a variable name and a state, returns the current value of the
variable VARMAP (ij, s) = vj

These state changes are used to define the meanings of programs and program constructs.

Expressions are mapped to values, not states.

Expressions

• Expressions are fundamentals to most programming languages

• Let Z be the set of integers, and error be the error value
• Z  {error} is the semantic domain
• We assume expressions are decimal numbers, variables, or binary expressions having one
arithmetic operator and two operands, each of which can be an expression.

BNF description of expression

<expr> → <dec_num> | <var> | <binary_expr>
<binary_expr> → <left_expr> <operator> <right_expr>
<left_expr> → <dec_num> | <var>
<right_expr> → <dec_num> | <var>
<operator> → + | *
<var> → A | B | C | . . . . . . . . . . . . .. | Z
The mapping function for the expression E and state ‘s’ follows:
Δ= (used to define mathematical function)
=>(represents assignment statements)
Me(<expr>, s) =
case <expr> of
<dec_num> => Mdec(<dec_num>, s)
<var> =>
if VARMAP(<var>, s) == undef
then error
Dept. of CSE. MECS 29
 else VARMAP(<var>, s)
<binary_expr> =>

if (Me(<binary_expr>.<left_expr>, s) == undef OR
Me(<binary_expr>.<right_expr>, s) == undef)
then error
else
if (<binary_expr>.<operator> == '+' then
Me(<binary_expr>.<left_expr>, s) + Me(<binary_expr>.<right_expr>, s)
else Me(<binary_expr>.<left_expr>, s) * Me(<binary_expr>.<right_expr>, s)
Assignment Statements

 An assignment statement is an expression evaluation and assigning the value to target variable.
 The meaning function maps state to a state.
Ma(x := E, s) =
if Me(E, s) == error
then error
else s’ = {<i1,v1’>,<i2,v2’>,...,<in,vn’>},
where for j = 1, 2, ..., n,
if ij == x #comaparison of names
then vj’ = Me(E, s)
else vj’ = VARMAP(ij, s)
Logical Pretest Loops

• Msl and Mb map statement lists and states to states and Boolean expression to Boolean values.

Ml(while B do L, s) =
if Mb(B, s) == undef
then error
else if Mb(B, s) == false
then s
else if Msl(L, s) == error
then error
else Ml(while B do L, Msl(L, s))
• The meaning of the loop is the value of the program variables after the statements in the loop
have been executed the prescribed number of times, assuming there have been no errors
• In essence, the loop has been converted from iteration to recursion, where the recursive control
is mathematically defined by other recursive state mapping functions
- Recursion, when compared to iteration, is easier to describe with mathematical rigor

Evaluation of denotational semantics:

- Can be used to prove the correctness of programs
- Provides a rigorous way to think about programs
- Can be an aid to language design
- Has been used in compiler generation systems

Axiomatic Semantics

Most abstract approach of semantic specification

Based on mathematical logic.

Dept. of CSE. MECS 30

 Specified in terms of what can be proven about the program.
Based on relationship among the program variables and constants.
Each statement in a program is preceded and followed by a logical expression that defines
constraints on program variables. So, these constraints are used to specify the meaning of
the statement in axiomatic semantics.
Notation used to describe constraint is predicate calculus (the language of axiomatic
semantics).

Original purpose: formal program verification

Approach: Define axioms or inference rules for each statement type in the language (to allow
transformations of expressions to other expressions)

The expressions are called assertions

-An assertion before a statement (a precondition) states the relationships and constraints among variables
that are true at that point in execution

-An assertion following a statement is a postcondition that describes the new constraint on variable after
execution.

Preconditions are computed from Postconditions

Example:

sum = 2 * x + 1 {sum > 1} # here {sum > 1} is the postcondition

To get sum > 1, one possible precondition is x >5 | x > 10 | x > 20 ….

But the least restrictive precondition that will guarantee the validity of associated postcondition is x > 0.
So, x > 0 is the weakest precondition

Program proof process: The postcondition for the whole program is the desired results. Work
back through the program to the first statement. If the precondition on the first statement is the
same as the program spec, the program is correct.

An axiom is a logical statement that is assumed to be true. Therefore, it is an inference rule without an
antecedent.

Inference rule is a method of inferring the truth of one assertion based on the values of other assertions.

(S1, S2, ……Sn)/S if s1, s2,…..Sn are true, then the truth of S can be inferred.

Top part is called antecedent

Bottom part is called its consequent

To use axiomatic semantics for correctness proofs or for formal semantic specification, either an axiom
or inference rule must exist for each kind of statement in language

Dept. of CSE. MECS 31

An axiom for assignment statements:

Precondition and Postcondition of an assignment statement together define precisely its

meaning.
Let x = E is an assignment statement, and Q is postcondition
P = Qx → E
{P} S {Q} => {Qx → E } x = E {Q}
Example:  (b / 2) – 1 < 10
a = (b / 2) – 1 {a < 10 }  b/2 < 11
 b < 22
Precondition is {b < 22}
Example:
 2 * y -3 >25
x = 2 * y – 3 {x > 25}
 2 * y > 28
Precondition is {y > 14}
 y > 28/2
 y > 14
An inference rule for Sequences

• Let S1 and S2 be two adjacent statements

• {P1} S1 {P2}
• {P2} S2 {P3}
• As per inference rule:
{P1} S1 {P2}, {P2} S2 {P2}
{P1} S1, S2 {P3}
S1: x1= E1 and S2: x2= E2
then we have
{P3 x2 → E2 } x2= E2 {P3}

{(P3 x2 → E2 ) x1 → E1 } x1= E1 {P3 x2 → E2 }

Therefore, the weakest precondition for the sequence

x1 = E1; x2 = E2 with postcondition P3 is {(P3 x2 → E2 ) x1 → E1 }.

An inference rule for Selection

• Inference rule for selection statement
• if B then S1 else S2
• {B and P} S1 {Q}, {(not B) and P} S2{Q}
• {P} if B then S1 else S2 {Q}

An inference rule for logical pretest loops

For the loop construct:

{P} while B do S end {Q} the inference rule is:

Dept. of CSE. MECS 32

 where I is the loop invariant. Characteristics of the loop invariant

I must meet the following conditions:

1. P => I (the loop invariant must be true initially)

2. {I} B {I} (evaluation of the Boolean must not change the validity of I)

3. {I and B} S {I} (I is not changed by executing the body of the loop)

4. (I and (not B)) => Q (if I is true and B is false, Q is implied)

5. The loop terminates (this can be difficult to prove)

- The loop invariant I is a weakened version of the loop postcondition, and it is also a precondition.

- I must be weak enough to be satisfied prior to the beginning of the loop, but when combined with the
loop exit condition, it must be strong enough to force the truth of the postcondition

Evaluation of axiomatic semantics:

 To define semantics/meaning, there must be an axiom or inference rule for each

statement type
 Defining axioms or inference rule for some statements/language constructs is difficult.
 So, design a language with the axiomatic method in mind.
 It is limited, but useful for language users.
 Axiomatic semantics is a powerful tool for research into program correctness proofs.

Dept. of CSE. MECS 33