Outline of Class 37: Introduction to Semantics

Held: Monday, May 4, 1998

Administrivia

• Don't forget that assignment six is due today. I've been told that this is my first assignment that is doable in significantly under ten hours.
• Those of you who have asked for an extension on the makeup for assignment 5 have until Wednesday (as do those of you who didn't ask for an extension).
• Those of you who attempted to read the Scheme semantics reported being totally lost. Hopefully, today's discussion of denotational semantics will help. You will not understand the Scheme report unless you master the chapter on semantics.
• Since some of you didn't know: Charles Earl has been offered the visiting position for next year and has accepted the position. We are still discussing who will teach what.
• We'll spend the first twenty minutes of class on the joyful course evaluation form.

Introduction to Formal Semantics

• When describing a programming language it is necessary to specify not only the syntax (what programs look like) but also the semantics (what programs mean).
• Traditionally, semantics have been specified informally. However, this leads to many ambiguities when the designers don't consider all the alternatives:
  • In many informal definitions, it is unclear in what order the various function calls are done in f1()+f2()+f3() (the order of addition is clear, but it's not always specified which argument is fully evaluated first).
  • In many informal definitions, no effort is made to handle error cases other than to say that they're in error.
  • ...
• Often, it is up to the implementers of languages to make these decisions. Different implementers make different decisions, which leads to incompatabilities.
• Clearly, implementers should be able to make some decisions (e.g., where in memory to put values. However, most informal definitions don't make it clear what is necessary and what is optional.
• What is the solution? Currently, the trend is to define a formal semantics for the language based on rules of logic.
  • Of course, a bad formal specification is no better than a casual specification.
  • The use of logics and formal systems can help us ensure that we don't make mistakes.
• What are typical formal and informal semantics?
  • "Casual" semantics: English text describing what each part does. Likely to lead to misinterpretation.
  • "Implementational" semantics: meaning is based on a particular implementation.
  • Translational semantics: meaning is based on a formal translation of the language to another language. Often, these translations are done via an attribute grammar. [In some sense, the transitional semantics is a more formalized implementational semantics based on compilation.]
  • Operational semantics: meaning is given by specifying the effects of any program on any input. Typically, this is done via an interpreter. [Similarly, the transitional semantics is an implementational semantics based on interpretation.]
  • Denotational semantics: Every program has an associated meaning (a denotation), given by a Meaning function (the semantics). For some, this seems similar to translational semantics with the destination language being something very similar to the lambda calculus (generic functional programs). The translation is described more with function definitions than with attributes (although there is again some similarity).

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).
• 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 (since it's similar enough to one we've used in the past).

  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.