Programming Languages (CSC-302 98S)
Outline of Class 37: Introduction to Semantics
Held: Monday, May 4, 1998
- 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
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.
- 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
- In many informal definitions, it is unclear in what order
the various function calls are done in
(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
- 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
- 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
- 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
- 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).
- 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
- 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.
- 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
- 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
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.