Class 12: Introduction to Denotational Semantics

Held Friday, February 19

Summary

• Exam 1 due.

Contents

Notes

• Is anyone here not in 341? (Other than Jack, who took it two years ago.)
• Advance warning: I'll be gone next Wednesday afternoon, so you'll need to find me in the morning or on Thursday.
• A number of people seemed to expect to find me in the office yesterday. Thursday's are my ``project day'', which means that I'm typically working on something intensive, such as an exam. You should not expect to be able to ask me questions on Thursday (except next week).
• No written homework assignment for next week! I expect you to spend some of the time you would have spent on a homework assignment carefully reading the semantics of Scheme. (At least two hours for each discussion.)
• Exams due. I should have them back by Monday. How long did they take?
• On Monday at noon, there is a meeting to discuss summer research opportunities in computer science at Grinnell.
• On Tuesday at 12:15 in 2413, there is an informational meeting on an MBA Program with specialization in information and software systems. It seems that students in the program will receive a $20,000 fellowship plus tuition.
• Because the book does not cover this subject in depth, I've included perhaps more in this outline that I would normally. Hopefully, we'll cover it all. If not, we'll talk about more issues on Monday.

Denotational Semantics

• Denotational semantics is currently among the most popular ways for formally describing the syntax of a language.
• Recall that a denotational semantics is based on a meaning function that provides a denotation (meaning, semantics) for each utterance.
  • This function maps elements of syntactic domains to elements of semantic domains.
• Once we've done the high-level overview, we'll ground our discussion in a semantics for SIMPLE.
• In addition to the domains, one also has both an abstract syntax and a concrete syntax to describe elements of the functional domain.
• The concrete syntax gives all of the details and handles issues like precedence and ambiguity.
• The abstract syntax ignores these details, and makes it easier to describe the semantics.
• Both syntaxes describe the same language, the abstract syntax just may be ambiguous.
• To map between the domains, we have one or more semantic functions.

A Note on Typography

• There are a lot of ``things'' in a typical semantics: semantic domains, syntactic domains, grammars, variables in the various domains, semantic functions, etc. etc.
• Hence, a typical semantics will make use of different typefaces and naming conventions to clarify the role each symbol plays.
• Since I don't have that freedom, I'll often use names, rather than symbols.

Environments

• A key issue in many semantics is the mapping of variables to values.
• Typically, we represent this mapping as an environment. For every variable or identifier, the environment maps that variable or identifier to a value (or to ``undefined'').
• We can then think of programs as manipulating input, output, and environment.
• The semantic description of a program often begins with an empty environment, which maps every variable to undefined.
  • It's also possible to map selected variables to default values.

A Simple Language

• It is often easiest to discuss semantics by examining how one writes semantics for language constructs we know. We'll begin with a simple imperative language, SIMPLE (Simple Imperative Mathematical Programming Language Example).
  • Yes, we use too many acronyms.
• SIMPLE will have variables, expressions, basic control (sequencing, loops, and conditionals), input, and output.
• We might begin with its syntax. The syntax of Expressions is left to the reader. (I realize that we have not formally discussed syntax, but this should be clear to most of you.)

  Program ::= StatementList
  StatementList ::= Statement
                 | Statement ';' StatementList
  Statement ::= Assignment
             | Conditional
             | Loop
             | Input
             | Output
  Assignment ::= identifier '=' Expression
  Conditional ::= 'if' Expression 'then' StatementList 'fi' 
               | 'if' Expression 'then' StatementList 'else' StatementList 'fi'
  Loop ::= 'while' Expression 'do' StatementList 'od'
  Input ::= 'read' '(' Identifier ')'
  Output ::= 'write' '(' Expression ')'
  

  • Note that I'm using a semicolon as a statement separator.
  • Note that we use terminators for the control statements so that there is less ambiguity.

A Denotational Semantics for SIMPLE

• Let's develop a denotational semantics for SIMPLE. Our semantics will need to accommodate the various utterances in the language.
• We begin with syntactic domains. These correspond to the nonterminals of our grammar.

  V in Val                       Numeric constants
  I in Id                        Variables
  E in Exp                       Expressions
  S in Sta                       Statements
  L in SL                        Statement Lists
  P in Prog                      Programs
  

• We continue with an abstract syntax.

  // Programs
  Prog => L
  // Lists of statements
  SL => S
      |  S ; L
  // Statements
  Stat => I = E
        |  if E then L fi
        |  if E then L0 else L1 fi
        |  while E do L od
        |  read(I)
        |  write(E)
  // Expressions
  Exp => E1 + E2
       |  E1 * E2
       |  E1 - E2
       |  E1 / E2
       |  (E)
       |  V
       |  I
  

• Note that this syntax is ambiguous and somewhat different from syntaxes you might expect or have seen, particularly the part of the syntax that describes expressions. This is an abstract syntax and assumes that the details (such as associativity) are worked out in the concrete syntax. Note also that we use variables on the right hand side and sets on the left.
  • This simplified version is easier to work with.
• We'll need a meaning function for each of the syntactic domains. We'll call these meaningProg, meaningStat, meaningExp, and meaningSL.
• What are the semantic domains we'll need? Certainly input (a list of numbers), output (a list of numbers and ``errors''), the environment (a map from identifiers to numbers or ``undefined''), and perhaps some other things.

  N                            Natural numbers
  U = Id -> N                  Environments
  I = N*                       Input (a sequence of numbers)
  O = N*                       Output (a sequence of numbers)
  

• We certainly need to consider the appropriate type of our functions.
• What is the type of an evaluated program? A program should be a function from input to output.

  meaningProg : Prog -> I -> O
  

  • We'll spend a little time discussing this type.

Detour: Curried Functions

• A mathematician nameed Haskell B. Curry observed that there are many ways to think of functions of multiple arguments, particularly when we're working with ``higher-order'' functions.
  • A function of two arguments can be thought of as a function from pairs of elements to whatever.
  • A function of two arguments can be thought of as a function of one argument that returns another function of one argument that returns a value.
• Consider a add function.
  • We might write

    (define add (lambda (x y) (+ x y)))

  • We might write

    (define add (lambda (x) (lambda (y) (+ x y)))) 

• The second version is called the Curried version of the function.
  • No it's not spicier.
• You have to apply Curried functions slightly differently. Rather than writing (add 3 4), you would write ((add 3) 4).
  • Some other functional languages provide more elegant notations.
• Curried functions are quite useful, because you can partially apply them.
• Consider

  ;;; Determine if x is a multiple of n
  (define multiple (lambda (n) (lambda (x) (zero? (modulo x n)))))
  

• We could use this along with a filter function to get only multiples of 3 from a list.

  (filter (multiple 3) lst)
  

Types for the Semantic Functions

• What is the type of an evaluated statement? That might be a little bit harder. In order to evaluate a statement, we need the environment and may need the input. After evaluating a statement, we may have affected environment, output, and input.
• How do we ``pass them back'' for the next statement?
  • We could return a triplet.
  • We could evaluate the next statement (and everything else in the program) in the updated environment and using the updated input.
  • We could call a continuation that expects three arguments.
• We'll try the second strategy. This means that the meaning functions for statements must take ``something'' as a third parameter. Hmmm ... that thing is ``rest of program'', which seems awfully like the traditional notion of ``continuation''.
  • See, there's are a number of reasons we were learning about continuations.

    C = U -> I -> O
    

  • That is, this kind of continuation is something that given an environment and input list, returns an output list.
• Now let's again consider the type of meaningStat. To determine the meaning of a statement, we need its continuation, environment, and input. The result is output.

  meaningStat : Stat -> C -> U -> I -> O
  

  • That is, we compute the meaning of a statement given the statement, a continuation for the statement, an environment, and an input list. The meaning is a list of output.
• Okay, what about statement lists? From our abstract and concrete syntax, we know that a statement list can be a statement or a statement followed by a statement list. Statement lists can also appear in while loops and conditionals. We also know that statement lists relate to programs. Since they'll need to read input and write output using an environment, perhaps with

  meaningSL : SL -> C-> U -> I -> -> O
  

• We're left with expressions. What is the type of meaningExp? It might be useful to specify what happens with the expression, or it might be useful just to give a value. In either case, we need the environment (since the expression may contain variables). Rather than using continuations, we'll just have the meaning of an expression be a value.

  meaningExp : Exp -> U -> N
  

• Note that we need an environment so that we can look up identifiers.
• Note that there is no continuation for expressions. This means that expressions cannot change the environment or input.
  • An important statement about the language, seemingly ``hidden'' in the design of the semantics.
  • Real denotational semantics also have such implicit decisions, so you'll need to read them carefully.

Semantic Functions

• We are now ready to write our semantic functions.
• The meaning of a program is the meaning of the corresponding statement list when run on the basic environment.

  meaningProg[[SL]] = meaningSL[[SL]] cleanup basicEnv
  basicEnv : U
  basicEnv = \x . undefined
  cleanup = \env . \inp . nil
  

  • Note that I'm using \var . body for lambda var . body
• Where's the input? It's hidden, because everything is Curried. We could just as easily have written

  meaningProg[[SL]] = \inp . meaningSL[[SL]] cleanup basicEnv inp
  

• What is the meaning of a statement list? It depends on whether it's a single statement or an actual list. In the first case, the meaning is simply the output of the statement.

  meaningSL[[S]] = meaningS[[S]]
  

  • We again take advantage of Currying.
• What is the meaning of a statement list with multiple statements? It's fairly simple.

  meaningSL[[S;L]] =
    \cont . \env . \inp . 
    meaningS[[S]] (meaningSL[[L]]] cont) env inp
  

  • You might want to check the types of all the arguments.
• Now we can worry about the individual statements.
• What is the meaning of input? An update to the environment. Note that to update the environment, we'll need a conditional and some list selection operations.
  • We'll use the McCarthy conditional, t -> a, b, which means ``if t then a else b''.
  • We'll just use car and cdr for list selection.

    meaningStat[[read(I)]] =
      \cont . \env . \inp . 
        cont (setenv env I (car inp)) (cdr inp)
    setenv : U -> Id -> N -> U
    setenv env id num =
      \x . (x == id) -> num , (env id)
    

• What if the input list is empty? We could assign a particular meaning to the program (e.g., ``undefined'') or to the the variable being read. How do do so is left to the reader.
• What is the meaning of output? We'll assume there is a convenient cons operation. (See the Scheme specification for a more formal version.)

  meaningStat[[write(E)]] =
    \cont . \env . \inp . 
      cons (meaningExp[[E]] env) (cont env inp)
  

• Assignment is similar to a combination of the two.

  meaningStat[[I = E]] =
    \cont . \env . \inp . 
      cont (setenv env I (meaningExp[[E]] env)) inp
  

Loops

• What about loops? Loops can be more complicated for a number of reasons.
  • The definition is even more recursive than most.
  • Not all loops terminate.
• We'll handle recursion the ``quick and dirty'' way. We're describing a function, not defining it. Any function that meets our criteria is acceptable (although we prefer the least such function).
• Nontermination is a more subtle issue. In effect, a program that doesn't terminate doesn't meet our requirements for the meaning function (generating a list of numbers). What do we do? We should update our requirements (including, perhaps, cons) so that ``nonterminating'' is a legal result. [This is left as an exercise for the reader.]
• So,

  meaningStat[[while E do L od]] = F(E,L) s.t.
    F(E,L) : C -> U -> I -> O
    F(E,L) cont env inp = 
      ((meaningExp[[E]] env) == 0) -> cont env inp,
      meaningSL(L) (\e . \i . F(E,L) cont e i ) env inp
  

  or

    F(E,L) cont env inp = 
      ((meaningExp[[E]] env) == 0) -> cont env inp,
      meaningSL(L) (F(E,L) cont) env inp
  

  or

    F(E,L) cont env = 
      ((meaningExp[[E]] env) == 0) -> cont env,
      meaningSL(L) (F(E,L) cont) env
  

• Why did I give you three variations of the same function? Because when you read a typical semantics, you'll find that the different structures are used and you need to be familiar with them.

History

• Created Tuesday, January 19, 1999 as a blank outline.
• Started to fill in details on Thursday, February 18, 1999. Some parts were based on outline 37 and outline 38 of CS302 98S.
• Added some more details on Friday, February 19, 1999. In particular, added a discussion of Currying based on one from outline 22 of CS302 98S.
• A few minor modifications on Friday, March 12, 1999.