Outline of Class 14: More Variables

Held: Wednesday, February 18, 1998

Administrivia

• Reminder: there is an exam next Wednesday.
  • It will be open book, open notes, open web.
  • I won't be there, as I'll be at a national conference on computer science education.
  • You get Friday the 27th off to recover.
  • I'll try to have a review sheet ready later this week.
• Women's hockey won the gold! I have a personal interest because I taught Gretchen Ulion, who scored the first goal. I hope to hear similarly good things from you folks in the future.
• A few of you asked me why we considered the various examples in such detail last class. It's because I consider design to be one of the key focuses of this class. Good design requires
  • Considering (and generating) alternative designs.
  • Selecting an appropriate design.
  • Evaluating the implications of that design in a more global context.
• Note that this "generate, consider, select, evaluate" process appears in many instances. It's also how we made grammars unambiguous.
• If you haven't done so already, read chapter 7 of Louden for Friday.
• Any questions on assignment 3?

Variables, Revisited

• L-values and r-values become increasingly important as we consider other language design components and their relations to variables.
• For example, in if test then x else y, should we use the l-value or r-value of the variable that is returned? Does it depend on context?
  • In most languages, this always gives you the r-value.
  • In Algol, it would depend on context. It would be perfectly legal to put such a conditional on the left-hand-side of an assignment.
• How far can we go with this idea? Can the return value of a function depend on its position? (Most likely not, since we type return values.)

Lifetime and Allocation

• Of particular interest with many variables is when the variable is allocated (and, eventually, deallocated).
• There are three basic strategies: static, automatic local, and dynamic.
• In static allocation, space for variables is allocated once, in static memory. This allocation is done automatically.
  • The original version of Fortran used static allocation.
  • Static allocation makes recursion particularly difficult.
• In automatic local allocation, memory is allocated on the stack, particularly for local variables in blocks (functions). This allocation is done automatically.
  • Most modern languages use automatic local allocation for local variables in a function.
• In dynamic allocation, the programmer explicitly allocates new containers and associates them with variables. Often, this allocation is done in the heap.
  • Many languages permit allocation with operations like new, free, and malloc.
• Many languages permit combinations of these types of allocation. For example, Pascal allocates some variables (global variables) statically, allocates local variables automatically, and allows the programmer to allocate more memory dynamically.

Scope

• In languages with block structure and name reuse, there can be some confusion as to which version of a variable is being used.
• Consider the following code in some generic language

  begin block
    String str = "global";
  
    procedure alpha()
    begin
      String str = "alpha";
      printstr();
    end;
  
    procedure printstr()
    begin
      print("The current string is '" + str + "'");
    end;
  end block
  

• What does this print? Depending on your experience, you may come up with different "obvious" answers. The two general philosophies are called static scoping and dynamic scoping.
• In static scoping, the version of a variable used is determined by a static analysis of the program. Static analyses are based on the text, rather than the execution of the program.
• In dynamic scoping, the version of a variable used is determined dynamically, at run time. Most frequently, the most recent version is used.
• Why use static scoping?
  • The address of a variable can be determined at compile time. This can lead to efficient code.
  • It's more logical, in some senses.
  • It's easier to analyze programs to verify that assignments and such are legal. (Compile-time type checking often requires static scoping.)
• Why use dynamic scoping?
  • It's easier to update parts of a program while the program is running. "Whoops, I screwed up the value of this variable. I better update it. Whoops, let's define a new version of function foo."
  • It provides a "clearer" alternative to forward function declarations. Note that in statically scoped languages, there may be some confusion as to what it means to call a function that is not yet defined. In dynamically scoped languages, that can be determined at run time.