UNIT-III

ABSTRACT DATA TYPES

Abstraction:

- The concept of abstraction is fundamental in programming

- Nearly all programming languages support process abstraction with subprograms

- Nearly all programming languages designed since 1980 have supported data abstraction with some
kind of module

Encapsulation:

- Original motivation:

- Large programs have two special needs:

1. Some means of organization, other than simply division into subprograms

2. Some means of partial compilation (compilation units that are smaller than the whole program)

- Obvious solution: a grouping of subprograms that are logically related into a unit that can be
separately compiled

- These are called encapsulations

Examples of Encapsulation Mechanisms:

1. Nested subprograms in some ALGOL-like languages (e.g., Pascal)

2. FORTRAN 77 and C - Files containing one or more subprograms can be independently compiled

3. FORTRAN 90, C++, Ada (and other contemporary languages) - separately compliable modules

Definitions: An abstract data type is a user-defined datatype that satisfies the following two conditions:

Definition 1: The representation of and operations of objects of the type are defined in a single
syntactic unit; also, other units can create objects of the type.

Definition 2: The representation of objects of the type is hidden from the program units that use
these objects, so the only operations possible are those provided in the type's definition .
Advantage of Restriction 1:

- Same as those for encapsulation: program organization, modifiability (everything

associated with a data structure is together), and separate compilation

Advantage of Restriction 2:

- Reliability--by hiding the data representations, user code cannot directly access objects
of the type. User code cannot depend on the representation, allowing the representation to be
changed without affecting user code.

Built-in types are abstract data types:

EX: int type in C

- The representation is hidden

- Operations are all built-in

- User programs can define objects of int type

- User-defined abstract data types must have the same characteristics as built-in abstract data
types

Language Requirements for Data Abstraction:

1. A syntactic unit in which to encapsulate the type definition.

2. A method of making type names and subprogram headers visible to clients, while hiding
actual definitions.

3. Some primitive operations must be built into the language processor (usually just assignment
and comparisons for equality and inequality)

- Some operations are commonly needed, but must be defined by the type designer

- e.g., iterators, constructors, destructors

Language Design Issues:

1. Encapsulate a single type, or something more?

2. What types can be abstract?

3. Can abstract types be parameterized?

4. What access controls are provided?

Language Examples:
1. Simula 67

- Provided encapsulation, but no information hiding

2. Ada

- The encapsulation construct is the package

- Packages usually have two parts:

1. Specification package (the interface)

2. Body package (implementation of the entities named in the specification

- Any type can be exported

- Information Hiding

- Hidden types are named in the spec package in, as in:

type NODE_TYPE is private;

- Representation of an exported hidden type is specified in a special invisible (to clients) part of
the spec package (the private clause), as in:

package … is

type NODE_TYPE is private;

type NODE_TYPE is

record

end record;

…
 - A spec package can also define unhidden type simply by providing the representation outside a
private clause

The reasons for the two-part type definition are:

1. The compiler must be able to see the representation after seeing only the spec package (the
compiler can see the private clause)

2. Clients must see the type name, but not the representation (clients cannot see the private clause)

Parameterized Abstract Data Types

• Parameterized ADTs allow designing an ADT that can store any type elements (among other things)

• Also known as generic classes

• C++, Ada, Java 5.0, and C# 2005 provide support for parameterized ADTs
Parameterized ADTs in Ada
• Ada Generic Packages
–Make the stack type more flexible by making the element type and the size of the stack generic
generic
Max_Size: Positive;
type Elem_Type is private;
package Generic_Stack is
Type Stack_Type is limited private;
function Top(Stk: in out StackType) return Elem_type;
…
end Generic_Stack;
Package Integer_Stack is new Generic_Stack(100,Integer);
Package Float_Stack is new Generic_Stack(100,Float);
Parameterized ADTs in C++
• Classes can be somewhat generic by writing parameterized
constructor functions
class stack {
…
stack (int size)
{ stk_ptr = new int
[size]; max_len = size -
1;
top = -1;
};
…
}
stack stk(100);
• The stack element type can be parameterized by making the class a template class
template <class Type>
class stack {
private:
Type *stackPtr;
const int maxLen;
int topPtr;
public:
stack() {
stackPtr = new Type[100];
maxLen = 99;
topPtr = -1;
}
…
}
Parameterized Classes in Java 5.0
• Generic parameters must be classes
• Most common generic types are the collection types, such as Linked List and Array List
• Eliminate the need to cast objects that are removed
• Eliminate the problem of having multiple types in a structure
Parameterized Classes in C# 2005
• Similar to those of Java 5.0
• Elements of parameterized structures can be accessed through indexing
• The concept of ADTs and their use in program design was a milestone in the development of
languages
• Two primary features of ADTs are the packaging of data with their associated operations and
information hiding
• Ada provides packages that simulate ADTs
• C++ data abstraction is provided by classes
• java‘s data abstraction is similar to C++
• Ada, C++, Java 5.0, and C# 2005 support parameterized ADTs

Object-Oriented Programming
• Abstract data types
• Inheritance
–Inheritance is the central theme in OOP and languages that support it
• Polymorphism
Inheritance
• Productivity increases can come from reuse
–ADTs are difficult to reuse—always need changes
–All ADTs are independent and at the same level
• Inheritance allows new classes defined in terms of existing ones, i.e., by allowing them to inherit
common parts
• Inheritance addresses both of the above concerns--reuse ADTs after minor changes and define classes
in a hierarchy
Object-Oriented Concepts
• ADTs are usually 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 super class
• Subprograms that define operations on objects are called methods
• Calls to methods are called messages
• The entire collection of methods of an object is called its message protocol or message interface
• Messages have two parts--a method name and the destination object
• In the simplest case, a class inherits all of the entities of its parent

• Inheritance can be complicated by access controls to encapsulated entities

–A class can hide entities from its subclasses
–A class can hide entities from its clients
–A class can also hide entities for its clients while allowing its subclasses to see them
• Besides inheriting methods as is, a class can modify an inherited method
–The new one overrides the inherited one
–The method in the parent is overridden
• There are two kinds of variables in a class:
 Class variables - one/class
Instance variables - one/object
• There are two kinds of methods in a class:
Class methods – accept messages to the class
Instance methods – accept messages to objects
Dynamic Binding
• A polymorphic variable can be defined in a class that is able to reference (or point to) objects of the
class and objects of any of its descendants
• When a class hierarchy includes classes that override methods and such methods are called through a
polymorphic variable, the binding to the correct method will be dynamic
• Allows software systems to be more easily extended during both development and maintenance
Dynamic Binding Concepts

• An abstract method is one that does not include a definition (it only defines a protocol)

• An abstract class is one that includes at least one virtual method

• An abstract class cannot be instantiated

Design Issues for OOP Languages: The Exclusivity of Objects

•Are Subclasses Subtypes
•Type Checking and Polymorphism
•Single and Multiple Inheritance
•Object Allocation and DeAllocation
•Dynamic and Static Binding
•Nested Classes
 UNIT-IV

Concurrency can occur at four levels:

1. Machine instruction level
2. High-level language statement level
3. Unit level
4. Program level
Because there are no language issues in instruction- and program-level
concurrency, they are not addressed here
The Evolution of Multiprocessor Architectures:
1. Late 1950s - One general-purpose processor and one or more special-purpose processors for
input and output operations

2. Early 1960s - Multiple complete processors, used for program-level concurrency

3. Mid-1960s - Multiple partial processors, used for instruction-level concurrency
4. Single-Instruction Multiple-Data (SIMD) machine The same instruction goes to all
processors, each with different data - e.g., vector processors
5. Multiple-Instruction Multiple-Data (MIMD) machines, Independent processors that can be
synchronized (unit-level concurrency)
Def: A thread of control: in a program is the sequence of program points reached as control
flows through the program

Categories of Concurrency:
1. Physical concurrency - Multiple independent processors ( multiple threads of control)
2. Logical concurrency - The appearance of physical concurrency is presented by time sharing
one processor (software can be designed as if there were multiple threads of control)
- Coroutines provide only quasiconcurrency

Reasons to Study Concurrency:

1. It involves a new way of designing software that can be very useful--many real-world
situation involve concurrency
2. Computers capable of physical concurrency are now widely used
Fundamentals (for stmt-level concurrency) :
Def: A task is a program unit that can be in concurrent execution with other program units
- Tasks differ from ordinary subprograms in that:
1. A task may be implicitly started
2. When a program unit starts the execution of a task, it is not necessarily suspended
 3. When a task’s execution is completed, control may not return to the caller
Def: A task is disjoint if it does not communicate with or affect the execution of any other task in the
program in any way Task communication is necessary for synchronization

- Task communication can be through:

1. Shared nonlocal variables
2. Parameters
3. Message passing
- Kinds of synchronization:
1. Cooperation

- Task A must wait for task B to complete some specific activity before task A can continue its
execution
e.g., the producer-consumer problem
2. Competition
- When two or more tasks must use some resource that cannot be simultaneously used
e.g., a shared counter
- A problem because operations are not atomic
- Competition is usually provided by mutually exclusive access (methods are discussed later
- Providing synchronization requires a mechanism for delaying task execution
- Task execution control is maintained by a program called the scheduler, which maps task
execution onto available processors
- Tasks can be in one of several different execution states:
1. New - created but not yet started
2. Runnable or ready - ready to run but not currently running (no available processor)
3. Running
4. Blocked - has been running, but cannot not continue (usually waiting for some event to
occur)
5. Dead - no longer active in any sense
Liveness is a characteristic that a program unit may or may not have
- In sequential code, it means the unit will eventually complete its execution
- In a concurrent environment, a task can easily lose its liveness
- If all tasks in a concurrent environment lose their liveness, it is called deadlock
- Design Issues for Concurrency:
1. How is cooperation synchronization provided?
2. How is competition synchronization provided?
3. How and when do tasks begin and end execution?
 4. Are tasks statically or dynamically created?
Example: A buffer and some producers and some consumers
Technique: Attach two SIGNAL objects to the buffer, one for full spots and one for empty spots
Methods of Providing Synchronization:
1. Semaphores
2. Monitors
3. Message Passing
1. Semaphores (Dijkstra - 1965)
- A semaphore is a data structure consisting of a counter and a queue for storing task descriptors
- Semaphores can be used to implement guards on the code that accesses shared data structures
- Semaphores have only two operations, wait and release (originally called P and V by Dijkstra)
- Semaphores can be used to provide both competition and cooperation synchronization
Cooperation Synchronization with Semaphores:
Example: A shared buffer
- The buffer is implemented as an ADT with the operations DEPOSIT and FETCH as the only
ways to access the buffer.
Use two semaphores for cooperation:
Empty spots and full spots
- The semaphore counters are used to store the numbers of empty spots and full spots in the buffer
- DEPOSIT must first check empty spots to see if there is room in the buffer
- If there is room, the counter of empty spots is decremented and the value is inserted
- If there is no room, the caller is stored in the queue of empty spots
- When DEPOSIT is finished, it must increment the counter of full spots
- FETCH must first check full spots to see if there is a value
- If there is a full spot, the counter of full spots is decremented and the value is removed
- If there are no values in the buffer, the caller must be placed in the queue of full spots
- When FETCH is finished, it increments the counter of empty spots
- The operations of FETCH and DEPOSIT on the semaphores are accomplished through two
semaphore operations named wait and release wait (aSemaphore)
if a Semaphore’s counter > 0 then Decrement aSemaphore’s counter
else
Put the caller in aSemaphore’s queue Attempt to transfer control to some
ready task
(If the task ready queue is empty, deadlock occurs)
end
release(aSemaphore)
 if aSemaphore’s queue is empty then
Increment aSemaphore’s counter
else
Put the calling task in the task ready queue Transfer control to a task from aSemaphore’s queue

end
- Competition Synchronization with Semaphores:
- A third semaphore, named access, is used to control access (competition synchronization)
- The counter of access will only have the values 0 and 1
- Such a semaphore is called a binary semaphore
SHOW the complete shared buffer example
- Note that wait and release must be atomic!

Evaluation of Semaphores:
1. Misuse of semaphores can cause failures in cooperation synchronization
e.g., the buffer will overflow if the wait of full spots is left out
2. Misuse of semaphores can cause failures in competition synchronization
e.g., The program will deadlock if the release of access is left out

:
2. Monitors ( Concurrent Pascal, Modula, Mesa)

The idea: encapsulate the shared data and it operations to restrict access
A monitor is an abstract data type for shared data show the diagram of monitor buffer operation,
- Example language: Concurrent Pascal
- Concurrent Pascal is Pascal + classes, processes (tasks), monitors, and the queue data type (for
semaphores)
Example language: Concurrent Pascal (continued) processes are types
Instances are statically created by declarations
- An instance is “started” by init, which allocate its local data and begins its execution
- Monitors are also types Form:
type some_name = monitor (formal parameters)
shared variables , local procedures
exported procedures (have entry in definition) initialization code

Competition Synchronization with Monitors:

- Access to the shared data in the monitor is limited by the implementation to a single process at a
time; therefore, mutually exclusive access is inherent in the semantic definition of the monitor
- Multiple calls are queued
 - Cooperation Synchronization with Monitors:
- Cooperation is still required - done with semaphores, using the queue data type and the built-in
operations, delay (similar to send) and continue (similar to release)

- delay takes a queue type parameter; it puts the process that calls it in the specified queue and
removes its exclusive access rights to the monitor’s data structure
- Differs from send because delay always blocks the caller
- continue takes a queue type parameter; it disconnects the caller from the monitor, thus freeing the
monitor for use by another process.
-It also takes a process from the parameter queue (if the queue isn’t empty) and starts it, Differs from
release because it always has some effect (release does nothing if the queue is empty)

Java Threads
• The concurrent units in Java are methods named run
– A run method code can be in concurrent execution with other such methods
– The process in which the run methods execute is called a thread
Class myThread extends Thread
public void run () {…}
}
…
Thread myTh = new MyThread ();
myTh.start();
Controlling Thread Execution
• The Thread class has several methods to control the execution of threads
The yield is a request from the running thread to voluntarily surrender the processor
– The sleep method can be used by the caller of the method to block the thread
– The join method is used to force a method to delay its execution until the run method of another thread
has completed its execution
Thread Priorities
• A thread‘s default priority is the same as the thread that create it
– If main creates a thread, its default priority is NORM_PRIORITY
• Threads defined two other priority constants, MAX_PRIORITY and MIN_PRIORITY
• The priority of a thread can be changed with the methods setPriority
Cooperation Synchronization with Java Threads
• Cooperation synchronization in Java is achieved via wait, notify, and notifyAll methods
– All methods are defined in Object, which is the root class in Java, so all objects inherit them
• The wait method must be called in a loop
• The notify method is called to tell one waiting thread that the event it was waiting has happened
• The notifyAll method awakens all of the threads on the object‘s wait list
Java’s Thread Evaluation
• Java‘s support for concurrency is relatively simple but effective
• Not as powerful as Ada‘s tasks
C# Threads

• Loosely based on Java but there are significant differences

• Basic thread operations

– Any method can run in its own thread
– A thread is created by creating a Thread object
– Creating a thread does not start its concurrent execution; it must be requested through the Start method
– A thread can be made to wait for another thread to finish with Join
– A thread can be suspended with Sleep
– A thread can be terminated with Abort

Synchronizing Threads

• Three ways to synchronize C# threads

– The Interlocked class

• Used when the only operations that need to be synchronized are incrementing or decrementing of an
integer
– The lock statement
• Used to mark a critical section of code in a thread
lock (expression) {… }
– The Monitor class
• Provides four methods that can be used to provide more
EXCEPTION HANDLING
In a language without exception handling:
When an exception occurs, control goes to the operating system, where a message is displayed
and the program is terminated
In a language with exception handling:
Programs are allowed to trap some exceptions, thereby providing the possibility of fixing the
problem and continuing. Many languages allow programs to trap input/ output errors (including EOF)
Definition 1:
An exception is any unusual event, either erroneous or not, detectable by either hardware or
software, that may require special processing
Definition 2: The special processing that may be required after the detection of an exception is called
exception handling
Definition 3: The exception handling code unit is called an exception handler
Definition 4: An exception is raised when its associated event occurs
A language that does not have exception handling capabilities can still define, detect, raise, and handle
exceptions
- Alternatives:
1. Send an auxiliary parameter or use the return value to indicate the return status of a
Subprogram
- e.g., C standard library functions
2. Pass a label parameter to all subprograms (error return is to the passed label)
- e.g., FORTRAN
3. Pass an exception handling subprogram to all subprograms

Advantages of Built-in Exception Handling:

1. Error detection code is tedious to write and it clutters the program
2. Exception propagation allows a high level of reuse of exception handling code

Design Issues for Exception Handling:

1. How and where are exception handlers specified and what is their scope?
2. How is an exception occurrence bound to an exception handler?
3. Where does execution continue, if at all, after an exception handler completes its execution?
4. How are user-defined exceptions specified?
5. Should there be default exception handlers for programs that do not provide their own?
6. Can built-in exceptions be explicitly raised?
7. Are hardware-detectable errors treated as exceptions that can be handled?
8. Are there any built-in exceptions?
7. How can exceptions be disabled, if at all?
PL/I Exception Handling
- Exception handler form:
EX:
ON condition [SNAP]
BEGIN;
...
END;
- condition is the name of the associated exception
- SNAP causes the production of a dynamic trace to the point of the exception
- Binding exceptions to handlers
- It is dynamic--binding is to the most recently executed ON statement
- Continuation
- Some built-in exceptions return control to the statement where the exception was raised
- Others cause program termination
- User-defined exceptions can be designed to go to any place in the program that is labeled
- Other design choices:
- User-defined exceptions are defined with:
CONDITION exception_name
- Exceptions can be explicitly raised with:
SIGNAL CONDITION (exception_name)
- Built-in exceptions were designed into three categories:
a. Those that are enabled by default but could be disabled by user code
b. Those that are disabled by default but could be enabled by user code
c. Those that are always enabled
- Evaluation
- The design is powerful and flexible, but has the following problems:
a. Dynamic binding of exceptions to handler makes programs difficult to write and to read
b. The continuation rules are difficult to implement and they make programs hard
to read
Ada Exception Handling
Def: The frame of an exception handler in Ada if either a subprogram body, a package body,
a task, or a block
- Because exception handlers are usually local to the code in which the exception can be raised, they
do not have parameters
- Handler form:
exception
when exception_name {| exception_name} =>
statement_sequence
...
when ..
...
[when others =>
statement_sequence]
- Handlers are placed at the end of the block or unit in which they occur
- Binding Exceptions to Handlers
- If the block or unit in which an exception is raised does not have a handler for that exception,
the exception is propagated elsewhere to be handled
1. Procedures - propagate it to the caller
2. Blocks - propagate it to the scope in which it occurs
3. Package body - propagate it to the declaration part of the unit that declared the
package (if it is a library unit (no static parent), the program is terminated)
4. Task - no propagation; if it has no handler, execute it; in either case, mark it "completed"

- Continuation
- The block or unit that raises an exception but does not handle it is always terminated (also any block
or unit to which it is propagated that does not handle it)
- User-defined Exceptions:
exception_name_list : exception;
raise [exception_name]
(the exception name is not required if it is in a handler--in this case, it propagates the same exception)
- Exception conditions can be disabled with:
pragma SUPPRESS(exception_list)
- Predefined Exceptions:
CONSTRAINT_ERROR - index constraints, range constraints, etc.
NUMERIC_ERROR - numeric operation cannot return a correct value, etc.
PROGRAM_ERROR - call to a subprogram whose body has not been elaborated
STORAGE_ERROR - system runs out of heap
TASKING_ERROR - an error associated with tasks
- Evaluation
- The Ada design for exception handling embodies the state-of-the-art in language design in 1980
- A significant advance over PL/I
- Ada was the only widely used language with exception handling until it was added to C++
C++ Exception Handling :
- Added to C++ in 1990
- Design is based on that of CLU, Ada, and ML

C++ Exception Handlers

•Exception Handlers Form:
try {
-- code that is expected to raise an exception
}
catch (formal parameter) {
-- handler code
}
...
catch (formal parameter) {
-- handler code
}
The catch Function
• catch is the name of all handlers--it is an overloaded name, so the formal parameter of each must be
unique
•The formal parameter need not have a variable
–It can be simply a type name to distinguish the handler it is in from others
•The formal parameter can be used to transfer information to the handler
•The formal parameter can be an ellipsis, in which case it handles all
Exception Handling in Java

• Based on that of C++, but more in line with OOP philosophy

•All exceptions are objects of classes that are descendants of the Throwable class
Classes of Exceptions

• The Java library includes two subclasses of Throwable:

–Error
• Thrown by the Java interpreter for events such as heap overflow
• Never handled by user programs
–Exception
• User-defined exceptions are usually subclasses of this
• Has two predefined subclasses, IOException and
RuntimeException (e.g., ArrayIndexOutOfBoundsException and NullPointerException

Java Exception Handlers

• Like those of C++, except every catch requires a named parameter and all parameters must be
descendants of Throwable
•Syntax of try clause is exactly that of C++
•Exceptions are thrown with throw, as in C++, but often the throw includes the new operator to create the
object, as in: throw new MyException ();
Binding Exceptions to Handlers
•Binding an exception to a handler is simpler in Java than it is in C++
–An exception is bound to the first handler with a parameter is the same class as the thrown object or an
ancestor of it
•An exception can be handled and rethrown by including a throw in the handler (a handler could also
throw a different exception)
Continuation
• If no handler is found in the method, the exception is propagated to the method‘s caller
• If no handler is found (all the way to main), the program is terminated
•To ensure that all exceptions are caught, a handler can be included in any try construct that catches all
exceptions
–Simply use an Exception class parameter
–Of course, it must be the last in the try construct
Checked and Unchecked Exceptions

• The Java throws clause is quite different from the throw clause of C++
•Exceptions of class Error and RunTimeException and all of their descendants are called unchecked
exceptions; all other exceptions are called checked exceptions
•Checked exceptions that may be thrown by a method must be either:
–Listed in the throws clause, or Handled in the method
Other Design Choices
•A method cannot declare more exceptions in its throws clause than the method it overrides
•A method that calls a method that lists a particular checked exception in its throws clause has three
alternatives for dealing with that exception:
–Catch and handle the exception
–Catch the exception and throw an exception that is listed in its own throws clause
–Declare it in its throws clause and do not handle it
The finally Clause
•Can appear at the end of a try construct
•Form:
finally {
...
}
•Purpose: To specify code that is to be executed, regardless of what happens in the try construct
Example
•A try construct with a finally clause can be used outside exception handling
try {
for (index = 0; index < 100; index++) {
…
if (…) {
return;
} //** end of if
} //** end of try clause
finally {
…
} //** end of try construct
LOGIC PROGRAM PARADIGM:

 Based on logic and declarative programming 60’s and early 70’s, Prolog (Programming
in logic, 1972) is the most well known representative of the paradigm.
 Prolog is based on Horn clauses and SLD resolution
 Mostly developed in fifth generation computer systems project
 Specially designed for theorem proof and artificial intelligence but allows general
purpose computation.
 Some other languages in paradigm: ALF, Frill, G¨odel,, Mercury, Oz, Ciao, _Prolog, datalog, and
CLP languages

Constrain Logic Programming:

Clause: disjunction of universally quantified literals, 8(L1 _ L2 _ ... _ Ln)

A logic program clause is a clause with exactly one positive literal

8(A _ ¬A1 _ ¬A2... _ ¬An) _

8(A ( A1 ^ A2... ^ An)

A goal clause: no positive literal

8(¬A1 _ ¬A2... _ ¬An)

Proof: by refutation, try to un satisfy the clauses with a goal clause G. Find 9(G).

Linear resolution for definite programs with constraints and selected atom.

CLP on first order terms. (Horn clauses).

Unification. Bidirectional.

Backtracking. Proof search based on trial of all matching clauses

Prolog terms:

Atoms:
  1 Strings with starting with a small letter and consist of
o [a-zA-Z 0-9]*
o a aDAM a1 2
 2 Strings consisting of only punctuation
 *** .+. .<.>.
 3 Any string enclosed in single quotes (like an arbitrary string)
o ’ADAM’ ’Onur Sehitoglu’’2 * 4 < 6’
 Numbers
o 1234 12.32 12.23e-10

Variables:

 Strings with starting with a capital letter or and consist of

 [a-zA-Z 0-9]*
 Adam adam A093
 is the universal match symbol. Not variable
Structures:

Starts with an atom head have one or more arguments (any term) enclosed in parenthesis, separated
by comma structure head cannot be a variable or anything other than atom.

a(b) a(b,c) a(b,c,d) ++(12) +(*) *(1,a(b)) ’hello world’(1,2) p

X(b) 4(b,c) a() ++() (3) × some structures defined as infix:

+(1,2) _ 1+2 , :-(a,b,c,d) _ a :- b,c,d

Is(X,+(Y,1)) _ X is X + 1

Static sugars:

Prolog interpreter automatically maps some easy to read syntax into its actual structure.

List: [a,b,c] _ .(a,.(b,.(c,[])))

Head and Tail: [H|T] _ .(H,T)

String: "ABC" _ [65,66,67] (ascii integer values) use display (Term). to see actual structure of the term
Unification:

Bi-directional (both actual and formal argument can be instantiated).

1. if S and T are atoms or number, unification successful only if

S=T

2 . if S is a variable, S is instantiated as T, if it is compatible with current constraint store (S is instantiated

to another term, they are unified)

3 if S and T are structures, successful if:

head of S = head of T

they have same arity

unification of all corressponding terms are successful.

S: list of structures, P current constraint store

s 2 S, arity(s): number of arguments of structure,

s 2 S, head(s): head atom of the structure,

s 2 S, argi (s): i th argument term of the structure,

p _ P: p is consistent with current constraint store.

S _ T;P =

(S,T 2 A _ S,T 2 N) ^ S = T ! true’s S 2 V ^ S _ T |= P ! true; S _ T ^ P T 2 V ^ S _ T |= P ! true; S _ T ^ P

S,T 2 S ^ head(S) = head(T) ^ arity(S) = arity(T) !

8i , argi (S) _ argi (T); P

Unification Example:

X = a ! pwith X = a

a(X,3) = a(X,3,2) ! ×

a(X,3) = b(X,3) ! ×
a(X,3) = a(3,X) ! pwith X = 3

a(X,3) = a(4,X) ! × a(X,b(c,d(e,f))) = a(b(c,Y),X) ! X = b(c,d(e,f )), Y = d(e,F)

Declarations:

Two types of clauses:

p1(arg1, arg2, ...) :- p2(args,...) , p3(args,...) .means if p2 and p3 true, then p1 is true. There can be
arbitrary number of (conjunction of) predicates at right hand side.

p(arg1, arg2, ...) .sometimes called a fact. It is equivalent to:

p(arg1, arg2, ...) :- true.

p(args) :- q(args) ; s(args) .

Is disjunction of predicates. q or s implies p. Equivalent to:

p(args) :- q(args).

p(args) :- s(args).

A prolog program is just a group of such clauses.

Lists Example:

% list membership

memb(X, [X| Re s t ]) .

memb(X, [ | Re s t ]) :- memb(X, Re s t ).

% concatenation

conc ([] ,L,L).

conc ([X|R] , L , [X|R and L ]) :- conc (R, L, R and L ).

% second list starts with first list prefix of ([],).

Prefix of ([X|Rx], [X|Ry]) :- prefix of (Rx,Ry).

% second list contains first list

Sublist (L1,L2) :- prefix of (L1,L2).

Sublist (L,[|R]):- sublist(L,R).

Procedural Interpretation:

For goal clause all matching head clauses (LHS of clauses) are kept as backtracking points (like a
junction in maze search) Starts from first match. To prove head predicate, RHS predicates need to be
proved recursively. If all RHS predicates are proven, head predicate is proven. When fails, prolog goes
back to last backtracking point and tries next choice. When no backtracking point is left, goal clause fails.
All predicate matches go through unification so goal clause variables can be instantiated.

Arthematic and Operations:

X = 3+1 is not an arithmetic expression!

operators (is) force arithmetic expressions to be evaluated all variables of the operations needs to be
instantiated.

12 is 3+X does not work!

Comparison operators force LHS and RHS to be evaluated:

X>Y, X<Y, X>=Y, X =< Y, X =:= Y, X == Y

is operator forces RHS to be evaluated: X is Y+3*Y Y needs to have a numerical value when search hits
this expression. Note that X is X+1 is never successful in Prolog. Variables are instantiated once.

Greatest Common Divisor:

gcd(m, n) = gcd(n,m − n) if n < m

gcd(m, n) = gcd(n,m) if m < n

gcd (X,X,X) .

gcd (X,Y,D) :- X < Y, Y1 is Y-X, gcd (X,Y1,D).

gcd (X,Y,D) :- Y < X, gcd (Y, X, D).

Deficiencies of Prolog

•Resolution order control

•The closed-world assumption

•The negation problem

• Intrinsic limitations

Applications of Logic Programming

•Relational database management systems

•Expert systems

•Natural language processing