CSC3315 (Spring 2009) 1

CSC 3315CSC 3315Programming Programming LanguagesLanguages

Hamid HarroudHamid HarroudSchool of Science and Engineering, Akhawayn School of Science and Engineering, Akhawayn

UniversityUniversityhttp://www.aui.ma/~H.Harroud/csc3315/

Programming Languages A programming paradigm is a certain methodology for

programming a machine to solve problems. A programming paradigm hence provides (and determines)

the view that the programmer has of the execution of a program.

Major programming paradigms that exist today are:– Imperative

– Functional

– Object-oriented

– Logic

Imperative Prgramming Imperative programming: the most widely

used programming paradigm Emerged and developed alongside the first

computers, and remained popular We will discuss the key features that

characterize the imperative programming paradigm

Imperative languages are said to be Turing Complete.

Imperative Prgramming

Theorem: a programming language is Turing Complete if it contains: integer variables, values, and operations assignment statements control constructs of statement sequencing

Basically conditionals and branching statements

So this is all a programming language really needs to be useful for writing programs,

But is this enough in practice?

Imperative Prgramming Modern imperative languages typically also

have a number of other features, such as: Variables Basic data types (floats, strings, boolean) Advanced control structures (loops, switch) Complex data types (arrays, structures,

enumerations, pointers, etc.) Subprograms Input/output commands

Why? More friendly to programmers, and hence better software maintainability

Variables A variable is an abstraction of a memory cell, Use of variables relieves programmers from the burden of

memory addressing, A variable exists as a name in a high-level program (written

by programmer). A variable exists as a memory location in the executable program.

In high-level languages, a programmer uses variables to indirectly access and modify memory memory management is left to the operating system; the detail of

where variables are actually stored during program execution is now conveniently hidden from the programmer.

Variable Attributes

Variables are characterized by six main attributes: 1) Name 2) Address (storage) 3) Value 4) Type 5) Lifetime 6) Scope

Static & Dynamic Binding

A binding is some kind of association between two entities.

Binding time is the time at which a binding takes place

A binding is said to be static if it first occurs before run time and remains unchanged throughout the program execution

A binding is said to be dynamic if it first occurs at runtime and/or can change during program execution

Static & Dynamic Binding

We are concerned with the binding of a variable to its attributes

When are the attributes of a variable defined? Name: compile-time Value: run-time Address: load-time, run-time Type: compile-ime, run-time Scope: compile-time, run-time

Type Binding Possible binding times of the type of a

variable: 1) Compile time: the binding is done during

compilation of the source program => Static type binding 2) Run time: the binding is done during the

execution of the program => Dynamic type binding

Static Type Binding Explicit type declaration: type of a variable is

specified via declaration statement in the program. Implicit type declaration: a default mechanism for

specifying type of a variable based on its first appearance in the program. Example: in Fortran the type of a variable is determined

based on first letter of variable name; I, J, K, L, M, N => integer, all other letters => float

Dynamic Type Binding

Type is determined during runtime based on RHS value of an assignment statement in which variable appears as the LHS Example: JavaScript, Matlab

list = [2, 4.33, 6, 8]; => list is now an array of floats

list = ‘this’; => list is now a string Flexible, but Inefficient (slow), because type

checking and storage allocation repeatedly done whenever an assignment statement is executed

Address Binding

Address binding: when/how does the variable become associated with a memory location => Hence this involves allocating storage for the

variable (to store its value) Obviously, this is related to the lifetime of the

variable Lifetime of a variable: the time interval during

which the variable is bound to a memory address

Address Binding Possible binding times of address of a variable:

1) Load time: binding is done during linking/loading of the executable program into memory (to prepare it for execution)

=> Static address binding 2) Run time: binding is done during the execution of the

program

=> Dynamic address binding (Compile time is never an address binding time!)

Type Binding

Storage allocation: getting memory cell(s) from some pool of available cells

Storage deallocation: putting a cell back into the pool Who does storage allocation and deallocation?

=> the operating system (OS) Storage for variables comes from two places: the runtime stack and the runtime heap

These are two chunks of memory managed by the operating system, and used to allocate memory for all executing programs

Address Binding There are four categories of variables, according to their address binding

properties: 1) Static static address binding (at load time) 2) Stack dynamic 3) Explicit heap dynamic 4) Implicit heap dynamic

1, 2, 3 dynamic address binding (at runtime)

In C, C++, and Java, only the first three categories are used. Implicit heap dynamic variables are typically used in conjunction with

dynamic type binding.

Address Binding & Lifetime

Static variables: load time => end of program execution

Stack-dynamic variables: execution of declaration stmt => execution of last stmt

before variable goes out of scope Explicit heap-dynamic variables:

execution of alloc stmt => execution of dealloc stmt Implicit heap-dynamic variables:

execution of assignment stmt of some variable => execution of next assignment stmt of same variable

Type Checking

When discussing the type attribute of variables, a related issue is that of type checking

Type checking basically has to do with making sure the operands in any operation are of compatible types

In general, these operands could be variables, constants, or expressions containing both

Type Checking

A compatible type: one that is either legal for the operation, or is allowed to be implicitly converted to a legal type, based on coercion rules of the language

Coercion: implicit conversion of the type of a variable or an expression Implicit means that the conversion is done

automatically by the compiler (by adding type conversion instructions in the code) or interpreter

Type Checking

Type checking is the activity of ensuring that the operands of an operation are of compatible types

A type error is the application of an operator to an operand of an incompatible type

Type checking in a language is done based on both its operator type compatibility rules and coercion rules

Type Checking

If all type bindings are static, then nearly all type checking can be static, i.e. done at compile time With some exceptions. Example: unions in C,

polymorphism in C++ (OOP) If type bindings are dynamic, then type

checking must be dynamic (done at runtime); the compiler cannot do type checking if the type itself is unknown!

Scope

The scope rules of a language specify how the occurrence of a user-defined name in a program statement is associated with the correct name declaration The name could be that of a variable, data type,

subprogram Example: if we have a program statement

i=1;=> we need to know which variable declaration with

variable name i this occurrence of i corresponds to

Scope

Two common types of scope rules exist in languages: Static scope: the scope of a variable is known at

compile-time Dynamic scope: the scope of a variable can only be

determined at runtime Static scope is the most commonly used in

languages today (C, C++, Java, Fortran, …). Dynamic scope is used in Scheme (Lisp),

which is a functional language.

Static Scope

Static scope rules are applied by the compiler to associate a name reference with a declaration as follows: When a reference to a name x is encountered,

compiler first searches declarations in the local scope (i.e. block), then in the parent scope, then in the grandparent scope, etc.; the search stops when a declaration with the given name is found

If no declaration is found in any of the enclosing scopes, then compiler flags a semantic error

Static Scope

Static Scope

Static Scope

Static Scope

C++ and Java allow access to hidden variables via explicit use of the scope operator

Dynamic Scope

Based on the subprogram call sequence (and not the spatial layout of program units)

References to variables are connected to declarations by searching back through the chain of subprogram calls that led to this point

A called subprogram is granted access to local variables of all other currently active subprograms

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 func() {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 func()