Princeton University
Computer Science Dept.

Computer Science 441
Programming Languages
Fall 1998

Lecture 8

Adding a run-time environment to interpreter

We have earlier described substitution as a reasonable mechanism for interpreting function application (called beta-conversion), but there are a few places where you must be very careful with name clashes if we have free variables.
(See section 10.7 in the text for details.)

We normally expect that if we change the names of formal parameters that it should not make any difference, but ...

Suppose we evaluate: 

   let  fun g x y = x + y  in g y end;
(or in our language PCF:
   (fn g => g y) (fn x => fn y => x+y))
If we evaluate blindly we get:
   fn y => y + y
Notice that because of scoping, the actual parameter y has become captured by the formal parameter y!

We should get: fn w => y + w, which has a very different meaning!!

(Note that we did not run into this problem earlier since during our evaluations we never worked with terms with free variables - when going inside functions we replaced all formal parameters by the actual parameters, which didn't involve free variables).

A different order of evaluation would have brought forth the same problem, however.

We would like to have fn x => B to represent the same function as
fn y => B[x:=y] as long as y doesn't occur freely in B. (Called alpha-conversion)

If you always alpha-convert to a new bound variable before substituting in, will never have problems.

Evaluate terms via environments:

Env = string -> values

An environment, rho, tells value of identifiers in term.

Write [[e]] rho for meaning of e with respect to environment rho.

E.g. if rho(x) = 12 and rho(y) = 2, then [[x+y]] rho = 14.

How does function application result in change of environment?

[[(fn x => body) actual]]rho = [[body]] rho [ [[actual]]rho / x]

where rho[v / x] is environment like rho except x has value "v".

This and rec are the only rules in which the environment changes!

Rest of rules look like the old interpreter (except identifiers looked up in environment)!

Replaces all uses of subst!

This means that computation no longer takes place by rewriting terms into new terms, interp is now a function from term to value.

Note that

	let val x = arg in e
is equivalent to
	(fn x => e) arg
Must worry about scoping problems:
   val test = let 
                  val x = 3;
                  fun f y = x + y;
                  val x = 12
              in 
                  x + (f 7)
              end;
What is value of test?

Change in scope is reflected by change in environment.

With functions must remember environment function was defined in!

When apply function, apply in defining environment.

test is equivalent to

   (fn x => (fn f => ((fn x => x + (f 7)) 12) (fn y => x + y))) 3
Then
 
   [[(fn x => (fn f => ((fn x => x + (f 7)) 12) (fn y => x + y))) 3]] rho0
	= [[(fn f => ((fn x => x + (f 7)) 12) (fn y => x + y)) ]] rho1
	= [[(fn x => x + (f 7)) 12]] rho2
	= [[x + (f 7)]] rho3
	= 12 + ([[fn y => 3 + y]] rho1) 7
	= 12 + [[3 + y]] rho4
	= 12 + 3 + 7 
	= 22
where rho0 is the starting environment and
   rho1 = rho0 [ [[3]] rho0 / x] = rho0[ 3 / x]
   rho2 = rho1 [ [[fn y => x + y]] rho1 / f] 	<-	Closure for f
   rho3 = rho2 [ [[12]] rho2 / x] = rho2[ 12 / x]
   rho4 = rho1 [ 7 / y]

MORE TYPES

Mappings:

Encompasses functions w/ both infinite and finite domains.

Arrays:

homogeneous collection of data.

Mapping from index type to range type
E.g. Array [1..10] of Real corresponds to {1,...,10} -> Real

Operations and relations: selection ". [.]", :=, =, and occasionally slices.

E.g. A[2..6] represents an array composed of A[2] to A[6]

Index range and location where array stored can be bound at compile time, unit activation, or any time.

In both static and semi-static languages the index set of an array is bound at compile time. The difference is that with static arrays, the location of the array in memory is bound at compile time (as in FORTRAN), while with semi-static, the size of the array is bound at compile time, but its location is determined at run-time.

For instance, in Pascal, an array stored in a local variable is allocated on the run-time stack, and its location on the stack may vary in different invocations of the procedure.

With semi-dynamic (or dynamic) arrays, the index set (and hence size) of the array may vary at run-time. For instance in ALGOL 60 or Ada, an array held in a local variables may have index bounds determined by a parameter to the routine. It is called semi-dynamic because the size is fixed once the routine has been activated.

A flexible array is one whose size can change at any time during the execution of a program. Thus, while a particular size array may be allocated when a procedure is invoked, the array may be expanded in the middle of a loop if more space is needed.

The key to these differences is binding time, as usual!

Function abstractions:

S->T ... function f(s:S):T (where S could be n-tuple) Operations: abstraction and application, sometimes composition.

What is difference from an array? Efficiency, esp. w/update.

	update f arg result x = if x = arg then result else f x
or 
	update f arg result = fn x => if x = arg then result else f x
Procedure can be treated as having type S -> unit for uniformity.

Powerset: 

	set of elt_type;
Typically implemented as bitset or linked list of elts

Operations and relations: All typical set ops, :=, =, subset, .. in ..

Why need base set to be primitive type? What if base set records?

Recursive types:

Examples: 
  	tree = Empty | Mktree of int * tree * tree

	list = Nil | Cons of int * list
In most lang's built by programmer from pointer types.

Sometimes supported by language (e.g. Miranda, Haskell, ML).

Why can't we have direct recursive types in ordinary imperative languages?

OK if use ref's: 

	list = POINTER TO RECORD
			first:integer;
			rest: list
		END;

Recursive types may have many sol'ns

E.g. list = {Nil} union (int x list) has following sol'ns:

  1. finite sequences of integers followed by Nil: e.g., (2,(5,Nil))

  2. finite or infinite sequences, where if finite then end with Nil
Similarly with trees, etc.

Theoretical result: Recursive equations always have a least solution - though infinite set if real recursion.

Can get via finite approximation. I.e.,

   list0 = {Nil}

   list1 = {Nil} union (int x list0) 
         = {Nil} union {(n, Nil) | n in int}

   list2 = {Nil} union (int x list1) 
         = {Nil} union {(n, Nil) | n in  int}
                 union {(m,(n, Nil)) | m, n in int}

      ...

   list = Unionn listn
Very much like unwinding definition of recursive function 
	fact = fun n => if n = 0 then 1 else n * fact (n-1)
	
	fact0 = fun n => if n = 0 then 1 else undef
	
	fact1 = fun n => if n = 0 then 1 else n * fact0(n-1)
	      = fun n => if n = 0, 1 then 1 else undef
	      
	fact2 = fun n => if n = 0 then 1 else n * fact1(n-1)
	      = fun n => if n = 0, 1 then 1 else 
	                 if n = 2 then 2 else undef
	...


	fact = Unionn factn
Notice solution to T = A + (T->T) is inconsistent with classical mathematics!
In spite of that, however, it can be used in Computer Science, 
	datatype univ = Base of int | Func of (univ -> univ);

Sequence:

Lists

Supported in most fcnal languages

operations: hd, tail, cons, length, etc.

sequential files

File operations: Erase, reset, read, write, check for end.

Persistent data - files.

strings:

ops: <, length, substr

Are strings primitive or composite?

User-Defined Types

User gets to name new types. Why?
  1. more readable

  2. Easy to modify if localized

  3. Factorization - why copy same complex def. over and over (possibly making mistakes)

  4. Added consistency checking in many cases.

STATIC VERSUS DYNAMIC TYPING

Static: Most languages use static binding of types to variables, usually in declarations
	var x : integer  {bound at translation time}
The variable can only hold values of that type. (Pascal/Modula-2/C, etc.)

FORTRAN has implicit declaration using naming conventions

Other languages will "infer" type of undeclared variables.

In either case, run real danger of problems due to typos.

Example in ML, if 

	datatype Stack ::= Nil | Push of int;
then define
	fun f Push 7 = ...
What error occurs?

Answer: Push is taken as a parameter name, not a constructor.
Therefore f is given type: A -> int -> B rather than the expected: Stack -> B

Dynamic: Variables typically do not have a declared type. Type of value may vary during run-time. Esp. useful w/ heterogeneous lists, etc. (LISP/SCHEME).

Dynamic more flexible, but more overhead since must check type before performing operations (therefore must store tag w/ value).

Dynamic binding found in APL and LISP.

Dynamic binding harder to implement since can't allocate a fixed amount of space for variables. Therefore often implemented as pointer to memory holding value.

TYPES IN HISTORY OF PROGRAMMING LANGUAGES

FORTRAN

Built-In: Integer, Real, Double Precision, Complex, Logical

no characters or strings, no user-defined of any sort.

Arrays - at most 3-dim'l of built-in type. Subscripts begin at 1

Orig., restricted form of subscript expressions.

No records or sets. Many holes in typing.

ALGOL 60

Built-In: Integer, Real, Boolean, limited strings

Arrays of built-in types - no limit on dim'n, bounds any integers, semi-dynamic arrays

No records or sets. Strongly and statically typed.

Pascal

Pascal's Types

Built-In:

Integer, Real, Boolean, Char, no strings except as packed array of char.

Enumeration types.

Subranges

Guard against errors, save space. (only for discrete types)

Arrays

Hierarchical, but only one-dim'l.
	Array [1..10, 'a'..'z'] of Real = Array [1..10] of Array ['a'..'z'] of Real
User fooled into thinking Array[A,B] of C is AxB->C, but really A->B->C.

Any discrete type as index.

No semi-dynamic arrays. Result of 2 principles:

  1. All types must be determinable at compile time.

  2. Array bounds are part of type.

Therefore, must have statically determinable array bounds.

Type of actual parameters must agree w/ type of formals

Therefore, no general sort routines, etc.

The major problem with Pascal

Variant records

as above - introduce holes in type system.

Pointers

must point to objects of specific type (unlike PL/I)

Sets

supported - but often limited implementation.

Sequential files

of any (non-file) type.

Problems with Types in Pascal

1. Holes in typing system with variant records, procedure parameters, and files.
		Procedure x(...; procedure y;...)

			:

			y(a,2);
Fixed in (new) ANSI standard.

No checking if type of file read in matches what was originally written.

2. Problems w/ type compatibility

Assignment compatibility:

When is x := y legal? x : integer, y : 1..10? reverse?

What if type hex = 0..15; ounces = 0..15;

var x : hex; y : ounces;

Is x := y legal?

Original report said both sides must have identical types.

When are types identical?

Ex.:

    Type    T = Array [1..10] of Integer;
    Var  A, B : Array [1..10] of Integer;
             C : Array [1..10] of Integer;
             D : T;
             E : T;
Which variables have the same type?

CS441 | CS Department | Princeton University