Programming Languages: Design, Specification, and Implementation

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

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 1st 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