CSC 434 Programming Languages Fall 2001

1. CSC 434 Programming LanguagesFall 2001

2. Why Study P.L.’s? • Broader point of view • Employability • Pick appropriate P.L. for the job • Design a new P.L. • Use in implementing a P.L.

3. Programming Paradigms • Imperative • Functional • Logic • Object oriented • Distributed / parallel

4. Criteria for Evaluating Programming Languages • Expressive power • Simplicity and orthogonality • Implementation • Error detection and correction • Program correctness and standards

5. Expressive Power • Writability control structures data structures operators modularity • Readability syntax ! maintenance

6. Simplicity and Orthogonality • Levels of precedence (15 in C) • Not too many constructions, with all combinations valid and no special cases K++ ++K K += 1 K = K + 1

7. Implementation IssuesCost and Efficiency • Compiling 2 stages faster execution • Interpreting 1 stage slower execution

8. The Stages of Compiling Source program Lexical phase Tokens Syntax phase Parse tree Semantic phase Object program

9. Error Detection and Correction • Type checking • Pointer problems • Array subscripts out of range • Run-time exceptions …

10. Correctness and Standards • BASIC versus Ada for standards • Program structure • Formal proofs (predicate calculus) invariants pre-conditions and post-conditions

11. Evolution of P.L.’s (1 of 2) • Fortran – surprising success of 1st HLL • Algol 60 – reasons it did not succeed, but enormous influence, BNF • COBOL – data processing, influence of DOD • PL/1 – synthesis of Fortran and COBOL • Basic – original simplicity, time-sharing, lack of a standard

12. Evolution of P.L.’s (2 of 2) • Pascal – for teaching CS concepts, influence of strong typing • C – for systems programming, weak typing • Ada – influence of DOD, rigorous standard • Modula-2 – simpler alternative to Ada • Others – Lisp, Prolog, C++, Java, … See Appendix 1, pp. 329-345

13. Syntax and Semantics of P.L.’sBackus Normal Form (BNF) • Syntax versus semantics • BNF is a meta-language, first used for Algol 60 • A grammar G defines a language L(G) • The grammar G can be used: to generate a valid sentence in L(G) to recognize if a given sentence is valid according to the rules of G

14. Elements of BNF Syntax • Consists of rules, or productions • ::= means ‘is defined to be’ • | means ‘or’ • Identifiers within ‘< >’ are syntactic categories, or non-terminal symbols • Other symbols are terminal symbols that represent themselves literally

15. Example of a BNF Grammar <exp> ::= <exp> + <term> | <exp> - <term> | <term> <term> ::= <term> * <factor> | <term> / <factor> | <factor> <factor> ::= ( <exp> ) | <identifier>

16. Other Features of Syntax • Ambiguous grammars – the dangling else • EBNF uses [ ] for optional items and { } for zero or more repetitions <integer> ::= [+|-] <unsigned integer> <identifier> ::= <letter> { <letter> | <digit> } • Syntax diagrams a graphical form of EBNF

17. Semantics of P.L.’s – Harder! • Operational Semantics – uses a virtual machine • Denotational Semantics – manipulates mathematical objects • Axiomatic Semantics – uses predicate calculus to prove properties of program statements

18. Miscellaneous P.L. Syntax • Special words in a P.L. keywords – meaning varies with context reserved words – meaning is fixed • Use of blanks (Fortran example) • Comments /* … */ // … • Case sensitivity – why it might be avoided

19. Block Structure • Nested functions / procedures • Scope of variables (inside out) local variables non-local variables global variables • Storage categories (lifetime) static storage automatic storage dynamic storage

20. Bindings • Binding name to its declaration – scope • Binding declaration to its reference – lifetime • Binding reference to its value – assignment • When do bindings occur? compile time? load time? run time? • own variables in Algol 60, static in C • Finding value, given address is dereferencing

21. Static Scope and Dynamic Scope • In static scope a procedure is called in the environment of its definition – can be determined at compile time. • In dynamic scope a procedure is called in the environment of its caller – must be determined at run time. • Hazards of dynamic scope.

22. Static Scope and Dynamic Scope PROGRAM Dynamic (input, output); VAR x: integer; PROCEDURE a; BEGIN … write (x); … END; PROCEDURE b; VAR x: real; BEGIN … x := 2.0; … a; … END; BEGIN … x := 1; … b; … a; … END.

23. Binding the Type • Strong typing (static) is good – catch errors at compile time – Pascal, Ada • Implicit typing – e.g., first letter of variable name in Fortran, $ suffix in Basic, … • Type inferencing – type determined at run time, can change during execution – APL

24. Simple Data Types • Primitive Data Types (portability ??) boolean (not in C) integers reals complex (in Fortran) • Enumerated Types day = (Sun, Mon, Tues, Wed, Thurs, Fri, Sat); • Subrange Types work = Mon .. Fri;

25. Pointer Variables TYPE integerpt = ^integer; VAR p: integer; pipoint, another: integerpt; new (pipoint); pipoint^ := 17; another := pipoint; Another is now an alias for pipoint. If we deallocate using pipoint, the memory block is gone, but another still refers to it – a dangling reference – a severe source of runtime errors.

26. Data Structures • Arrays • Records • Sets • Strings • Dynamic – using pointers lists stacks queues trees graphs

27. Arrays • Index type and base type • Array storage allocation – the dope vector • Array sizes – static, semi-dynamic, dynamic • Cross-sections or slices • Equivalence structural equivalence name equivalence

28. Name/Structural Equivalence TYPE first = ARRAY [1..10] OF integer; second = ARRAY [1..10] OF integer; VAR a: first; b: second; c: ARRAY [1..10] OF integer; d,e: ARRAY [1..10] OF integer; f: first;

29. Records • Arrays use indexing – A[j,k] – homogeneous elements Records use qualification – R.field – heterogeneous fields • Arrays with records as elements Records with arrays as fields • Variant records – conserve memory a fixed part a tag field, or discriminant a variant part but variant part may not correspond to tag!

30. Records – An Example TYPE spouse = RECORD name: ARRAY [1..10] OF CHAR; age: INTEGER; END; employee = RECORD name: ARRAY [1..20] OF CHAR; bday: ARRAY [1..3] OF INTEGER; wage: real; status: char; spice = ARRAY [1..n] OF spouse; END;

31. Records – Another Example TYPE shape = (circle, triangle, rectangle); colors = (red, green, blue); figure = RECORD filled: boolean; color: colors; CASE form: shape OF circle: (diameter: real); triangle: (leftside: integer; riteside: integer; angle: real); rectangle: (side1: integer; side2: integer); END; VAR myfigure: figure;

32. Sets & Strings • Set representations the characteristic vector union / intersection via OR / AND • String representations terminal characters fixed-length strings varying-length strings count-delimited strings indexed list of strings linked list strings

33. Evaluating Expressions • Overloading of operators • Short circuit evaluation • Type conversions mixed mode arithmetic assignment coercion of parameters casts

34. Control Structures • Sequential Processing do A, then B, then C, … • Conditional Processing (branching or selection) if A is true, then do B, else do C • Iterative Processing (looping or repetition) while A is true, do B {and test A again} • Exceptions

35. Issues with Iteration • Is lcv a floating point variable? • Is lcv declared explicitly or implicitly? • What is value of lcv when loop terminates? • When is termination test done? • Can lcv be changed inside the loop? • Can the loop be exited from the middle?

36. Structuring Programs • Procedures, functions, subroutines, … • Formal versus actual parameters • Named parameters • Default parameters • Overloading of function names – signatures • Independent versus separate compilation

37. Parameter Passing • Principal methods call by value call by value-result call by reference call by name • Complications with aliasing

38. Parameter Passing VAR element: integer; a: ARRAY [1..2] OF integer; PROCEDURE whichmode (x: ? MODE integer) BEGIN a[1] := 6; element := 2; x := x + 3; END; BEGIN a[1] := 1; a[2] := 2; element := 1; whichmode (a[element]); …

39. Elements of OOP • Encapsulation – information hiding, as with ADT’s – modules, packages, classes, … • Inheritance • Polymorphism – as with overloading • Dynamic binding – method call can invoke different actual methods, determined at run time

40. Java Abstract Classes • An abstract method is one that has a header but no body, so cannot be implemented. • An abstract class is one in which one or more of the methods are abstract.

41. Java Interfaces • Multiple inheritance would be desirable, as provided in C++, but has significant problems. • Instead Java provides interfaces. An interface contains just constants and abstract methods. Since they are all abstract, they are not labeled as such. • A class can then inherit from a parent class, and also implement several interfaces. To do so, the class must provide bodies for each of the abstract methods in the interfaces.

42. Java Exceptions • Throwable objects include: • errors, from which there is no recovery • unchecked exceptions, such as for arithmetical errors, which need not be (but can be!) caught and dealt with • checked exceptions, which must be caught, even if no action is provided • Code that may cause one or more exceptions is placed in a try block. • Code for dealing with exceptions is placed in catch blocks.

43. Parallel Architectures • Single Instruction, Multiple Data (SIMD) • Multiple Instruction, Multiple Data (MIMD) via shared memory • Multiple Instruction, Multiple Data (MIMD) via message passing • Each of these must deal with the issue of coordinating the parallel activities.

44. Problems of Parallelism • Non-determinism • Deadlock • Starvation • Fairness • Termination • Load Balancing

45. Solving the Preceding Problems • Semaphores are low-level, using flags set by the user – easy to use improperly. • Monitors are procedures that take on all of the responsibility of assigning critical resources to other processes, in response to their requests. • Rendezvous is the use of message passing to coordinate the allocation of resources and tasks to be performed. • Both monitors and rendezvous were invented by Tony Hoare!

46. Java Threads (1 of 3) • Java provides concurrency, which may or not be true parallelism on multiple CPU’s, via threads. • Threads can be in several states: created, running, suspended, stopped, … • Once a thread is created, one must explicitly start it; it will then perform the functionality of its run method. • Threads can be created either by extending the thread class, or by implementing the runnable interface.

47. Java Threads (2 of 3) • Java restricts access by competing threads to critical regions of code via the synchronized reserved word. • When a method of a Java object is synchronized, the object becomes a monitor. • When an object is a monitor in Java, then when a thread T is using one of the monitor’s synchronized methods, no other thread can use any of the monitor’s synchronized methods until T relinquishes the monitor.

48. Java Threads (3 of 3) • Synchronization is still not adequate to coordinate the activities of threads. It just prevents threads from stepping on each other. • To provide coordination, one must use wait( ) and notify( ), as with the Producer-Consumer problem.

49. Dijkstra’s Guarded IF if expr1 -> stmt1 [ ] expr2 -> stmt2 [ ] … [ ] exprn -> stmtn fi

50. Dijkstra’s Guarded DO do expr1 -> stmt1 [ ] expr2 -> stmt2 [ ] … [ ] exprn -> stmtn od