[ ^ CSE 341, Winter 2004 home page | Lectures index ]

CSE 341: Functions and patterns, supplementary notes

What is functional programming?

Functional programming is a style that emphasizes:

• Expression-oriented programming
• Heavy use of functions as values: higher-order and anonymous functions
• Side-effect-free code; referential transparency
• Recursion instead of iteration

Secondary characteristics (usually, but not always part of FP) include:

• Strong typing
• Garbage collection
• Emphasis on lists as a data type

Language Construct X in a Nutshell

All language constructs (in a statically typed language) have three parts:

• 1: Syntax: What does it look like?
• Semantics: What does it mean?; in two parts:
  • 2: Dynamic semantics: What does it do at runtime?
  • 3: Static semantics: How is it typechecked? This consists of at least two parts:
    • What subexpressions are legal and illegal in the type system? Alternatively phrased: What constraints does the type system place on well-typed instances of construct X?
    • For well-typed constructs, what is the resulting type of the construct?

Stating these three properties gives you the essence of the language construct. When language designers design a language, they go through these three steps for each construct --- either consciously or unconsciously.

In these notes, we will do two examples informally, to show this formula in action.

if/then/else in a Nutshell

Syntax:: If/then/else expressions have the syntactic form:

if expr1 then expr2 else expr3

Dynamic semantics: First, expr1 is evaluated to a value v. If v has the boolean value true, then expr2 is evaluated and returned. Otherwise, v has the boolean value false, and expr3 is evaluated and returned.

Static semantics:

• Constraints: expr1 must have the type bool. It must be possible to unify expr2 and expr3 to the same type; call this type T.
• Result type: The expression has type T

Functions in a Nutshell

There are two constructs related to functions: definition (sometimes called abstraction in the programming languages literature) and application (a.k.a. function call).

Function definition

Syntax: Function definitions have the syntactic form

fn pattern => returnValue

Dynamic semantics: A function definition constructs a closure that contains two parts:

• The code of the compiled function.
• An environment pointer that "captures" variables in the surrounding environment.

Static semantics:

• Constraints: A function must have a well-typed body, assuming the names bound in its argument pattern have the inferred types (and any references to enclosing names have the proper types, etc.).
• Result type: The type of the function is argType -> returnType, where argType and returnType are inferred from the argument pattern and body.

Function application

Syntax: Function applications have the syntactic form

expr1 expr2

Dynamic semantics: First, expr1 is evaluated to a value value1. Second, expr2 is evaluated to a value value2. Then, value1's function body is evaluated in the environment produced by matching value2 against the argument pattern.

Static semantics:

• Constraints: A function application is well-typed if expr2's type can be unified with expr1's argument type.
• Result type: The type of the function application is the result type of expr1*

* With polymorphic type variables appropriately instantiated. We'll learn about polymorphic types in the next couple of lectures.

Sample exercises

The answers to the following exercises are available here.

• Which of the following pattern-matches fail? Which succeed? For successful matches, draw a diagram of the bindings that result, and annotate each name binding with its type. For unsuccessful matches, describe briefly the reason for the failure.

  1. val (a, _) = (("hi", "bye"), fn x => x + 1);
  2. val (_, b) = (("hi", "bye"), fn x => x + 1);
  3. val {a=a, b=b} = ({a="hi", b="bye"}, fn x => x + 1)
  4. val (x:char)::xs = ["a","b","c"];
  5. val x::y::z = ["a","b","c"];
  6. val x::y::z = ["a","b"];
  7. val x::y::z = ["a"];
  8. val x::y::(z:string list)::zz = ["a", "b", "c"];
  9. val (a:int->int, b) = (fn x => x + 1, fn x => x ^ "1");
  10. val (a, b) = (fn x => x + 1, {foo=fn x => x ^ "1", bar=fn x => x * x});

• For each of the following recursive functions, state briefly why it isn't properly tail-recursive, and then write a tail-recursive version.

  1. fun sumN 0 = 0
       | sumN n = n + sumN (n-1);
     

  2. fun factorial 0 = 1
       | factorial n = n * factorial (n-1);
     

  3. fun joinStrings nil     = ""
       | joinStrings (x::xs) = x ^ joinStrings xs;
     

  4. fun countDown 0 = [0]
       | countDown n = n::(countDown (n-1));
     

  5. fun countUp 0 = [0]
       | countUp n = countUp (n-1) @ [n];
     

• Try writing the syntax, dynamic semantics, and static semantics for the following language constructs.*
• Integer addition. (Actually, this is a function application --- using infix operator syntax --- but pretend it's a primitive.)
• List cell cons.
• val binding. (You do not have to describe pattern matching --- assume this has been defined.)
• let expressions. This can be defined two ways --- as a "primitive" construct, from the ground up, or as a syntactic sugar for a series of function applications.** Define it both ways.

* For most of these constructs, the static semantics for full ML uses polymorphic types. For now pretend ML only has monomorphic types like int, string, or (int * int * int).

** Actually, there are slightly different typechecking requirements between function application and let, but the distinctions are beyond the scope of your current knowledge.

This work is licensed under a Creative Commons License. Rights are held by the University of Washington, Department of Computer Science and Engineering (see RDF in XML source).