Scribd
Upload
40 views5 pages

PPL Lecture5

The document discusses subprograms, abstract data types, encapsulation constructs, and naming encapsulations in programming languages. It covers key concepts like parameter passing methods, design issues for abstraction, and techniques for organizing large programs into logical units to manage complexity and compilation.

Uploaded by

kunalpatil8010201413
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
40 views5 pages

PPL Lecture5

The document discusses subprograms, abstract data types, encapsulation constructs, and naming encapsulations in programming languages. It covers key concepts like parameter passing methods, design issues for abstraction, and techniques for organizing large programs into logical units to manage complexity and compilation.

Uploaded by

kunalpatil8010201413
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

SPPU Principle of Programming Notes.

(Lecture 5)

Subprograms
Fundamentals of Sub Programs
A subprogram definition is a description of the actions of the subprogram
abstraction. A subprogram call is an explicit request that the called subprogram
be executed. A subprogram is said to be active if, after having been called, it has
begun execution but has not yet completed that execution. The two fundamental
types of the subprograms are:
1) Procedures
2) Functions

Procedures: provide user-defined parameterized computation statements. The


computations are enacted by single call statements. Procedures can produce
results in the calling program unit by two methods: o If there are variables that
are not formal parameters but are still visible in both the procedure and the calling
program unit, the procedure can change them. o If the subprogram has formal
parameters that allow the transfer of data to the caller, those parameters can be
changed.

Functions: provide user-defined operators which are semantically modeled on


mathematical functions. o If a function is a faithful model, it produces no side
effects. o It modifies neither its parameters nor any variables defined outside the
function.

Design Issues for Subprograms

1. What parameter passing methods are provided?


2. Are parameter types checked?
3. Are local variables static or dynamic?
4. Can subprogram definitions appear in other subprogram definitions?
5. What is the referencing environment of a passed subprogram?
6. Can subprograms be overloaded?
7. Are subprograms allowed to be generic?

Parameter passing methods.

SPPU NOTES YOUTUBE CHANNEL- UR ENGINEERING FREIND


1. Pass-by-Value: When a parameter is passed by value, the value of the
actual parameter is used to initialize the corresponding formal parameter,
which then acts as a local var in the subprogram, thus implementing in-
mode semantics
2. Pass-by-Result - Pass-by-Result is an implementation model for out-mode
parameters. When a parameter is passed by result, no value is transmitted to
the subprogram. The corresponding formal parameter acts as a local var, but
just before control is transferred back to the caller, its value is transmitted back
to the caller’s actual parameter, which must be a var.One problem with the
pass-by-result model is that there can be an actual parameter collision, such as
the one created with the call. sub (p1, p1)

3. Pass-by-Value-Result - It is an implementation model for input-mode


parameters in which actual values are copied. It is a combination of pass-by-
value and pass-by-result. The value of the actual parameter is used to initialize
the corresponding formal parameter, which then acts as a local var.

4. Pass-by-reference- Pass-by-reference is a second implementation model


for in out-mode parameters. Rather than copying data values back and forth.
This method transmits an access path, sometimes just an address, to the called
subprogram. This provides the access path to the cell storing the actual
parameter

5. Pass-by-Name - The method is an in out-mode parameter transmission that


does not correspond to a single implementation model. ƒ When parameters
are passed by name, the actual parameter is, in effect, textually substituted for
the corresponding formal parameter in all its occurrences in the subprogram

Abstract Data Types and Encapsulation Construct


Design issues for Abstraction
Abstract Data type (ADT) is a type (or class) for objects whose behavior is
defined by a set of values and a set of operations. The definition of ADT only
mentions what operations are to be performed but not how these operations
will be implemented. It does not specify how data will be organized in
memory and what algorithms will be used for implementing the operations. It
is called “abstract” because it gives an implementation-independent view.

SPPU NOTES YOUTUBE CHANNEL- UR ENGINEERING FREIND


1. The form of the container for the interface to the type.

2. Whether abstract data types can be parameterized.

3. What access controls are provided and how such controls are specified.

4. Whether the specification of the type is physically separate from its


implementation (or whether that is a developer choice).

Parameterized Abstract Data types

It is often convenient to be able to parameterize abstract data types. For example,


we should be able to design a stack abstract data type that can store any scalar
type elements rather than be required to write a separate stack abstraction for
every different scalar type. Note that this is only an issue for static typed
languages. In a dynamic typed language like Ruby, any stack implicitly can store
any type elements. In fact, different elements of the stack could be of different
types.

Ada
Packages can also be generic, so we can construct generic, or parameterized,
abstract data types.

The Ada stack abstract data type example suffers two restrictions:
(1) Stacks of its type can store only integer type elements, and
(2) the stacks can have only up to 100 elements.

Encapsulation Constructs
When the size of a program reaches beyond a few thousand lines, two practical
problems become evident. From the programmer’s point of view, having such a
program appear as a single collection of subprograms or abstract data type
definitions does not impose an adequate level of organization on the program to
keep it intellectually manageable. The second practical problem for larger
programs is recompilation. For relatively small programs, recompiling the whole
program after each modification is not costly. But for large programs, the cost of
recompilation is significant. So, there is an obvious need to find ways to avoid
recompilation of the parts of a program that are not affected by

SPPU NOTES YOUTUBE CHANNEL- UR ENGINEERING FREIND


a change. The obvious solution to both problems is to organize programs into
collections of logically related code and data, each of which can be compiled
without recompilation of the rest of the program. An encapsulation is such a
collection.

Encapsulations are often placed in libraries and made available for reuse in
programs other than those for which they were written. People have been writing
programs with more than a few thousand lines for at least the last 50 years, so
techniques for providing encapsulations have been evolving for some time.

Naming Encapsulations
Libraries are the origin of the same kind of naming problems. Over the past two
decades, large software systems have become progressively more dependent on
libraries of supporting software. Nearly all software written in contemporary
programming languages requires the use of large and complex standard libraries,
in addition to application-specific libraries. This widespread use of multiple
libraries has necessitated new mechanisms for managing names.

Naming encapsulations define name scopes that assist in avoiding these name
conflicts. Each library can create its own naming encapsulation to prevent its
names from conflicting with the names defined in other libraries or in client code.
Each logical part of a software system can create a naming encapsulation with the
same purpose.

Naming encapsulations are logical encapsulations, in the sense that they need not
be contiguous. Several different collections of code can be placed in the same
namespace, even though they are stored in different places.

SPPU NOTES YOUTUBE CHANNEL- UR ENGINEERING FREIND


SPPU NOTES YOUTUBE CHANNEL- UR ENGINEERING FREIND

You might also like