1 / 68

CSC 434 Programming Languages Fall 2001

CSC 434 Programming Languages Fall 2001. 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. Programming Paradigms. Imperative Functional Logic Object oriented Distributed / parallel.

rance
Download Presentation

CSC 434 Programming Languages Fall 2001

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related