[PLT logo] Outline Lecture 3, Comp 311

The Scope of Variables and
How to Process Abstract Syntax Trees

Almost every programming language has constructs for

  • (i) introducing a new variable x, and
  • (ii) for describing which uses of the variable name x in the rest of the program refer to this variable.
  • If the same name x is used for several different variables, a programmer can resolve which variable is really meant by a particular use of the variable named x.

    For example, in Java or C++, a loop header may introduce a new loop variable and its scope:

    for(int i = 0; i < NumOfElements; i++) ... ;
    

    The scope of the variable i is the program text following the = sign to the end of the loop body. If the loop contains a breakstatement and the statement following the loop is

    System.out.println("the index where we stopped searching is " + i);
    
    then scope rules of the language tell us that the print statement is almost certainly erroneous because the use of i in the invocation of println does not refer to the variable i that was introduced as the loop variable.

    Other examples of scoping constructs in Java and C++ include

    Free and Bound, Scope: A Simple Example

    Let's call the toy language from last lecture LC (for Lambda Calculus) Using LC, we can show how to define the notion of free and bound occurrences of program variables rigorously.

    Recall the concrete syntax of LC:

    Exp = Var | Num | (lambda Var Exp) | (Exp Exp)
    Var = Sym \ {'lambda}
    

    If we interpret LC as a sub-language of Scheme, it contains only one binding construct: lambda-expressions. In

    (lambda a-variable an-expression)
    

    a-variable is introduced as a new, unique variable whose scope is the body an-expression. of the lambda-expression (with the exception of possible "holes", which we will describe in a moment).

    A tool for determining the scope of variable binding constructs is to define when a variable occurs free in a given expression. By specifying where a variable occurs free and how this relation is affected by the various constructs, we also define the scope of variable definitions. Here is the definition for LC.

    Definition (Free occurrence of a variable in LC):

    Let a-var, b-var range over the elements of Var.
    Let a-num range over the elements of Num.
    Let a-exp, b-exp range over the elements of Exp.

    Then a-var occurs free in:

    The relation a-var occurs free in a-exp is the least relation satisfying the preceding constraints.

    If a-var occurs free in a-exp, then some specific occurrence of a-var in a-exp can be identified as a "free occurrence". In fact, we could adapt the preceding definition to define the related notion "occurrence k of a-var is free in a-exp", but the details are tedious because we must label each occurrence of a-var with a unique index k, or alternatively, we must uniquely identify each occurrence by a path from the root in the abstract syntax tree for a-exp.

    An occurrence of variable a-var is bound in a-exp iff it is not free in a-exp. The most blatant form of bound occurrence is the second component of a lambda-expression. This form of variable occurrence is called the binding occurrence for the variable. Each logically distinct variable obviously has one binding occurrence; if a-var occurs twice as the second component of a lambda-expression, it is the name of two distinct variables.

    Note that the definition of the "occurs free" and "free occurence" relations are inductive over expressions precisely because the definition of Exp is itself inductive.

    The definitions of free and bound implicitly determine the notion of a scope in LC expressions. Clearly, a lambda expression opens a new scope; or, to put it differently, the scope of the binding occurrence a-var in

    (lambda a-var a-Exp)
    
    is that textual region of a-Exp where a-var might occur free.


    Static Distance Representation

    Given a variable occurrence, a programmer reading the code needs to know where the corresponding binding occurrence is. Consider the expression

    (lambda z (lambda x ((lambda x (z (z (z x)))) x)))
    

    The two occurrences of x in the fragment

                                        ... x)))) x) 
    

    are unrelated, but only the binding occurrences for the two can tell them apart.

    For a human being, a representation that includes arrows from bound occurrences to binding occurrences is clearly preferable. We can approximate such graphical representations of programs by replacing variable occurrences with numbers that indicate how far away in the surrounding context the binding construct is. The above expression would translate into

    (lambda z (lambda x ((lambda x (3 (3 (3 1)))) 1)))
    

    Indeed, since the parameters in lambda's are now superfluous, we can omit them completely:

    (lambda (lambda ((lambda (3 (3 (3 1)))) 1)))
    

    This representation is often called either the static distance representation of the term or the "deBruijn (de BROIN) notation" for the term. deBruijn is a Dutch mathematician who recognized the theoretical advantages of the notation in the context of idealized programming language called the lambda-calculus, which was invented by Alonzo Church in the 1930's. LC is a slight extension of the lambda-calculus. Although the static distance representation is not particularly helpful for people, it is valuable for compilers and interpreters.

    We could specify the process that replaces variable occurrences with static distances in English along the lines of the above definitions. Instead, we write a program that performs the translation.

    First, recall the abstract representation of the set of LC expressions is given by the equation:

    Exp = (make-var Var)
       | (make-const Num)
       | (make-proc Var Exp) 
       | (make-app Exp Exp)
    
    based on the data definitions
    (define-struct var (symbol))
    (define-struct const (number))
    (define-struct proc (var body))
    (define-struct app (rator rand))
    

    Second, the program template for abstract representations is clearly

    ;; Exp -> ?
    (define f
      (lambda (a-exp ...)
        (cond
          ((var? a-exp) ...)
          ((const? a-exp) ...)
          ((proc? a-exp) ... (f (proc-body a-exp) ...)
                          ... (proc-var a-exp) ...)
          ((app? a-exp) ... (f (app-rator a-exp) ...) ... 
                         ... (f (app-rand a-exp) ...) ...))))
    

    Since the replacement process substitutes a variable by a number that depends on the context of the variable, that is, the syntactic constructions surrounding the variable occurrence, we also need an accumulator. In our case, it suffices to accumulate the variables in binding constructs as we traverse the expression. This means the template can be refined to:

    ;; Exp -> ?
    (define f
      (lambda (a-exp binding-vars)
        (cond
          ((var? a-exp) ...)
          ((const? a-exp) ...)
          ((proc? a-exp) 
           ... (f (proc-body a-exp)
                     (cons (proc-var a-exp) binding-vars)) ...)
          ((app? a-exp) ... (f (app-rator a-exp) binding-vars) ... 
                         ... (f (app-rand a-exp) binding-vars) ...))))
    

    Finally, to distinguish the initial abstract representation of "deBruijn" programs from the new one, we introducce two new data definitions:

    (define-struct sdvar (sdc))
    (define-struct sdproc (body))
    

    and define the set of SD programs by the equation:

    SD = (make-sdvar sdc)
       | (make-num Num)
       | (make-sdproc SD) 
       | (make-app Exp Exp)
    
    We do not introduce new records for constants or applications, because their structure is unchanged.

    We can now complete the translation:

    ;; Exp -> SD
    (define sd
      (lambda (a-exp binding-vars)
        (cond
          ((var? a-exp) (make-sdvar (sdlookup (var-name a-exp) binding-vars)))
          ((const? a-exp) a-exp)
          ((proc? a-exp) 
           (make-sdproc 
    	(sd (proc-body a-exp) (cons (proc-var a-exp) binding-vars))))
          (else
           (make-app (sd (app-rator a-exp) binding-vars) 
    		 (sd (app-rand a-exp) binding-vars))))))
    
    where
    ;; Symbol (list-of Symbol) -> number
    (define sdlookup
      (lambda (a-var vars)
        (cond
          ((null? vars) (error 'sdlookup "free occurrence of ~s" a-var))
          (else (if (eq? (car vars) a-var)
    		1
    		(add1 (sdlookup a-var (cdr vars))))))))
    

    Variables are replaced by their static distance coordinate, which is determined by looking up how deep in the list of binding vars it occurs. If the list does not contain the variable, we signal an error. Constants do not need to be translated. Applications are traversed and re-constructed.

    We can test sd by applying it to the result of parsing some surface syntax and the empty list.


    Exercise: What should the output of this be?
    (sd (parse '(lambda z (lambda x ((lambda x (z (z (z x)))) x)))) null)
    

    (The empty list of variables indicates that we consider this to be the complete program with no further context.)

    cork@cs.rice.edu/ (adapted from shriram@cs.rice.edu)