Programming Language

Concepts
Main Topics
 Reasons for studying programming languages
 Programming Domains
 Language Evaluation Criteria
 Influences on Language Design
 Language Categories
 Language Design Tradeoffs
 Implementation Methods
 Programming Environments
2
Why Study PLC?
 Increased capacity to express ideas
 Improved background for choosing
appropriate languages
 Increased ability to learn new languages
 Better understanding of the significance of
implementation
 Increased ability to design new languages
 Overall advancement of computing

3
Increased capacity to express ideas
 Programming language constrains
 Control structures
 Data structures
 Abstractions that can be used
 Awareness of language features reduces
these limitations
 Features of one language may be simulated in
another
 Study of PLC builds appreciation for language
features and encourages their use

4
Language Evaluation Criteria
 Readability
 Writability
 Reliability
 Cost

5
Readability
 Overall Simplicity
 Control Statements
 Data Types and Structures
 Syntax Considerations

6
Writability
 Support for abstraction
 Process abstraction
 Data abstraction
 Expressivity
 APL has powerful operators that accomplish lots of
computation with little coding
 for statements for counting loops (instead of
while)
 and then, or else Boolean operators in Ada

7
Reliability
 Type checking
 Subscript ranges: Ada vs. C
 Static vs. dynamic type checking
 Exception handling
 Intercept runtime errors, take action to correct
problem, and continue processing
 PL/I, C++, Ada, Java
 Aliasing
 2 or more ways to reference same memory cell
 Possible via pointers, reference parameters, unions

8
Costs
 Training programmers
 Writing programs
 Compiling programs
 Executing programs
 Language implementation system
 Poor reliability
 Maintaining programs
9
Language Categories
 Imperative
 Functional
 Logic
 Object-oriented

10
Language Design Tradeoffs
 Reliability vs. cost of execution
 Ada’s runtime type checking adds to execution
overhead
 Readability vs. writability
 C and APL
 Flexibility vs. safety
 Pascal variant record is a flexible way to view a
data object in different ways, but no type
checking is done to make it safe

11
 Questions to Ponder
 What are language design criteria?
 What are some design trade-offs?
 What are some language design
criteria that are in direct conflict
with each other?

12
Influences on Language Design
 Computer architecture
 Imperative languages model von Neumann
architecture
 Functional programming languages need a non-von
Neumann architecture to be implemented efficiently
 Programming methodologies
 Top-down design, stepwise refinement
 Data-oriented vs. process-oriented design
 Object-oriented design
 Concurrency (process-oriented)

13
Implementation methods
 Compilation
 Interpretation
 Hybrid implementation systems
 Java applets are compiled into byte code
 Compiled applets are downloaded and
interpreted by byte code interpreter

14
Evolution of Major
Programming Languages
Evolution Language

15
Lexical and Syntax Analysis

Describing Syntax and Semantics

Lexical and Syntax Analysis
 Definitions
 Syntax: the form or structure of the expressions,
statements, and program units
 Semantics: the meaning of the expressions,
statements, and program units
 Sentence: a string of characters over some
alphabet
 Language: a set of sentences
 Lexeme: the lowest level syntactic unit of a
language (e.g., *, sum, begin)
 Token: a category of lexemes (e.g., identifier)
17
Describing Syntax
 Recognizers: used by compilers
 A grammar is used to describe the
syntax of a language.
 A context-free grammar can be used
to develop language translators.

18
Context-Free Grammar
 A context-free grammar is one whose
productions take the form A  ,
where A is a single non-terminal symbol
and  is any string of terminals and/or
non-terminals.
 Context-free grammars are used to
describe the syntax of modern
programming languages.
19
Derivation
 A derivation is a repeated application of rules,
starting with the start symbol and ending with
a sentence. In each step of a derivation,
exactly one non-terminal is expanded.
 Every string of symbols in a derivation is a
sentential form. A sentential form may
contain terminal and non-terminal symbols.
 A sentence is a sentential form that has only
terminal symbols.
20
Parse Trees
 Grammars describe the hierarchical
syntactic structure of sentences in the
language they define
 These hierarchical structures are called
parse trees.
 Every internal node is labeled with a non-
terminal symbol
 Every leaf is labeled with a terminal symbol
21
Questions to Ponder
 What’s syntax and semantics?
 What’s syntax analysis?
 What’s lexical analysis?
 What’s a lexeme and a token?
 What are grammars used for?

22
Names, Bindings, Type
Checking, and Scopes
Naming
 Naming is the process by which the
programmer associates a name with a
potentially complicated program fragment
 The goal is to hide complexity
 Programming languages use name to designate
variables, types, classes, methods, operators,…
 Naming provides abstraction
 E.g. Mathematics is all about the formal notation
(i.e. naming) that lets us explore more and more
abstract concepts

24
 Variable Names

Design issues
- What should the maximum length be?
- Are connector characters allowed?
- Are names case sensitive?
- Are special words reserved words or keywords?

Length

- FORTRAN I: maximum 6
- COBOL: maximum 30
- FORTRAN 90 and ANSI C: maximum 31
- Ada: no limit, and all are significant
- C++: no limit, but implementers often impose one
25
 Variable Names

Case sensitivity
Disadvantage: readability (names that look alike are different)

• C, C++, Java, and Modula-2 names are case sensitive

• The names in other languages are not

Special words
A keyword is a word that is special only in certain contexts
Disadvantage: poor readability

A reserved word is a special word that cannot be used as a user-

defined name
26
 Variable Names
A variable is an abstraction of a memory cell

Variables can be characterized as a collection of attributes:

name, address, value, type, lifetime, and scope

Name - not all variables have them

Address - the memory address with which it is associated

• A variable may have different addresses at different times
during execution
• A variable may have different addresses at different places
in a program
• If two variable names can be used to access the same
memory location, they are called aliases
27
Attributes of variables
 Name—not all variables have a name
 Address
 The memory address with which a variable
is associated
 A variable may have different addresses at
different times
 Two names that can be used to access the
same memory location are called aliases

28
Attributes of variables
 Type
 Determines the range of values of variables
and the set of operations defined for those
values
 Value
 The contents of the location with which a
variable is associated

29
Some definitions
 Binding—an association, such as
 between an attribute and an entity, or
 between an operation and a symbol
 Binding time—the time at which a
binding takes place

30
Binding times
 Compile time
 Example: binding of a variable to a type in C
 Load time
 Example: binding of a C static variable to a
memory cell
 Run time
 Example: binding of a non-static local variable
to a memory cell

31
More on binding
 A binding is static if it
 occurs before run time and
 remains unchanged throughout execution
 A binding is dynamic if it
 Occurs during execution, or
 Can change during execution

32
Scope
 The scope of a variable is the range of
statements over which it is visible
 The non-local variables of a program unit are
those that are visible but not declared there
 The scope rules of a language determine how
references to names are associated with
variables
 Scope may be static or dynamic

33
 Static scope
 Based on the text of a program

 To connect a name reference to a variable,

the compiler must find the declaration
 Search process: search declarations, first locally,
then in increasingly larger enclosing scopes, until
one is found for the given name.

34
Dynamic scope
 Based on calling sequences of program
units, not their textual layout

 References to variables are connected to

declarations by searching back through the
chain of subprogram calls that forced
execution to this point

35
Scope vs. lifetime
 Scope and lifetime are sometimes closely related,
but are different concepts.
 Consider a static variable in a C or C++ function:
void fun() {
static int x = 0;
int y = 0;
…
}
 Scope of x and y is from point of declaration to end of
function block
 Lifetime of x is entire execution of program
 Lifetime of y is during execution of fun()

36
 Scope and Blocks
Blocks - a method of creating static scopes
inside program units. Example:

C and C++:

for (...) {
int index;
...
}

37
Variable initialization
 The binding of a variable to a value at
the time it is bound to storage is called
initialization
 Initialization is often done on the
declaration statement:

 C++: float sum = 0.0;

38
 Type Checking
Type checking is the activity of ensuring that the
operands of an operator are of compatible types
A compatible type is one that is either legal for the
operator, or is allowed under language rules to be
implicitly converted, by compiler-generated code, to a
legal type.
A type error is the application of an operator to an
operand of an inappropriate type
A programming language is strongly typed if type
errors are always detected

39
 Strong Typing
Allows the detection of the misuses
of variables that result in type
errors.

C and C++ don’t have strong

typing: parameter type checking
can be avoided; unions are not type
checked (Java is similar)
40
 Questions to Ponder
 What are some design issues for names?
 What is static and dynamic scoping?
 What is type checking?
 What’s strong typing?

41
 Data Types
Statement-Level Control Structures
 Abstract Data Types

Abstract Data Type

- the use of type is separated from the
representation and operations on values
of that type

43
 Ordinal Types ( user defined )

An ordinal type is one in which the range of

possible values can be easily associated
with the set of positive integers.
Enumeration Types
- one in which the user enumerates all of
the possible values, which are symbolic
constants
 Design Issue:

Should a symbolic constant be allowed to

be in more than one type definition?
44
 Arrays
• An array is an aggregate of homogeneous
data elements in which an individual element
is identified by its position in the aggregate,
relative to the first element.
 Specific element of an array is identified by:

i) Aggregate name;
ii) Index (subscript):

position relative to the first element.

45
 Design Issues for Arrays

1. What types are legal for subscripts?

2. Are subscripting expressions in
element references range checked?
3. When are subscript ranges bound?
4. When does allocation take place?
5. What is the maximum number of
subscripts?
6. Can array objects be initialized?
46
 Pointers
A pointer type is a type in which the range of values
consists of memory addresses and a special value,
null. The value null indicates that a pointer cannot
currently be used to reference another object.

Design Issues:

1. What is the scope and lifetime of pointer variables?

2. What is the lifetime of heap-dynamic variables?
3. Are pointers restricted to pointing at a particular type?
4. Are pointers used for dynamic storage management, indirect
addressing, or both?
5. Should a language support pointer types, reference types, or
both?

47
 Fundamental Pointer Operations

1. Assignment: Sets a pointer variable to the

address of some object.
2. References: Obtaining the value of the
memory cell whose address is in the memory
cell to which the pointer variable is bound to.
In C and C++, dereferencing is specified by
prefixing a identifier of a pointer type by the
dereferencing operator (*).

48
 Problems with pointers

1. Dangling pointers (dangerous)

- A pointer points to a heap-dynamic variable that
has been de-allocated

2. Memory Leak (wasteful)

- A heap dynamic variable that is no longer
referenced by any program pointer

49
 Levels of Control Flow

The flow of control, or execution sequence, in program can be

examined at several levels:
1. Within expressions
2. Among program units
3. Among program statements

Def: Statements that provide capabilities such as,

selecting among alternative control flow paths or
causing the repeated execution of certain collection
of statements are called control statements
Def: A control structure is a control statement and the
statements whose execution it controls
50
 Classification of Control Statements

 Selection statements: Choose between two or more

execution paths in a program.
Two-way selection statements:
Select one of two execution paths—if-then-else statements.
Design issues
 What is the form and type of the expression that controls

the selection
 Can a single statement, a sequence of statements, or a

compound statement be selected

 How should the meaning of nested selectors be specified

51
 Multiple selection constructs

Multiple selection construct allows the selection of one or

any number of statements or statement groups (switch
construct).
Design issues for multiple way selectors:
 What is the type and form of expression that controls the selection?
 May single statement, sequence of statements or compound
statement be selected?
 Is the entire construct encapsulated in a syntactic structure?
 Is execution flow through the structure restricted to include just one
selectable segment?
 How should unrepresented selector expression values be handled, if
at all?
52
 Iterative Statements

The repeated execution of a statement or compound

statement is accomplished either by iteration or
recursion.

General design Issues for iteration control statements:

1. How is iteration controlled?

2. Where is the control mechanism in the loop?

The primary possibilities for iteration control are

logical, counting or combination of this two. Main
choices for the location of the control mechanism are
top or bottom of the loop.( posttest, or pretest)
53
 Questions to Ponder
 What are some common data types?
 What are some design issues associated
with arrays and pointers?
 What are some design issues related to
control structures?

54
Subprograms

Fundamentals of Subprograms
Design Issues for Subprograms
 Subprogram Definitions

1. A subprogram has a single entry point

2. The caller is suspended during execution of the called subprogram
3. Control always returns to the caller when the called subprogram’s
execution terminates

A subprogram definition is a description of the actions of the subprogram

abstraction

A subprogram call is an explicit request that the subprogram be executed

A subprogram header is the first line of the definition, including the name,
the kind of subprogram, and the formal parameters

The parameter profile of a subprogram is the number, order, and types of

its parameters
56
 Design Issues for Subprograms

1. What parameter passing methods are provided?

2. Are parameter types checked?
3. Are local variables static or dynamic?
4. What is the referencing environment of a passed
subprogram?
5. Are parameter types in passed subprograms
checked?
6. Can subprogram definitions be nested?
7. Can subprograms be overloaded?
8. Are subprograms allowed to be generic?
9. Is separate or independent compilation
supported?
57
 Implementing Parameter Passing

Value or Name - copy it to the stack;

passes the identify for the parameter

Result – same

Reference - regardless of form, put the

address in the stack. Evaluate the
address of the parameter

58
 Design Considerations for
Parameter Passing

1. Efficiency
2. One-way or two-way

- These two are in conflict with one another!

Good programming => limited access to

variables, which means one-way whenever
possible

Efficiency => pass by reference is fastest way to

pass structures of significant size

59
 Parameters that are
Subprogram Names

1. Are parameter types checked?

2. What is the correct referencing environment
for a subprogram that was sent as a parameter?

- Possibilities:
a. It is that of the subprogram that enacts it.
- Shallow binding

b. It is that of the subprogram that declared it.

- Deep binding
60
 Generic
Subprograms
A generic or polymorphic subprogram is one that
takes parameters of different types on different
activations

Overloaded subprograms provide polymorphism

A subprogram that takes a generic parameter that

is used in a type expression that describes the
type of the parameters of the subprogram
provides parametric polymorphism

61
 Functions

Design Issues:

1. Are side effects allowed?

2. What types of return values are allowed?
3. What should the variable access method be?

The non-local variables of a subprogram are those

that are visible but not declared in the subprogram

Global variables are those that may be visible in all

of the subprograms of a program

62
Questions to Ponder
 What are some design issues for
subprograms?
 What are some design issues for
parameter passing?
 What is polymorphism?
 What are some design issues for
functions?

63
Object-Oriented, Functional and
Logical Programming Languages
 Object-Oriented Languages
Abstract Data Types are called classes
Class instances are called objects

A class that inherits is a derived class or a subclass

The class from which another class inherits is a parent
class or superclass

Subprograms that define operations on objects are

called methods
In the simplest case, a class inherits all of the entities of
its parent
65
 Pure Functional Languages
 The concept of assignment is not part of functional
programming
1. no explicit assignment statements
2. variables bound to values only through parameter binding at
functional calls
3. function calls have no side-effects
4. no global state

 Control flow: functional calls and conditional

expressions
 no iteration!
 repetition through recursion

66
 FPLs vs imperative languages
 Imperative programming languages
 Design is based directly on the von Neumann architecture
 Efficiency is the primary concern, rather than the suitability
of the language for software development
 Functional programming languages
 The design of the functional languages is based on
mathematical functions
 A solid theoretical basis that is also closer to the user, but
relatively unconcerned with the architecture of the machines
on which programs will run

67
Lambda expressions
 A mathematical function is a mapping of members of
one set, called the domain set, to another set, called
the range set
 A lambda expression specifies the parameter(s)
and the mapping of a function in the following form
(x) x * x * x
for the function
cube (x) = x * x * x
 Lambda expressions describe nameless functions

68
 Fundamentals of FPLs
 The objective of the design of a FPL is to mimic
mathematical functions as much as possible
 The basic process of computation is fundamentally
different in a FPL than in an imperative language:
 In an imperative language, operations are done and the
results are stored in variables for later use
 Management of variables is a constant concern and source
of complexity for imperative programming languages
 In an FPL, variables are not necessary, as is the case in
mathematics
 The evaluation of a function always produces the
same result given the same parameters. This is
called referential transparency
69
 LISP

 Functional language developed in the mid 50’s

 Semantics based on the lambda-calculus
 All functions operate on lists or symbols (called S-
expressions)
 Only 6 basic functions
 list functions: cons, car, cdr, equal, atom
 conditional construct: cond
 Useful for list processing
 Useful for Artificial Intelligence applications:
programs can read and generate other programs
70
 Scheme
 A mid-1970s dialect of LISP, designed
to be a cleaner, more modern, and
simpler version than the contemporary
dialects of LISP
 Functions are first-class entities
 They can be the values of expressions and
elements of lists
 They can be assigned to variables and
passed as parameters
71
Prolog
PROgramming in LOGic
 It is the most widely used logic
programming language
 Its development started in 1970
 What’s it good for?
 Knowledge representation
 Natural language processing
 State-space searching (Rubik’s cube)
 Expert systems, deductive databases, Agents
72
Overview of
Logic Programming
 Main idea: Ask the computer to solve
problems using principles of logic:
 Program states the known facts
 To ask a question, you make a statement
and ask the computer to search for a proof
that the statement is true
 Additional mechanisms are provided to
guide the search to find a proof

73
 Declarative vs. Imperative
 Languages used for logic programming are called
declarative languages because programs written in
them consist of declarations rather than assignment
and flow-of-control statements. These declarations
are statements, or propositions, in symbolic logic.
 Programming in imperative languages (e.g., Pascal,
C) and functional languages (e.g., Lisp) is
procedural, which means that the programmer knows
what is to be accomplished by the program and
instructs the computer on exactly how the
computation is to be done.

74
Logic Programming
 Programming in logic programming languages
is non-procedural.
 Programs in such languages do not state how
a result is to be computed. Instead, we
supply the computer with:
 relevant information (facts and rules)
 a method of inference for computing desired
results.
 Logic programming is based on the predicate
calculus.
75
 Questions to Ponder
 What are some characteristics of
Object-Oriented, Functional and Logical
Programming Languages?
 What’s the difference between
Declarative and Imperative
Programming Languages?

76