Part 1 - PPL
Part 1 - PPL
Topics / Content
Overview
The Origins of Programming Languages
Abstractions in Programming Languages
Computational Paradigms
Language Definition
Language Translation
Reference:
Kenneth C. Louden and Kenneth A. Lambert, Programming
Languages: Principles and Practice, 3rd Edition, Cengage Learning.
Pages 3 to 19
And Supplementary Instructional Manual
Origins of Programming
Example
6
0
Assembly Language
Example
LD R1, FIRST
In assembly language. The mnemonic symbol LD (short
for load) translates to the binary opcode 0010 seen in
line 1 of Figure 1.2. The symbols R1 and FIRST translate
to the register number 001 and the data address offset
000000100, respectively. After translation, another
program, called a loader, automatically loads the
machine code for this instruction into computer
memory.
Abstractions in Programming
Languages
Abstractions in Programming
Languages
To abstract means simply to hide
something.
pseudo code example:
Abstractions in Programming
Languages
Control abstraction:
Examples : loops, conditional statements,
and procedure calls
Data abstraction :
Examples : as numbers, character strings,
and search tree.
encapsulation
information hiding.
#include <iostream.h>
class Add
{
private:
int x,y,r;
public:
int Addition(int x, int y)
{
r= x+y;
return r;
}
void show( )
{ cout << "The sum is::" << r <<
"\n";}
}s;
void main()
{
Add s;
s.Addition(10, 4);
s.show();
}
Abstractions
Levels of Abstractions
Measures of the amount of information
contained (and hidden) in the abstraction.
Basic abstractions collect the most
localized machine information.
Structured abstractions collect
intermediate information about the
structure of a program.
Unit abstractions collect large-scale
information in a program
Variable
var x : integer
Variable
Data Type
Control Abstraction
FIRST
SECOND
SUM
Memory
Example:
operation x += 10 is the same as
x = x + 10,
in C, Java, and Python.
Structured Abstractions
Parameters:
things that change
from call to call
Javascript Example:
Note that even if the threads are started in sequence (1, 2, 3 etc.)
they may not execute sequentially, meaning thread 1 may not be
the first thread to write its name to System.out.
This is because the threads are in principle executing in parallel
and not sequentially. T
he JVM and/or operating system determines the order in which
the threads are executed. This order does not have to be the same
order in which they were started.
Principles of Programming
Languages
Part 2
Computational Paradigms
Language Definition
Language Syntax
The syntax of a programming language is in many
ways like the grammar of a natural language. It is the
description of the ways different parts of the language
may be combined to form phrases and, ultimately,
sentences.
Language Syntax
The description of language syntax is one of the areas
where formal definitions have gained acceptance, and
the syntax of all languages is now given using a
grammar. For example, a grammar rule for the C if
statement can be written as follows:
Language Syntax
Language Syntax
If else Statement in Java
Language Syntax
If else Statement in Visual Basic 6.0
Language Syntax
If else Statement in C
Language Syntax
If else Statement in PHP
Language Syntax
The lexical structure of a programming language is
the structure of the languages words, which are
usually called tokens.
Thus, lexical structure is similar to spelling in a
natural language.
In the example of a C if statement, the words if and else
are tokens. Other tokens in programming languages
include identifiers (or names), symbols for operations,
such as + and * and special punctuation symbols such
as the semicolon (;) and the period (.).
Language Syntax
Language Syntax
Language Syntax
Tokens in C:
Language Syntax
Tokens in Java:
Language Semantics
Syntax represents only the surface structure of a
language and, thus, is only a small part of a language
definition. The semantics, or meaning, of a language
is much more complex and difficult to describe
precisely.
The first difficulty is that meaning can be defined in
many different ways. Typically, describing the
meaning of a piece of code involves describing the
effects of executing the code, but there is no standard
way to do this.
Language Semantics
Moreover, the meaning of a particular mechanism
may involve interactions with other mechanisms in
the language, so that a comprehensive description of
its meaning in all contexts may become extremely
complex.
Language Semantics
This description itself points out some of the
difficulty in specifying semantics, even for a simple
mechanism such as the if statement.
The description makes no mention of what happens if
the condition evaluates to 0, but there is no else part
(presumably nothing happens; that is, the program
continues at the point after the if statement).
Language Semantics
Another important question is whether the if
statement is safe in the sense that there are no
other language mechanisms that may permit the
statements inside an if statement to be executed
without the corresponding evaluation of the if
expression.
If so, then the if-statement provides adequate
protection from errors during execution, such as
division by zero:
if (x != 0) y = 1 / x;
Language Semantics
Otherwise, additional protection mechanisms may be
necessary (or at least the programmer must be aware
of the possibility of circumventing the if expression).
The alternative to this informal description of
semantics is to use a formal method. However, no
generally accepted method, analogous to the use of
context-free grammars for syntax, exists here either..
Language Semantics
Indeed, it is still not customary for a formal definition
of the semantics of a programming language to be
given at all.
Nevertheless, several notational systems for formal
definitions have been developed and are increasingly
in use. These include:
operational semantics
denotational semantics
axiomatic semantics.
Language Translation
Language Translation
For a programming language to be useful, it must have
a translatorthat is, a program that accepts other
programs written in the language in question and that
either executes them directly or transforms them into
a form suitable for execution.
A translator that executes a program directly is called
an interpreter, while a translator that produces an
equivalent program in a form suitable for execution is
called a compiler.
Language Translation
Language Translation
Compilation, on the other hand, is at least a two-step
process:
Language Translation
More commonly, the target language is assembly
language, and the target program must be translated
by an assembler into an object program, and then
linked with other object programs, and loaded into
appropriate memory locations before it can be
executed.
Sometimes the target language is even another
programming language, in which case a compiler for
that language must be used to obtain an executable
object program.
Principles of Programming
Languages
Part 3
Language Design
When creating a new language, its essential to decide on an overall goal for the
language, and then keep that goal in mind throughout the entire design
process.
This is particularly important for special purpose languages, such as database
languages, graphics languages, and real-time languages, because the particular
abstractions for the target application area must be built into the language
design.
However, it is true for general-purpose languages as well.
For example, the designers of FORTRAN focused on efficient execution, whereas
the designers of COBOL set out to provide an English-like nontechnical
readability.
Algol60 was designed to provide a block-structured language for describing
algorithms and Pascal was designed to provide a simple instructional language to
promote top-down design.
Finally, the designer of C++ focused on the users needs for greater abstraction
while preserving efficiency and compatibility with C.
Historical Overview
In the early days of programming, machines were extremely slow and memory
was scarce. Program speed and memory usage were, therefore, the prime
concerns.
Also, some programmers still did not trust compilers to produce efficient
executable code (code that required the fewest number of machine instructions
and the smallest amount of memory).
Thus, one principal design criterion really mattered: efficiency of
execution.
For example, FORTRAN was specifically designed to allow the programmer to
generate compact code that executed quickly.
Indeed, with the exception of algebraic expressions, early FORTRAN code more or
less directly mapped to machine code, thus minimizing the amount of translation
that the compiler would have to perform.
Historical Overview
Judging by todays standards, creating a high-level programming language
that required the programmer to write code nearly as complicated as machine
code might seem counterproductive.
After all, the whole point of a high-level programming language is to make
life easier for the programmer.
In the early days of programming, however, writability the quality of a
language that enables a programmer to use it to express a computation
clearly, correctly, concisely, and quicklywas always subservient to efficiency.
Moreover, at the time that FORTRAN was developed, programmers were less
concerned about creating programs that were easy for people to read and
write, because programs at that time tended to be short, written by one or a
few programmers, and rarely revised or updated except by their creators.
Historical Overview
By the time COBOL and Algol60 came on the scene, in
the 1960s, languages were judged by other criteria
than simply the efficiency of the compiled code.
For example, Algol60 was designed to be suitable or
expressing algorithms in a logically clear and concise
wayin other words, unlike FORTRAN, it was
designed for easy reading and writing by people.
Historical Overview
To achieve this design goal, Algol60s designers
incorporated block structure, structured control
statements, a more structured array type, and
recursion.
These features of the language were very effective.
For example, C. A. R. Hoare understood how to express his
QUICKSORT algorithm clearly only after learning Algol60.
Historical Overview
COBOLs designers attempted to improve the readability of
programs by trying to make them look ike ordinary written
English.
In fact, the designers did not achieve their goal. Readers
were not able to easily understand the logic or behavior of
COBOL programs.
They tended to be so long and verbose that they were harder
to read than programs written in more formalized code.
But human readability was, perhaps for the first time, a
clearly stated design goal
148
149
Chapter 3
Louden
Conflicting advice
Efficiency
150
Chapter 3
Louden
151
Chapter 3
Louden
152
Chapter 3
Louden
153
Chapter 3
Louden
154
155
Chapter 3
Louden
Generality deficiencies
In pascal, procedures can be passed as
parameters, but no procedure variable.
Pascal has no variable length arrays length is
defined as part of definition (even when
parameter)
156
Chapter 3
Louden
Orthogonality: independence
Not context sensitive
Seems similar to generality but more of an odd
decision rather than a limitation.
For example, if I buy a sweater, I may have the
following choices:
short sleeve, long sleeve, or sleeveless
small, medium, or large
red, green, or blue
157
Chapter 3
Louden
158
Orthogonality
Chapter 3
Louden
159
Chapter 3
Louden
160
161
Chapter 3
Louden
162
Chapter 3
Louden
163
Chapter 3
Louden
164
Chapter 3
Louden
165
Chapter 3
Louden
166
Chapter 3
Louden
167
Chapter 3
Louden
168
Chapter 3
Louden
169
Chapter 3
Louden
170
Chapter 3
Louden
171
Chapter 3
Louden