Part 1 - PPL

8/18/2019 Part 1 - PPL

1/171

Part 1Principles of Programming Languages

8/18/2019 Part 1 - PPL

2/171

Topics / Content• Overview

• The Origins of Programming Languages

• Abstractions in Programming Languages• Computational Paradigms

• Language Definition

• Language Translation

Reference:• enneth C! Louden and enneth A! Lambert" Programming

Languages: Principles and Practice" #rd $dition" Cengage Learning!Pages # to %&

• And 'upplementar( )nstructional *anual

8/18/2019 Part 1 - PPL

3/171

The Origins of Programming Languages

• A vocabular( and set of grammatical rules for instructinga computer to perform specific tas+s!

• The term programming language usuall( refers to high,level languages" such as -A')C" C" C.." CO-OL"/ORTRA0" Ada" and Pascal!

• $ach language has a uni1ue set of +e(words 2words thatit understands3 and a special s(nta4 for organi5ingprogram instructions!

• 6igh,level programming languages" while simplecompared to human languages" are more comple4 thanthe languages the computer actuall( understands" calledmachine languages!

• $ach different t(pe of CP7 has its own uni1ue machinelanguage!

8/18/2019 Part 1 - PPL

4/171

Origins of Programming

8/18/2019 Part 1 - PPL

5/171

8/18/2019 Part 1 - PPL

6/171

The Origins of Programming Languages

• -efore the middle of the %&89s" computer operatorshardwired; their programs!

• That is" the( set switches to ad

8/18/2019 Part 1 - PPL

7/171

Machine Language and the First Stored Programs

• A ma

8/18/2019 Part 1 - PPL

8/171

8/18/2019 Part 1 - PPL

9/171

8/18/2019 Part 1 - PPL

10/171

8/18/2019 Part 1 - PPL

11/171


• )nstead of turning off the computer to reconfigure itscircuits" the operator could flip switches to enter thesecodes" e4pressed in machine language" into computermemor(!

• At this point" computer operators became the first trueprogrammers" who developed software>the machinecode>to solve problems with computers!

8/18/2019 Part 1 - PPL

12/171


• To decode or interpret an instruction" the programmer2and the hardware3 must recogni5e the first 8 bits of theline of code as an opcode" which indicates the t(pe ofoperation to be performed

Instruction Format

• The general format for a machine language i t ti nsruction is Op code Operands The operands can be amemor( address a The operands can be a memor(address" a register or a value!

8/18/2019 Part 1 - PPL

13/171


8/18/2019 Part 1 - PPL

14/171


8/18/2019 Part 1 - PPL

15/171

Example

%! $ach line of code contains %? bits or binar( digits!

@! A line of %? bits represents either a single machine languageinstruction or a single data value!

#! The last three lines of code happen to represent data values>the integers " ?" and 9>using %?,bit twos complementnotation!

8! The first five lines of code represent program instructions!Program e4ecution begins with the first line of code" whichis fetched from memor(" decoded 2interpreted3" ande4ecuted!

! Control then moves to the ne4t line of code" and the processis repeated" until a special halt instruction is reached

5

6

0

8/18/2019 Part 1 - PPL

16/171


• *achine language programming is not for themee+!

• Despite the improvement on the earliermethod of reconfiguring the hardware"programmers were still faced with the tediousand error,prone tas+s of manuall( translating

their designs for solutions to binar( machinecode and loading this code into computermemor(!

8/18/2019 Part 1 - PPL

17/171

Assembler and Machine

• Assembler language is the eas( wa( to writemachine language!

• $ach line of an assembler program generates one

machine language instruction!

• The assembler allows (ou to use variable namesinstead of numerical addresses and instruction

mnemonics instead of numerical operation codes!

• A program called an assembler translates thes(mbolic assembl( language code to binar(machine code! /or e4ample" letBs sa( that the first

instruction in the program

8/18/2019 Part 1 - PPL

18/171

Assembly Language

8/18/2019 Part 1 - PPL

19/171

Example

LD R%" /)R'T

• )n assembl( language! The mnemonic s(mbol LD 2shortfor load;3 translates to the binar( opcode 99%9 seen inline % of /igure %!@! The s(mbols R% and /)R'T translate

to the register number 99% and the data address offset999999%99" respectivel(! After translation" anotherprogram" called a loader" automaticall( loads themachine code for this instruction into computermemor(!

8/18/2019 Part 1 - PPL

20/171

8/18/2019 Part 1 - PPL

21/171

Assembler and Machine• Programmers also used a pair of new input devices>a

keypunch machine to t(pe their assembl( language

codes and a card reader to read the resulting punchedcards into memor( for the assembler!

• These two devices were the forerunners of toda(Bssoftware te4t editors! These new hardware and software

tools made it much easier for programmers to developand modif( their programs!

8/18/2019 Part 1 - PPL

22/171

Assembler and Machine

• The assembler and loader would then update all of theaddress references in the program" a tas+ that machinelanguage programmers once had to perform manuall(!

• *oreover" the assembler was able to catch some errors"

such as incorrect instruction formats and incorrectaddress calculations" which could not be discovered untilrun time in the pre,assembler era!

8/18/2019 Part 1 - PPL

23/171

8/18/2019 Part 1 - PPL

24/171

8/18/2019 Part 1 - PPL

25/171

Fortran and Algebraic Notation

8/18/2019 Part 1 - PPL

26/171


• One of the precursors of these high,levellanguages was /ORTRA0" an acron(m for/ORmula TRA0slation language!

• =ohn -ac+us developed /ORTRA0 in the earl(%&9s for a particular t(pe of )-* computer! )nsome respects" earl( /ORTRA0 code wassimilar to assembl( language!

• )t reflected the architecture of a particular t(peof machine and lac+ed the structured controlstatements and data structures of later high,level languages!

8/18/2019 Part 1 - PPL

27/171


• 6owever" /ORTRA0 did appeal toscientists and engineers" who en

8/18/2019 Part 1 - PPL

28/171


8/18/2019 Part 1 - PPL

29/171

The ALOL Family

•

'oon after /ORTRA0 was introduced" programmersreali5ed that languages with still higher levels of abstraction would improve their abilit( to write concise"understandable instructions!

•*oreover" the( wished to write these high,level

instructions for different machine architectures with nochanges!

•)n the late %&9s" an international committee of computerscientists 2which included =ohn -ac+us3 agreed on a

definition of a new language whose purpose was to satisf( both of these re1uirements!

8/18/2019 Part 1 - PPL

30/171

The ALOL Family

•This language became ALOL 2an acron(m for ALOrithmic Language3! )ts first incarnation" ALOL,?9" was released in %&?9!

• ALOL provided first of all a standard notation forcomputer scientists to publish algorithms in journals! Assuch" the language included notations for structured controlstatements for se1uencing 2begin,end bloc+s3" loops 2the forloop3" and selection 2the if and if,else statements3!

8/18/2019 Part 1 - PPL

31/171

The ALOL Family

•These t(pes of statements have appeared in more or lessthe same form in ever( high,level language since!

•Li+ewise" elegant notations for e4pressing data of differentnumeric t(pes 2integer and float3 as well as the arra( datastructure were available! /inall(" support for procedures"including recursive procedures" was provided!

8/18/2019 Part 1 - PPL

32/171

8/18/2019 Part 1 - PPL

33/171

8/18/2019 Part 1 - PPL

34/171

Abstractions in ProgrammingLanguages

8/18/2019 Part 1 - PPL

35/171

Abstractions in Programming

Languages

To abstract; means simpl( to hidesomething!

pseudo code example:

8/18/2019 Part 1 - PPL

36/171

Two classes of abstraction mechanismsare distinguished

• Control abstraction : provides theprogrammer the abilit( to hideprocedural data

• Data abstraction : allow thedefinition and use of sophisticated datat(pes without referring to how such

t(pes will be implemented

8/18/2019 Part 1 - PPL

37/171

Abstractions in Programming

Languages

Control abstraction:

$4amples : loops" conditional statements,and procedure calls

Data abstraction :

$4amples : as numbers" character strings"and search tree.

8/18/2019 Part 1 - PPL

38/171

• The process of pic+ing out 2abstracting3

common features of ob

8/18/2019 Part 1 - PPL

39/171

•

Abstraction is one of the mostimportant techni1ues in softwareengineering and is closel( related to twoother important techni1ues:

encapsulation information hiding!

All three techni1ues are used to reducecomple4it(!

i l d Ei t hF Th i t l

8/18/2019 Part 1 - PPL

40/171

include Eiostream!hFclass AddGprivate:

int 4"("rHpublic:int Addition2int 4" int (3GrI 4.(Hreturn rHJ void show2 3G cout EE KThe sum is::K EE r EEKnKHJJsH

void main23G Add sHs! Addition2%9" 83Hs!show23H

J

The integer valuesK4"("rK of the classK AddK can beaccessed onl(

through the functionK AdditionK! Theseinteger values areencapsulated insidethe class K AddK!

abstract class -an+G

8/18/2019 Part 1 - PPL

41/171

abstract class -an+ Gabstract int getRateOf)nterest23HJ

class '-) e4tends -an+Gint getRateOf)nterest23Greturn MHJJclass P0- e4tends -an+Gint getRateOf)nterest23Greturn NHJ

J

class Test-an+Gpublic static void main2'tring args3G

-an+ bInew '-)23H QQ orP0-int interestI b!getRateOf)nterest23H'(stem!out!println2KRate of )nterest is: K.interest.KK3H

JJ

Abstractions

8/18/2019 Part 1 - PPL

42/171

Abstractions

Levels of Abstractions

*easures of the amount of informationcontained 2and hidden3 in the abstraction!

•

Basic abstractions collect the mostlocali5ed machine information!

• Structured abstractions collect

intermediate information about thestructure of a program!

• Unit abstractions collect large,scale

information in a program

8/18/2019 Part 1 - PPL

43/171

!ata" #asic Abstractions

6ides the internal representation ofcommon data values in a computer!

a I b . cH

Two values stored in two locations and then storing the result in anew location!!

Shat happens beneath

There are registers" instruction sets" program counters" storageunits" etc involved! There is P7'6" POP happening! 6igh levellanguage we use abstracts those comple4 details!

!

8/18/2019 Part 1 - PPL

44/171


8/18/2019 Part 1 - PPL

45/171


C declaration:

Int x;

var x : integer

Data T(pe Uariable

Uariable Data T(pe

8/18/2019 Part 1 - PPL

46/171

!ata" Structured Abstractions!ata structure

The principal method for collecting related data values into a singleunit!

#mployee record

Contains:

$ame SurnameGiven Name

Address Permanent emporar!

%hone number "obile #andline

8/18/2019 Part 1 - PPL

47/171

!ata" Structured Abstractions

A group of items" all of which have the same data t(pe and which need to be +ept together for purposes of sorting orsearching!

Array : Collects data into a se1uence of individuall( inde4editems! Uariables can name a data structure in a declaration"as in the C: )nt a %9H

which establishes the variable a as the name of an arra( often integer values!


8/18/2019 Part 1 - PPL

48/171



8/18/2019 Part 1 - PPL

49/171


8/18/2019 Part 1 - PPL

50/171


8/18/2019 Part 1 - PPL

51/171

!ata" $nit Abstractions

• Often associated with the concept of an

abstract data type

• a set of data values and the operations onthose values!

• )ts main characteristic is the separationof an interface 2the set of operations

available to the user3 from itsimplementation 2the internalrepresentation of data values andoperations3

8/18/2019 Part 1 - PPL

52/171


$4amples

package of Lisp" Ada" and =ava:

)n =ava:

• &ava'lang , bundles the fundamental classes!

• &ava'io , classes for input " output functions are bundled in thispac+age

8/18/2019 Part 1 - PPL

53/171


8/18/2019 Part 1 - PPL

54/171

!ata" $nit Abstractions Additional propert( of a unit data abstraction that has becomeincreasingl( important:

•

(eusability : the abilit( to reuse the data abstraction indifferent programs" thus saving the cost of writing abstractionsfrom scratch for each program!

T(picall(" such data abstractions represent components2operationall( complete pieces of a program or user interface3 and

are entered into a librar( of available components!

8/18/2019 Part 1 - PPL

55/171


• As such" unit data abstractions become the basis for languagelibrary mechanisms 2the librar( mechanism itself" as well ascertain standard libraries" ma( or ma( not be part of thelanguage itself3!

• The combination of units 2their interoperability 3 is enhanced b( providing standard conventions for their interfaces

8/18/2019 Part 1 - PPL

56/171


• Shen programmers are given a new software resource to use"

the( t(picall( stud( its application programming interface)A%I*!

• An AP) gives the programmer onl( enough information aboutthe resourceBs classes" methods" functions" and performancecharacteristics to be able to use that resource effectivel(!

8/18/2019 Part 1 - PPL

57/171

!ata" $nit Abstractions• An e4ample of an AP) is =avaBs 'wing Tool+it for graphical user

interfaces" as defined in the pac+age

8/18/2019 Part 1 - PPL

58/171

Control Abstraction

8/18/2019 Part 1 - PPL

59/171

%ontrol " #asic Abstractions

'7* I /)R'T . '$CO0D

The code fetches the value of the variables of /)R'T and'$CO0D" adds these values" then store the result locationcalled '7*!

T(pical basic control abstractions are those statements in alanguage that combine a few machine instructions into an

abstract statement that is easier to understand than themachine instructions!

FIRST

SECOND

SUM

*emor(

8/18/2019 Part 1 - PPL

60/171


Syntactic sugar

• A simpler" shorthand notation!• Replacing long notation into shorter one

$4ample:

operation 4 .I %9 is the same as

4 I 4 . %9"

in C" =ava" and P(thon!

8/18/2019 Part 1 - PPL

61/171


8/18/2019 Part 1 - PPL

62/171

%ontrol" Structured Abstractions

'election and iteration are accomplished b( the use of branchinstructions to memor( locations other than the ne4t one!

$4ample:

%ontrol " Structured Abstractions

8/18/2019 Part 1 - PPL

63/171

%ontrol " Structured AbstractionsComments have been added to aid the reader!

)f the comments were not included" even a competent LC,#

programmer probabl( would not be able to tell at a glance what thisalgorithm does!

Compare this assembl( language code with the use of the structuredif and for statements in the functionall( e1uivalent C.. or =ava

8/18/2019 Part 1 - PPL

64/171

Structured Abstractions

• 'tructured control abstractions divide a program into groups ofinstructions that are nested within tests that govern theire4ecution!

• The(" thus" help the programmer to e4press the logic of the

primar( control structures of se1uencing" selection" and iteration2loops3!

• At the machine level" the processor e4ecutes a se1uence ofinstructions simpl( b( advancing a program counter through theinstructionsB memor( addresses!

8/18/2019 Part 1 - PPL

65/171

%ontrol" Structured Abstractions Another structured form of iteration is provided b( an iterator!

)terator

• T(picall( found in ob

8/18/2019 Part 1 - PPL

66/171


$4ample:

The =ava code segment uses an iterator to print the contents of alist" called e4ampleList" of strings

The iterator,based traversal of a collection is such a common looppattern that some languages" such as =ava" provide s(ntactic sugarfor it" in the form of an enhanced for loop

8/18/2019 Part 1 - PPL

67/171

!ata" Structured Abstractions$4ample:

Se can use this t(pe of loop to further simplif( the =ava code forcomputing the sum of either an arra( or a list of integers

8/18/2019 Part 1 - PPL

68/171


8/18/2019 Part 1 - PPL

69/171


• Another powerful mechanism for structuring controlis the procedure" sometimes also called asubprogram or subroutine!

• This allows a programmer to consider a se1uence ofactions as a single action that can be called or invo+edfrom man( other points in a program!

8/18/2019 Part 1 - PPL

70/171

%ontrol " Structured AbstractionsProcedural abstraction involves two things!

• /irst" a procedure must be defined b( giving it a nameand associating with it the actions that are to beperformed! This is called procedure declaration" andit is similar to variable and t(pe declaration" mentioned

earlier!

• 'econd" the procedure must actuall( be called at thepoint where the actions are to be performed!

•This is sometimes also referred to as procedureinvocation or procedure activation!


8/18/2019 Part 1 - PPL

71/171

As an e4ample" consider the sample code fragment thatcomputes the greatest common divisor of integers u and v!

Se can ma+e this into a procedure in Ada:

procedure gcd(u, v: in integer; x: out integer) is

y, t, z: integer;

beginz := u;

y := v;

loop

exit when y = 0;

t := y;

y := z mod y;

z := t;

end loop;

x := z;

end gcd;

%arameters:things that changefrom call to call

8/18/2019 Part 1 - PPL

72/171

%ontrol " Structured Abstractions• The s(stem implementation of a procedure call

is a more comple4 mechanism than selection orlooping" since it re1uires the storing ofinformation about the condition of the programat the point of the call and the wa( the calledprocedure operates! 'uch information is storedin a runtime environment!

• An abstraction mechanism closel( related toprocedures is the function" which can be

viewed simpl( as a procedure that returns a value or result to its caller!


8/18/2019 Part 1 - PPL

73/171


/or e4ample" the Ada code for the gcd procedurecan more appropriatel( be written as a function asgiven below! 0ote that the gcd function uses arecursive strateg( to eliminate the loop thatappeared in the earlier version! The use ofrecursion further e4ploits the abstraction

mechanism of the subroutine to simplif( the code!

Simplified d! "ode:

function gcd2u" v: in integer3 return integer is begin

if v I 9return uH

elsereturn gcd2v" u mod v3H

end ifH

8/18/2019 Part 1 - PPL

74/171

&a'ascript Example"

8/18/2019 Part 1 - PPL

75/171

8/18/2019 Part 1 - PPL

76/171

%ontrol" $nit Abstraction

• *an( modern computers have severalprocessors or processing elements and arecapable of processing different pieces ofdata simultaneousl(!

• A number of programming languagesinclude mechanisms that allow for theparallel e4ecution of parts of programs" as

well as providing for s(nchroni5ation andcommunication among such programparts!

% l $ i Ab i

8/18/2019 Part 1 - PPL

77/171

%ontrol" $nit Abstraction• =ava has mechanisms for declaring threads

2separatel( e4ecuted control paths within the =ava s(stem3and processes 2other programs e4ecuting outside the=ava s(stem3!

•

Ada provides the task mechanism for parallele4ecution!• AdaBs tas+s are essentiall( a unit abstraction"

whereas =avaBs threads and processes are classes andso are structured abstractions" albeit part of the

standard

8/18/2019 Part 1 - PPL

78/171



8/18/2019 Part 1 - PPL

79/171


0ote that even if the threads are started in se1uence 2%" @" # etc!3the( ma( not e4ecute se1uentiall(" meaning thread % ma( not be

the first thread to write its name to '(stem!out! This is because the threads are in principle e4ecuting in parallel

and not se1uentiall(! T he =U* andQor operating s(stem determines the order in which

the threads are e4ecuted! This order does not have to be the sameorder in which the( were started!

8/18/2019 Part 1 - PPL

80/171

Principles of Programming

LanguagesPart @

8/18/2019 Part 1 - PPL

81/171

%omputational Paradigms

8/18/2019 Part 1 - PPL

82/171

• Programming languages began b( imitating andabstracting the operations of a computer!

• )t is not surprising that the +ind of computer for whichthe( were written had a significant effect on theirdesign! )n most cases" the computer in 1uestion was

the von 0eumann model: a single central processingunit that se1uentiall( e4ecutes instructions thatoperate on values stored in memor(!

•These are t(pical features of a language based on the von 0eumann model:V variables represent memor( locations

V assignment allows the program to operate on thesememor( locations!

8/18/2019 Part 1 - PPL

83/171

• A programming language that is characteri5ed b( these three properties>the se1uential

e4ecution of instructions" the use of variablesrepresenting memor( locations" and the use ofassignment to change the values of variables>iscalled an imperative language" because its

primar( feature is a se1uence of statements thatrepresent commands" or imperatives!

8/18/2019 Part 1 - PPL

84/171

• Imperative language : A programminglanguage that is characteri5ed b( these three

properties:

V the se1uential e4ecution of instructions

V the use of variables representing memor(

locations

V the use of assignment to change the values of variables

-ecause its primar( feature is a se1uence ofstatements that represent commands" orimperatives!

8/18/2019 Part 1 - PPL

85/171

• *ost programming languages toda( are imperative" but" it is notnecessar( for a programming language to describe computationin this wa(!

• )ndeed" the re1uirement that computation be described as ase1uence of instructions" each operating on a single piece of data"is sometimes referred to as the von $eumann bottleneck !

V This bottlenec+ restricts the abilit( of a language to provideeither parallel computation" that is" computation that can beapplied to man( different pieces of data simultaneousl(" ornondeterministic computation" computation that does notdepend on order! Thus" it is reasonable to as+ if there are wa(sto describe computation that are less dependent on the von0eumann model of a computer!

• )mperative programming languages actuall( represent onl( one

paradigm" or pattern" for programming languages!

8/18/2019 Part 1 - PPL

86/171

8/18/2019 Part 1 - PPL

87/171

8/18/2019 Part 1 - PPL

88/171

8/18/2019 Part 1 - PPL

89/171

8/18/2019 Part 1 - PPL

90/171

U 0 - l +

8/18/2019 Part 1 - PPL

91/171

• Uon 0eumann -ottlenec+ V )n simplicit(" traffic of data from cpu to memor(

U 0 - l +

8/18/2019 Part 1 - PPL

92/171


U 0 - l +

8/18/2019 Part 1 - PPL

93/171


Alt ti P di id f ) ti

8/18/2019 Part 1 - PPL

94/171

• Alternative Paradigm aside from )mperative

8/18/2019 Part 1 - PPL

95/171

A fo rth programming paradigm the ob&ect oriented

8/18/2019 Part 1 - PPL

96/171

• A fourth programming paradigm" the ob&ect+orientedparadigm" has ac1uired enormous importance over thelast @9 (ears!

V Ob

8/18/2019 Part 1 - PPL

97/171

• The difference is that the resulting programsconsist of a large number of ver( small pieces

whose interactions are carefull( controlled and (et easil( changed!

• *oreover" at a higher level of abstraction" the

interaction among ob

8/18/2019 Part 1 - PPL

98/171

Language Definition

• Documentation for the earl( programming languages was

8/18/2019 Part 1 - PPL

99/171

• Documentation for the earl( programming languages was written in an informal wa(" in ordinar( $nglish!

• 6owever" programmers soon became aware of the need formore precise descriptions of a language" to the point ofneeding formal definitions of the +ind found inmathematics!

V /or e4ample" without a clear notion of the meaning ofprogramming language constructs" a programmer has no clearidea of what computation is actuall( being performed!

V *oreover" it should be possible to reason mathematicall(

about programs" and to do this re1uires formal verification orproof of the behavior of a program!

Sithout a formal definition of a language this is impossible!

The best wa( to achieve the need for formal

8/18/2019 Part 1 - PPL

100/171

• The best wa( to achieve the need for formaldefinition and the need for machine or

implementation independence is throughstandardi5ation" which re1uires an independentand precise language definition that isuniversall( accepted!

• 'tandards organi5ations such as A0')2American 0ational 'tandards )nstitute3 and

)'O 2)nternational Organi5ation for'tandardi5ation3 have published definitions forman( languages" including C" C.." Ada"Common Lisp" and Prolog!

8/18/2019 Part 1 - PPL

101/171

8/18/2019 Part 1 - PPL

102/171

• A further reason for a formal definition is that

8/18/2019 Part 1 - PPL

103/171

• A further reason for a formal definition is that"inevitabl( in the programming process" difficult

1uestions arise about program behaviour andinteraction!

• Programmers need an ade1uate wa( to answer

such 1uestions besides the often,used trial,and,error process: it can happen that such 1uestionsneed to be answered alread( at the design stageand ma( result in ma

8/18/2019 Part 1 - PPL

104/171

8/18/2019 Part 1 - PPL

105/171

• Often a language designer will not reali5e the

conse1uences of design decisions until he or sheis re1uired to produce a clear definition!

• Language definition can be loosel( divided intotwo parts:

,' syntax" or structure" and

-' semantics" or meaning!

Language Syntax

8/18/2019 Part 1 - PPL

106/171

Language Syntax• The s(nta4 of a programming language is in man(

wa(s li+e the grammar of a natural language! )t is thedescription of the wa(s different parts of the languagema( be combined to form phrases and" ultimatel("sentences!

Language Syntax

8/18/2019 Part 1 - PPL

107/171

Language Syntax• The description of language s(nta4 is one of the areas

where formal definitions have gained acceptance" andthe s(nta4 of all languages is now given using agrammar! /or e4ample" a grammar rule for the C ifstatement can be written as follows:

Language Syntax

8/18/2019 Part 1 - PPL

108/171

Language Syntax

Language Syntax

8/18/2019 Part 1 - PPL

109/171

Language Syntax• )f else 'tatement in =ava

Language Syntax

8/18/2019 Part 1 - PPL

110/171

Language Syntax• )f else 'tatement in Uisual -asic ?!9

Language Syntax

8/18/2019 Part 1 - PPL

111/171

Language Syntax• )f else 'tatement in C

Language Syntax

8/18/2019 Part 1 - PPL

112/171

Language Syntax• )f else 'tatement in P6P

Language Syntax

8/18/2019 Part 1 - PPL

113/171

Language Syntax• The lexical structure of a programming language is

the structure of the languageBs words" which areusuall( called tokens!

• Thus" le4ical structure is similar to spelling in anatural language!

V )n the e4ample of a C if statement" the words if and else

are to+ens! Other to+ens in programming languagesinclude identifiers 2or names3" s(mbols for operations"such as . and W and special punctuation s(mbols suchas the semicolon 2H3 and the period 2!3!

Language Syntax

8/18/2019 Part 1 - PPL

114/171

Language Syntax

Language Syntax

8/18/2019 Part 1 - PPL

115/171

Language Syntax

Language Syntax

8/18/2019 Part 1 - PPL

116/171

Language Syntax• To+ens in C:

8/18/2019 Part 1 - PPL

117/171

Language Semantics

8/18/2019 Part 1 - PPL

118/171

Language Semantics• '(nta4 represents onl( the surface structure of a

language and" thus" is onl( a small part of a languagedefinition! The semantics" or meaning" of a languageis much more comple4 and difficult to describeprecisel(!

• The first difficult( is that meaning; can be defined inman( different wa(s! T(picall(" describing the

meaning of a piece of code involves describing theeffects of e4ecuting the code" but there is no standard wa( to do this!

Language Semantics

8/18/2019 Part 1 - PPL

119/171

Language Semantics• *oreover" the meaning of a particular mechanism

ma( involve interactions with other mechanisms inthe language" so that a comprehensive description ofits meaning in all conte4ts ma( become e4tremel(comple4!

Language Semantics

8/18/2019 Part 1 - PPL

120/171

Language Semantics• This description itself points out some of the

difficult( in specif(ing semantics" even for a simplemechanism such as the if statement!

• The description ma+es no mention of what happens ifthe condition evaluates to 9" but there is no else part2presumabl( nothing happensH that is" the programcontinues at the point after the if statement3!

8/18/2019 Part 1 - PPL

121/171

Language Semantics

8/18/2019 Part 1 - PPL

122/171

Language Semantics• Otherwise" additional protection mechanisms ma( be

necessar( 2or at least the programmer must be awareof the possibilit( of circumventing the if e4pression3!

• The alternative to this informal description ofsemantics is to use a formal method! 6owever" nogenerall( accepted method" analogous to the use ofconte4t,free grammars for s(nta4" e4ists here either!!

Language Semantics

8/18/2019 Part 1 - PPL

123/171

a guage Se a t cs• )ndeed" it is still not customar( for a formal definition

of the semantics of a programming language to begiven at all!

• 0evertheless" several notational s(stems for formaldefinitions have been developed and are increasingl(in use! These include:

V operational semantics

V denotational semanticsV axiomatic semantics!

8/18/2019 Part 1 - PPL

124/171

Language Translation


8/18/2019 Part 1 - PPL

125/171


• /or a programming language to be useful" it must havea translator>that is" a program that accepts otherprograms written in the language in 1uestion and thateither e4ecutes them directl( or transforms them into

a form suitable for e4ecution!

• A translator that e4ecutes a program directl( is calledan interpreter" while a translator that produces ane1uivalent program in a form suitable for e4ecution iscalled a compiler!


8/18/2019 Part 1 - PPL

126/171


• An interpreter can be viewed as a simulator for amachine whose machine language; is the language being translated!


8/18/2019 Part 1 - PPL

127/171


• Compilation" on the other hand" is at least a two,stepprocess:

•

%! the original program 2or source program3 is input to

the compiler"@! and a new program 2or target program3 is output

from the compiler!

This target program ma( then be e4ecuted" if it is in aform suitable for direct e4ecution 2i!e!" in machinelanguage3!


8/18/2019 Part 1 - PPL

128/171


• *ore commonl(" the target language is assembl(language" and the target program must be translated b( an assembler into an ob

8/18/2019 Part 1 - PPL

129/171

• Alternativel(" the target language is a form oflow,level code +nown as byte code!

• After a compiler translates a programBs sourcecode to b(te code" the b(te code version of theprogram is e4ecuted b( an interpreter!

8/18/2019 Part 1 - PPL

130/171

• This interpreter" called a virtual machine" is

written differentl( for different hardwarearchitectures" whereas the b(te code" li+e thesource language" is machine,independent!

• Languages such as =ava and P(thon compile to b(te code and e4ecute on virtual machines" whereas languages such as C and C.. compile tonative machine code and e4ecute directl( onhardware!

8/18/2019 Part 1 - PPL

131/171

• )t is important to +eep in mind that a language and thetranslator for that language are two different things! )t ispossible for a language to be defined b( the behaviour of aparticular interpreter or compiler 2a so,called

definitional translator3 but this is not

8/18/2019 Part 1 - PPL

132/171

• *ore often" a language definition e4ists independentl(" and a translator ma( or

ma( not adhere closel( to the language definition 2one hopes the former3!• Shen writing programs one must alwa(s be aware of those features and

properties that depend on a specific translator and are not part of the languagedefinition!

• There are significant advantages to be gained from avoiding nonstandard

features as much as possible!

8/18/2019 Part 1 - PPL

133/171

8/18/2019 Part 1 - PPL

134/171

8/18/2019 Part 1 - PPL

135/171

Principles of Programming

LanguagesPart #

8/18/2019 Part 1 - PPL

136/171

Language !esign

Shat is good programming language design

8/18/2019 Part 1 - PPL

137/171

-( what criteria do we

8/18/2019 Part 1 - PPL

138/171

definition also have a ma

8/18/2019 Part 1 - PPL

139/171

• Languages succeed for as man( different reasonsh f il

8/18/2019 Part 1 - PPL

140/171

as the( fail!

• 'ome language designers argue that anindividual or small group of individuals have a better chance of creating a successful language

because the( can impose a uniform designconcept!

• This was true" for e4ample" with Pascal" C" C.." APL" '0O-OL" and L)'P" but languagesdesigned b( committees" such as CO-OL" Algol"and Ada" have also been successful!

• Shen creating a new language" itBs essential to decide on an overall goal for thelanguage" and then +eep that goal in mind throughout the entire design

8/18/2019 Part 1 - PPL

141/171

process!

• This is particularl( important for special purpose languages" such as databaselanguages" graphics languages" and real,time languages" because the particularabstractions for the target application area must be built into the languagedesign!

• 6owever" it is true for general,purpose languages as well!

V /or e4ample" the designers of /ORTRA0 focused on efficient e4ecution" whereasthe designers of CO-OL set out to provide an $nglish,li+e nontechnicalreadabilit(!

V Algol?9 was designed to provide a bloc+,structured language for describingalgorithms and Pascal was designed to provide a simple instructional language topromote top,down design!

V /inall(" the designer of C.. focused on the usersB needs for greater abstraction while preserving efficienc( and compatibilit( with C!

• 0evertheless" it is still e4tremel( difficult to describe goodprogramming language design!

8/18/2019 Part 1 - PPL

142/171

p g g g g g

•$ven noted computer scientists and successful language designers offerconflicting advice!

• 0i+laus Sirth" the designer of Pascal" advises that simplicit( isparamount !

• C! A! R! 6oare" a prominent computer scientist and co,designer of anumber of languages" emphasi5es the design of individual languageconstructs!

• -

8/18/2019 Part 1 - PPL

143/171

• )n the earl( da(s of programming" machines were e4tremel( slow and memor(

was scarce! Program speed and memor( usage were" therefore" the primeconcerns!

• Also" some programmers still did not trust compilers to produce efficiente4ecutable code 2code that re1uired the fewest number of machine instructionsand the smallest amount of memor(3!

• Thus" one principal design criterion reall( mattered: efficiency ofexecution'

V /or e4ample" /ORTRA0 was specificall( designed to allow the programmer togenerate compact code that e4ecuted 1uic+l(!

V )ndeed" with the e4ception of algebraic e4pressions" earl( /ORTRA0 code more orless directl( mapped to machine code" thus minimi5ing the amount of translationthat the compiler would have to perform!

8/18/2019 Part 1 - PPL

144/171

(istorical O'er'ie)

8/18/2019 Part 1 - PPL

145/171

• -( the time CO-OL and Algol?9 came on the scene" in

the %&?9s" languages were

8/18/2019 Part 1 - PPL

146/171

(istorical O'er'ie)

8/18/2019 Part 1 - PPL

147/171

• CO-OLBs designers attempted to improve the readabilit( of

programs b( tr(ing to ma+e them loo+ i+e ordinar( written$nglish!

• )n fact" the designers did not achieve their goal! Readers

were not able to easil( understand the logic or behavior ofCO-OL programs!

• The( tended to be so long and verbose that the( were harder

to read than programs written in more formali5ed code!

• -ut human readabilit( was" perhaps for the first time" aclearl( stated design goal

%8N

8/18/2019 Part 1 - PPL

148/171

Chapter #Louden

Chapter 3 - Language Design

Principles

Chapter #Louden

%8&

8/18/2019 Part 1 - PPL

149/171

The language design problem• Language design is difficult" and success is hard

to predict:

V Pascal a success" *odula,@ a failureV Algol?9 a success" Algol?N a failure

V /ORTRA0 a success" PLQ) a failure

• Conflicting advice

Chapter #Louden

%9Efficienc• The first; goal 2/ORTRA03: execution e$$icienc!!

8/18/2019 Part 1 - PPL

150/171

g $$ !

• 'till an important goal in some settings 2C.." C3!

• *an( other criteria can be interpreted from thepoint of view of efficienc(:V programming efficienc(: writabilit( or

e4pressiveness 2abilit( to e4press comple4

processes and structures3V reliabilit( 2securit(3!

V maintenance efficienc(: readabilit(!

2saw this as a goal for first time in Cobol3

Chapter #Louden

%%

8/18/2019 Part 1 - PPL

151/171

Other !inds of efficienc• efficienc( of e4ecution 2optimi5able3

• efficienc( of translation! Are there features

which are e4tremel( difficult to chec+ at compiletime 2or even run time3 e!g! Alogol [ prohibitsassignment to dangling pointers

• )mplementabilit( 2cost of writing translator3

Chapter #Louden

%@

8/18/2019 Part 1 - PPL

152/171

"eatures that aid efficienc of e#ecution• 'tatic data t(pes allow efficient allocation and

access!• *anual memor( management avoids

overhead of garbage collection;!• 'imple semantics allow for simple structure

of running programs 2simple environments ,Chapter N3!

Chapter #Louden

%#

$ote conflicts %ith efficienc

8/18/2019 Part 1 - PPL

153/171

$ote conflicts %ith efficienc

• Sritabilit(" e4pressiveness: no static datat(pes 2variables can hold an(thing" no needfor t(pe declarations3! harder to maintain

• Reliabilit(" writabilit(" readabilit(: automatic

memor( management 2no need for pointers3!runs slower

• $4pressiveness" writabilit(" readabilit(: morecomple4 semantics" allowing greaterabstraction! harder to translate

Chapter #Louden

%8

&nternal consistenc of a language design'

(egularit

8/18/2019 Part 1 - PPL

154/171

(egularit

•Regularit( is a measure of how well a languageintegrates its features" so that there are nounusual restrictions" interactions" or behavior!$as( to remember!

• Regularit( issues can often be placed insubcategories:V eneralit(: are constructs general enough 2Or too

general3

V Orthogonalit(: are there strange interactionsV 7niformit(: Do similar things loo+ the same" and do

different things loo+ different

8/18/2019 Part 1 - PPL

155/171

8/18/2019 Part 1 - PPL

156/171

Chapter #Louden

%M

8/18/2019 Part 1 - PPL

157/171

Limitations to s%eater e#ample'• )f it is not possible to get sleeveless sweaters"

that ma( be a lac+ of generalit(!

• )f an( combination of an( attributes can be usedtogether" it is orthogonal!

• )f red sweaters cannot be purchased in a smallsi5e" but other sweaters can" it is non,orthogonal

8/18/2019 Part 1 - PPL

158/171

Chapter #Louden

%&

" l f th lit id

8/18/2019 Part 1 - PPL

159/171

"or e#amples of non-orthogonalit consider

C**'V Se can convert from integer to float b( simpl(

assigning a float to an integer" but not vice versa!2not a 1uestion of abilit( to do [ generalit(" but ofthe wa( it is done3

V Arra(s are pass b( reference while integers arepass b( value!

V A switch statement wor+s with integers"characters" or enumerated t(pes" but not doublesor 'trings!

Chapter #Louden

%?9

(egularit e#amples from C**

8/18/2019 Part 1 - PPL

160/171

• /unctions are not general: there are no localfunctions 2simplicit( of environment3!

• Declarations are not uniform: datadeclarations must be followed b( a semicolon"function declarations must not!

• Lots of wa(s to increment [ lac+ of uniformit(2..i" i.." i I i.%3

• iI< and iII< loo+ the same" but are different!Lac+ of uniformit(

Chapter #Louden

%?%

8/18/2019 Part 1 - PPL

161/171

+hat about ,aa.• Are function declarations non,general

V There are no functions" so a non,issue! 2Sell" whatabout static methods3

• Are class declarations non,generalV 0o multiple inheritance 2but there is a reason:

comple4it( of environment3!

V =ava has a good replacement: interface inheritance!

• Do declarations re1uire semicolonsV Local variables do" but is that an issue 20ot reall( ,

the( loo+ li+e statements!3

Chapter #Louden

%?@

8/18/2019 Part 1 - PPL

162/171

,aa regularit continued• Are some parameters references" others not

V \es: ob

8/18/2019 Part 1 - PPL

163/171

Other design principles'implicit(: ma+e things as simple as possible" but

not simpler 2$instein3! 2Pascal" C3

• Se can ma+e things so simple that it doesnBt wor+ well [ no string handling" no reasonable)Q9

• Can be cumbersome to use or inefficient!

Chapter #Louden

%?8

8/18/2019 Part 1 - PPL

164/171

Other design principles$4pressiveness: ma+e it possible to e4press

conceptual abstractions directl( and simpl(!

2'cheme3• 6elps (ou to thin+ about the problem!

• Perl" for e4ample" allows (ou to return multiplearguments:

2]a"]b3 I swap2]a"]b3H

Chapter #Louden

%?

8/18/2019 Part 1 - PPL

165/171

Other design principles• $4tensibilit(: allow the programmer to e4tend

the language in various wa(s! 2'cheme" C..3

T(pes" operators

• 'ecurit(: programs cannot do une4pecteddamage! 2=ava3

V discourages errorsV allows errors to be discovered

V t(pe chec+ing

8/18/2019 Part 1 - PPL

166/171

Chapter #Louden

%?M

Other design principles 0cont 2

8/18/2019 Part 1 - PPL

167/171

Other design principles 0cont2

• *achine,independence: should run the same onan( machine! 2=ava, big effort3

• Consistent with accepted notations [ eas( tolearn and understand for e4periencedprogrammers 2*ost languages toda(" but not'malltal+ ^ Perl3

• Restrictabilit(: a programmer can programeffectivel( in a subset of the full language! 2C..:avoids runtime penalties3

Chapter #Louden

%?N

8/18/2019 Part 1 - PPL

168/171

C** case stud• Than+s to -

8/18/2019 Part 1 - PPL

169/171

a4or C** design goals• OO features: class" inheritance

• 'trong t(pe chec+ing for better compile,time

debugging• $fficient e4ecution

• Portable

• $as( to implement

• ood interfaces with other tools

8/18/2019 Part 1 - PPL

170/171

Chapter #Louden

%M%

8/18/2019 Part 1 - PPL

171/171

C** design errors• Too big

V C.. programs can be hard to understand and

debugV 0ot eas( to implement

V Defended b( 'troustrup: multiparadigm featuresare worthwhile

• 0o standard librar( until late 2and even thenl +i < f 3

Part 1 - PPL

Documents

Transcript of Part 1 - PPL