1. Programming Languages: Design, Specification, and Implementation G22.2210-001 Rob Strom October 12, 2006

2. Administrative Alternative mailing address for me: robstrom@us.ibm.com robstrom@us.ibm.com Everyone should subscribe to the class mailing list: http://www.cs.nyu.edu/mailman/listinfo/g22_2110_001_fa06 Reading: Ada http://www.adahome.com/rm95/ sections 1, 3, 4 http://www.adahome.com/rm95/ C++ (Dewhurst&Stark), chapters 1, 2 Java ( http://java.sun.com/docs/books/jls/) 2, 4.1-4.2, 10 (grammars, introduction to types, primitive types, arrays) http://java.sun.com/docs/books/jls/ Basic homework: In Ada, C++, and Java, how do I do my earlier FORTRAN example, where I read a value N and then create an array of exactly size N? Alternative C++ book: Lippman & Lajoie “C++ Primer” (Addison Wesley); ch 2, 3.1-3.10, 13.7

3. Programming Languages Core Exam  Syntactic issues: regular expressions, context-free grammars (CFG), BNF.  Imperative languages: program organization, control structures.  Types in imperative languages: strong typing, type equivalence, unions and discriminated types in C and Ada.  Block structure, visibility and scoping issues, parameter passing.  Systems programming and weak typing: exposing machine characteristics, type coercion, pointers & arrays in C.  Run-time organization of block-structured languages: static scoping, activation records, dynamic and static chains, displays.  Programming in the large: abstract data types, modules, packages and namespaces in Ada, Java, and C++.  Functional programming: list structures, higher order functions, lambda expressions, garbage collection, metainterpreters in Lisp and Scheme. Type inference and ML.  Object-Oriented programming: classes, inheritance, polymorphism, dynamic dispatching. Constructors, destructors and multiple inheritance in C++, interfaces in Java.  Generic programming: parametrized units and classes in C++, Ada and Java.  Concurrent programming: threads and tasks, communication, race conditions and deadlocks, protected methods and types in Ada and Java.

4. Types Languages differ on What has types – run-time or compile-time entities Often both, and a checking scheme is sound if and only if what passes the check at compile-time will never produce a type error at runtime. What counts as type equivalence Name equivalence Structural equivalence What counts as compatibility How types are inferred How much users can define their own types What a type denotes: a value space? A set of operations?

5. Classes of types – Basic Pure data: Nominals Booleans Enumerations (many languages) Numbers Records/Structs Unions/Variants Strings, Lists, and Arrays Sets, Maps, Tables Constraints Numeric ranges Array/String bounds Constrained variants

6. Language Differences Records Fortran-like exposure of byte order and holes Structural vs. name equivalence Ada: subtypes are considered compatible; derived types not. Variants/Unions No discriminant Ability to change discriminant at will Case conformity clauses Union (t1, t2, t3) u Case u in (t1 a) : … (t2 b) :... (t3 c) : … Ada always initialized discriminant Hermes/NIL typestate Arrays Bounds checking Type of contents, type of index

7. Variants (Hermes) type s-expr: case(pair) car: s-expr (init), cdr: s-expr (init), case(atom) val: String (init) case(nil) uninit nil atompair pair init(car),init(cdr) pair init(cdr)pair init(car) atom init(val) init Inspect pairInspect atomInspect nil Create pairCreate atom Create nil Unite Select Assign val At each point in the program, each variable must be in exactly one of these “typestates” regardless of the path taken to that point.

8. Variants (Ada) type v1 (variety: Boolean := true) is record a: string (1..2); -- this field is always there b: integer; -- this field is always there case variety is when true => c: integer; -- this field is only there when variety = true d: string; -- this field is only there when variety = true when false => e: real; -- this field is only there when variety = false end case; end record; Can declare: (1) constrained instances, where variety is immutable, or (2) unconstrained instances, where only whole record assignment is possible All references to variant fields of unconstrained instances, e.g. “e”, contain implicit checks of the discriminant, although some compilers may optimize them away as appropriate.

9. Classes of Types, continued Functions/procedures, including closures Type signature includes parameter/result types Pointers/References Type defines type of target In C++, a reference is a bound-once alias In C/C++, a pointer p supports p+i, meaning go to the i-th instance of the object of the type p points to. Object Abstractions (OOLs) Type determines sets of operations (methods) Tasks (Ada) Special (files, etc.)

10. Compatibility and Conversion type test_score = 0..100; type celsius_temp is new integer; n: integer; r: real; t: test_score; c: celsius_temp; … t := test_score(n) ; -- bounds check n := integer(t); -- no check needed r := real(n); -- conversion n := integer(r); -- both a conversion and a check n := integer(c); -- no conversion or check (abstractly) c:= celsius_temp(n); -- no conversion or check (abstractly)

11. Escaping Strong Typing Generic (reference) type: Void* (C/C++), address (Modula-2), refany (Modula-3), Object (Java), Polymorph (Hermes) Can be safe or unsafe Safe ones require that the generic form carry type information at runtime, and that the conversion back to the original type raise an exception

12. Implementation Issues Stacks Hold local variables, parameters, temporaries, state of caller Hold “static backchain” to enclosing nested environments Displays Replace static backchain with fixed array Closures implemented via the stack become invalid when creating environment terminates: therefore PL/I, Algol, Ada, etc. do not have 1 st class closures. “Dope vectors” permit properties of arrays (and more generally, records, objects) to be passed from environments where these properties are known statically to those where they are not known statically

13. Issues with Pointers Stacks are deallocated on exit Heaps are not. In some languages (Pascal, C++), you can explicitly free objects. This can lead to dangling references. If you can make pointers to the stack, you can still get dangling references unless you have a rule, such as: Algol 68: Pointers may not point to an object whose lifetime is shorter than that of the pointer. Ada 95: Pointers may not point to an object whose lifetime is shorter than that the of the pointer’s type. Otherwise, to be safe, you must retain objects until they’re guaranteed unusable. If you can copy pointers, then any heap object or any stack object to which a pointer was ever made could be aliased.

14. Avoiding dangling references Tombstones: Extra level of indirection Nulled out when object deallocated Advantage: object can be dynamically moved Disadvantages: speed, can’t collect tombstone Key/lock Each pointer has address + key Each pointed to object has matching lock

15. Automatic Reclamation techniques Reference counting Problem: circular garbage Mark and sweep garbage collection Initially, every allocated block is “suspected garbage” Each reachable block is labelled “non-garbage” Finally, every suspected garbage block is collected Variations: stop-and-copy, generational Both require that we know: where all the pointers are and when they’re initialized the extents of allocated memory Hybrid techniques Rely on the fact that References to some blocks are isolated within some region, and Some regions are not aliased