1. CS 152: Programming Language Paradigms May 12 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak www.cs.sjsu.edu/~mak

2. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 2 All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use a hammer. – IBM Manual, 1925

3. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 3 A Partial Solution to Assignment #6  The only implemented built-in procedures are + and *.  The only implemented special forms are define, lambda, let, and let*. No if and cond.  It shouldn’t take too much effort to add the remaining built-in procedures and special forms to complete Assignment #6 and the extra credit. (define x 2) (define y 3) (+ x y) (define add (lambda (a b) (+ a b))) (add x 10) (define func (lambda (a) (let* ((b 2) (prod (* a b))) prod))) (define proc (lambda (a b) (let ((sum (+ a (func b)))) sum))) (proc x y)

4. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 4 (define proc (lambda (a b) (let ((sum (+ a (func b)))) sum))) (define func (lambda (a) (let* ((b 2) (prod (* a b))) prod))) Parse Trees and Symbol Tables lambda a func definelet* prod 2 b b a * lambda b a proc define sum b func a + let sum a b Level 2 sum Level 3 b prod Level 3 a Level 2 (define x 2) (define y 3) (proc x y) Top-Level Symbol Table xy proc func The parse trees and the symbol tables are interlinked.

5. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 5 The Symbol Table Stack  Whichever symbol table is on top of the stack is the local symbol table.  The first symbol table created (the one at the bottom of the stack) is the global symbol table. It stores the predefined information, such as entries for the names of the standard Scheme procedures car, cdr, cons, +, -, etc.  During the translation process, symbol tables are pushed onto and popped off the stack … … as the parser enters and exits scopes. Global symbol table

6. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 6 (define proc (lambda (a b) (let ((sum (+ a b))) sum) )) Nested Scopes and the Symbol Table Stack “car”“cdr”“+” Level 0 symbol table Symbol table stack “proc” Level 1 symbol table “a” Level 2 symbol table “b”“sum” Level 3 symbol table

7. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 7 Runtime Activation Records RUNTIME STACK AR: main x AR: lambda a 2 2 (define proc (lambda (a b) (let ((sum (+ a (func b)))) sum) )) (define func (lambda (a) (let* ((b 2) (prod (* a b))) prod) )) (define x 2) (define y 3) (proc x y) y 3 b 3 AR: let sum 8 AR: lambda a 3 AR: let* b 2 prod 6  Create the activation records at run time from the contents of the symbol tables. 6 6 8 8 8

8. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 8 The Runtime Display  The runtime display makes accesses to nonlocal values more efficient.  The activation record back links help to restore the runtime display. RUNTIME STACK (define proc (lambda (a b) (let ((sum (+ a (func b)))) sum) )) (define func (lambda (a) (let* ((b 2) (prod (* a b))) prod) )) (define x 2) (define y 3) (proc x y) RUNTIME DISPLAY 1 2 3 AR: main xy 1 AR: lambda ab 2 AR: let sum 3 AR: lambda a 2 AR: let* bprod 3

9. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 9 The frontend and intermediate Packages  Package frontend : Parser Scanner Source Token TokenType  Package intermediate : Node NodeType ParserResults SymbolTable SymtabEntry SymtabEntryType SymtabStack TreeWalker

10. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 10 (define proc (lambda (a b) (let ((sum (+ a (func b)))) sum))) (define func (lambda (a) (let* ((b 2) (prod (* a b))) prod))) Building Symbol Tables lambda a func definelet* prod 2 b b a * lambda b a proc define sum b func a + let sum a b Level 2 sum Level 3 b prod Level 3 a Level 2 Top-Level Symbol Table xy proc func

11. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 11 Building Symbol Tables: First Way  Build the symbol tables while you’re building the parse trees. (define proc (lambda (a b) (let ((sum (+ a (func b)))) sum))) lambda b a proc define a b Level 2 Top-Level Symbol Table proc

12. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 12 Building Symbol Tables: Second Way  First build a parse tree completely for a top-level list.  Walk the parse tree to build the symbol tables. Create the links between the symbol tables and the tree nodes.  The partial solution does it this way. Class TreeWalker in package intermediate does all the work of walking a parse tree and building the symbol tables. This way may be easier to implement.

13. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 13 Walking the Parse Trees  The TreeWalker code does a lot of looking ahead from a given node: cdar, cddar, cddaar, etc. Example (processing the body of a lambda expression): Node body = lambdaRoot.cdr().cdr(); if (body != null) { Node cddar = body.car(); if (cddar != null) { if (cddar.getType() == NodeType.LIST) { Node cddaar = cddar.car(); if (cddaar != null) { Token token = cddaar.getToken(); if ( (token != null) && ( (token.getType() == TokenType.KW_LET) || (token.getType() == TokenType.KW_LET_STAR))) { processLet(cddar, level+1); letFlag = true; } } } } }

14. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 14 Front-End Parser  Back-End Executor  The parse trees and the symbol tables built by the parser from classes in package intermediate are the interface between the front-end parser and the back-end executor.

15. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 15 Front-End Parser  Back-End Executor, cont’d  The parser builds a parse tree for each top-level list.  It builds symbol tables for the lambda and let scopes. The tables are linked to tree nodes.  The parser also builds the global and top-level symbol tables. _

16. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 16 Front-End Parser  Back-End Executor, cont’d  The parser creates a ParserResults object in the intermediate package to wrap up: the parse trees the symbol tables  The parser then hands the ParserResults object over to the back-end Executor. _

17. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 17 The backend Package  Package backend : ActivationRecord BuiltIn Executor RuntimeStack TreePrinter  Class Executor in the backend package also walks the trees. _

18. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 18 Back-End Executor  The execute() method in class Executor calls various helper methods: eval() evalElement() evalList() executeDefine() executeCall() executeLambda() executeLet() print()

19. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 19 Activation Records  An ActivationRecord object is created each time a new scope is entered during run time.  The “slots” to hold the computed values of the local variables are initially created from the scope’s symbol table that was built by the front end.  The activation record has a slot for each variable whose name is in the symbol table. _

20. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 20 Activation Records, cont’d  When a procedure is called: Create an activation record for the formal parameters of the lambda expression. Push the activation record onto the runtime stack.  When a let or let* is entered: Create an activation record for the let variables. Push the activation record onto the runtime stack.  Pop off the activation record when exiting the scope, such as by returning from a procedure. _

21. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 21 Returning Values  Each the of methods eval*() and execute*() of class Executor returns the value that it computed.  A value returned by a top-level list is printed. _

22. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 22 Postmortem Reports  Due Friday, May 16 at 11:59 PM A few paragraphs. Word document or just an email message Individual and private.  What did you learn in this class?  What were your accomplishments on your project team?  How well did each of your teammates do? _

23. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 23 Final Exam  Tuesday, May 20 12:15 – 2:30 PM in DH 318  It will be similar to the midterm. Covers the entire semester. More emphasis on the second half. _

24. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 24 Review for the Final  Allocation of data objects Java C++  Binding of methods Java C++ _

25. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 25 Review for the Final, cont’d  Language syntax Syntax diagrams  Grammars and languages BNF and EBNF Derivations and productions Compiler-compilers _

26. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 26 Review for the Final, cont’d  Compiler design Parsing and scanning Tokens Front end, intermediate, and back end Interpreters  Intermediate Symbol tables Parse trees Parsing Scheme lists into parse trees and symbol tables

27. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 27 Review for the Final, cont’d  Error handling Exceptions Exception propagation Resumption vs. termination  Parameter passing By value By reference By name _

28. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 28 Review for the Final, cont’d  Symbol table stack Scope  static vs. dynamic Searching  Runtime stack Activation records Display Searching _

29. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 29 Review for the Final, cont’d  Runtime memory management Heap Garbage collection  Name resolution Overloading C++ operator overloading _

30. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 30 Review for the Final, cont’d  Data types Strongly and weakly typed languages Type constructors Reference and pointer types Type compatibility Polymorphism Generic Covariant arrays  Abstract data types (ADT) Language support for ADTs

31. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 31 Review for the Final, cont’d  Multithreading  Threads activating terminating interrupting  Runnable interface  run() method

32. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 32 Review for the Final, cont’d  Thread synchronization Race condition Critical region Locks and conditions Degrees of granularity of parallelism _

33. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 33 Review for the Final, cont’d  Language support for multithreading Java object locks and synchronized methods Java monitors and Ada protected objects Go message passing _

34. SJSU Dept. of Computer Science Spring 2014: May 12 CS 152: Programming Language Paradigms © R. Mak 34 Review for the Final, cont’d  Major themes of the second half: Data handling Compilers and interpreters Scheme interpreter Multithreaded programming _