Programming Languages:Design, Specification, and

Implementation

G22.2210-001Rob Strom

October 12, 2006

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

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.

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?

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

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) uCase u in

(t1 a) : …(t2 b) : ...(t3 c) : …

• Ada always initialized discriminant• Hermes/NIL typestate

Arrays• Bounds checking• Type of contents, type of index

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 pair Inspect atom Inspect nil

Create pair Create atom

Create nil

Unite Unite 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.

Variants (Ada)type v1 (variety: Boolean := true) is record

a: string (1..2); -- this field is always thereb: integer; -- this field is always there

case variety iswhen true =>

c: integer; -- this field is only there when variety = trued: 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.

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.)

Compatibility and Conversiontype 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)

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

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

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.

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

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