1. In lambda calculus, all computation is carried out by untyped functions.
2. In our approach to Lisp and its interpreter, we view computation in essentially the same way.
3. That is, all computational constructs in Lisp, including its own evaluator, are represented as untyped functions.

1. In general, pure lambda calculus is a more primitive notation, in that nothing is built-in except function definition and invocation.
2. However, once basic arithmetic and list operations are constructed from lambda calculus primitives, it's essentially the same notation as pure Lisp.

1. We'll use it in the same way that the Hudak and Cardelli/Wegner papers use the pure lambda calculus notation.
2. In particular, there is a lisp-based formulation of typed lambda calculus presented later in the notes that we'll use as the basis for assignment 2.

1. A lambda expression is an anonymous function value.
2. E.g., the expression (lambda (x) (+ x 1)) is a function that adds one to its argument.
3. What one does with a lambda expression is apply it to actual parameters, as in

   (apply (lambda (x) (+ x 1)) '(10))
   

   which delivers 11.
4. Interestingly, the fundamental semantics of the following two definitions is the same:

   (defun f (x) (+ x 1))
   

   versus

   (setq g (lambda (x) (+ x 1)))
   

   that is, f and g define the same function.
5. For technical reasons, Common Lisp disallows the direct application of a lambda form, as in (g 10)
   1. Hence in GCL, application of a lambda form must be performed as (apply g '(10))
   2. This disallowance is really just a technicality; earlier versions of Lisp did in fact treat the preceding definitions of f and g as exactly the same, and hence allowed direct eval of lambda forms.

1. In the solution to assignment 1, when we bind a function value we are effectively treating the function body as a lambda expression.
2. The keyword "lambda" need not be used in the function binding, but the notion of treating an unevaluated function body as a piece of data is the same.

1. The lambda calculus is in a sense the grandparent of all purely functional notations.
2. When we study denotational semantics, we will define everything as a function, including memory itself.
3. For example, here is the purely functional definition of a variable-binding memory:

   (setq memory
       (lambda (x) (cadr (assoc x '( (x 10) (y 20) (z 30))))))
   

4. Conceptually, this definition treats memory as a function that when applied to the name of a memory location returns its value (sort of like the hardware definition of memory as a "map").
5. Given this definition, here's how we look up the value stored at memory location y:

   (apply memory '(y))
   

6. And here's how we add a new binding

   (defun add-binding (memory binding)
       (nconc (cadadr (cdadar (nthcdr 5 memory))) (list binding)))
   

   (excuse the nconc, please).
7. When you can wrap your head around these definitions of memory, you're getting the gist of purely functional thinking.
8. And lest you think the definition of add-binding is some kind of Lisp parlor trick, it is in fact the direct Lisp translation of the denotational semantics function for "memory perturbation" as defined by Tennent.

1. a basic (or primitive or atomic) type
2. a composite (or constructed or non-atomic) type

1. type boolean is the two-element set (true, false).
2. type integer is the infinite set of all decimal integers

1. a record type is composed of values of two or more types
2. an array type is composed of zero or more values of the same type

1. a typed value is clothed to protect it from undesirable outside elements that may want look at it in ways it should not be looked at
2. an untyped value is naked and exposed to the outside world, subject to all manner of manipulation

1. A strongly typed language is one in which all values and variables have a consistently known type.
2. A weakly type language is one in which some or all values and/or variables have no type, or a type that changes inconsistently.

1. A statically typed language is one in which the types of all values and variables are known before program execution begins.
2. A dynamically typed language is one in which the types of some or all values and/or variables are not known until during program execution.

1. A monomorphic language is one in which all functions operate on parameters of exactly one type.
2. A polymorphic language is one in which some or all functions may operate on parameters of more than one type.

1. A language with encapsulated types provides the means to hide the representation of types from external view
2. A language with flat typing provides no form of type encapsulation.

1. A language with a subtyping capability allows one type to be a parent type from which one or more child types may inherit properties.
2. A language without subtyping provides no form of inheritance.

1. A language with generics is one in which some form of parameterized type is definable.
2. A language without generics is one in which each type must be fully and explicitly defined.

1. An often-cited but infrequently-used language
2. ALGOL 68 provided one of the first formal definitions of structural versus name type equivalence.

1. For example, the following is a genuinely polymorphic equality function:

   forall type T,
     function Eq(x:T, y:T) =
       x = y;
   

2. The body of the function works for any arguments of the same type for which equality is defined.

1. This form of polymorphism is called parametric
2. It involves the use of type variables to define the types of function parameters
3. These type variables hold the position of a variable number of types, constrained only by how the body of the function is implemented.

1. For example,

   class A = ... ;
   class B subclass of A = ... ;
   class C subclass of a = ... ;
   function Eq(x:A, y:A) =
       x = y;
   

2. Here the function Eq is polymorphic over types A, B, and C.
3. This is due to the normal rules for subtyping defined by inheritance (more on this shortly).

1. This type of polymorphism is called subtype (or inclusion in Cardelli and Wegner).
2. The standard rule for subtype polymorphism is that a function defined on a parent type is polymorphic on all subtypes of that parent type.

1. The two major forms of apparent polymorphism are overloading and coercion.
2. What distinguishes genuine from apparent polymorphism is that with genuine polymorphism, neither the body of the polymorphic function nor the types of its actual parameters change when the function is invoked.
   1. In the case of overloading, there is a separate function body for every distinct set of argument types (i.e., the function body changes).
   2. In the case of coercion, the types of actual parameters are forced to the required type of the called function when the function is called (i.e., the actual parameter types change).

1. A base set of type primitives
2. A set of type composition rules

(deftype name type)
    where type is
      * one of the atomic type names sym, int, real, string, or bool
      * a composite type specified with one or more of the four type forms
        below
      * the name of a defined type, including a recursive reference to such a
        name
      * a type variable of the form ?X, for any atom X

(array type [bounds])
    where bounds is either an integer, or (integer integer) pair, or a type var

(record fields)
    where fields is a list of (name type) pairs in which all names must be
    unique; fields may be a single type var

(union fields)
    where fields is a list of (name type) pairs in which all names and types
    must be unique; fields may be a single type var

(function args outs [suchthat])
    where args and outs are lists of names or (name type) pairs; names and
    (name type) pairs can be mixed in a signature; the name in a (name type)
    pair may be empty; args and/or outs may each be a single type var; suchthat
    is of the form (suchthat predicate), and the predicate can reference type
    vars

(defun name args [outs] [suchthat] body)
    where args, outs, and suchthat are as defined above for the function type