Thought question

• How do you know what are well-formed programs in a language?

Introduction

• syntax - "form", a specification of the well-formed constructs in a language
• semantics - "function", a specification of the meaning of construct in a language

Formal Descriptions of Syntax

• a language recognizer - A recognizer is a machine that takes a string and determines if it belongs to the language described by the grammar.
• a language generator - A generator is a machine that produces only legal sentences in the language. It produces random sentences.

To simplify the specification of a grammar, usually the syntax of a programming language is specified with respect to an alphabet that is a set of tokens (Contrast with CptS 317 where alphabets are typically collections of single characters). A token is a category of lexemes. Example lexemes (literally, what appears in the program) are:

• begin
• }
• "asdfas"
• 3.54
• (
• foo

• identifier: foo
• reserved word begin: begin
• string literal: "asdfas"
• integer literal: 7
• right brace: }
• left parenthesis: (
• plus operation: + -
• mult operation: * / %

  sum = x + y;

BNF

• Terminals - These are the tokens. Terminals will be represented as the name of the token, e.g., begin means the token corresponding to the reserved word begin, identifier means any identifier, etc.
• Nonterminals - These are represented in angle brackets, e.g., <stmt> means the nonterminal statement.
• Rules or productions of the form

  nonterminal

  ->

  body

  The body of the rule consists of a list of
  • terminals,
  • nonterminals,
  • | (meaning "or"),
  • a pair of brackets, [], enclosing an optional clause,
  • a pair of braces, {}, followed by a * (meaning zero or more), or + (meaning one or more), enclosing a repeating clause
  • e or E, representing the empty string.
  The interpretation of a rule is that the syntax of the nonterminal, sometimes called the head or left-hand side (LHS) is described by the body, sometimes called the right-hand side (RHS). For example, the following rule describes the syntax of an if statement.

  <if_stmt>	->	if <predicate> then <stmt>
  	|	if <predicate> then <stmt> else <stmt>

  Note that a non-terminal may be the LHS of several rules. The rule given above is the same as the pair of rules given below.

  <if_stmt>	->	if <predicate> then <stmt>
  <if_stmt>	->	if <predicate> then <stmt> else <stmt>

  Another equivalent formulation is as an optional clause.

  <if_stmt>

  ->

  if <predicate> then <stmt> [ else <stmt> ]

• A start symbol - By default the start symbol is the nonterminal on the LHS of the first rule.

Derivations

Derivation Tree

• The root of the tree is the start symbol.
• Every interior node is a nonterminal.
• Every leaf is a terminal.
• There is one child for each nonterminal or terminal in the body of a production that is used in the derivation.

                      stmt_list
                          |
                        stmt
                       / | \
                    var  =  expr
                     |      / | \
                     X   expr *  expr 
                        /  | \      |
                    expr   -  expr  X
                     |         | 
                    var       var
                     |         |      
                     Y         Y      

                      stmt_list
                          |
                        stmt
                       / | \
                    var  =  expr
                     |      / | \
                     X   expr -  expr 
                           |     / | \
                           Y  expr *  expr
                               |       | 
                              var     var
                               |       | 
                               Y       X 

Parsing

Relationship between Grammar, Associativity and Precedence

Associativity refers to a "direction" in which (binary) operators associate. In mathematical notation, subtraction is left-associative meaning that

  7 - 3 - 4 

  (7 - 3) - 4 

  7 - (3 - 4)

Precedence refers to which operations are executed prior to others. Multiplication typically has higher precedence than subtraction meaning it should be done first so

  7 + 3 * 4

A parse tree implicitly says which operations' results are input to other operations. For example, in the parse tree given above, if we assume X = 3 and Y = 4, then the result is 4 - (4 * 3) or -8 because the result of the multiplication is the second operand of the substraction.

Question: what is the result if we use the first parse tree instead?

Associativity and precedence can be specified in a grammar by altering whether recursion is done on the right or left sides of rules, and by altering the derivation order of the grammar rules.

To specify precedence, the trick is to split the production where the precedence is ambiguous into two (or more) productions. Notice that this moves multiplication down the parse tree, so that a multiplication can never be the ancestor of a subtraction.

<stmt_list>	->	<stmt>
	|	<stmt> ; <stmt_list>
<stmt>	->	<var> = <expr>
<expr>	->	<expr> - <expr>
	|	<term>
<term>	->	<term> * <term>
	|	<var>
<var>	->	X
	|	Y

Question: what might we do to the grammar so that the result of a subtraction might be an operand of a multiplication? How would you do it in mathematical notation?

We can specify associativity in the grammar by giving a direction to the parse, that is, by recursing on only the left side (or right side, but not both) of an operation. Let's make subtraction left associative and make multiplication right-associative (just as an illustration).

<expr>	->	<expr> - <term>
	|	<term>
<term>	->	<var> * <term>
	|	<var>
<var>	->	X
	|	Y

Exercise: convince yourself that the above grammar gives multiplication precedence over subtraction, that subtraction associates to the left, and that multiplication associates to the right, by creating parse trees for several expressions.

So now for a nasty little secret about programming languages and context-free grammars. The grammar for a PL typically does *not* specify the acceptable programs of the language. Consider

   int *c;
   c = 17;

Some aspects of the language, such as type checking, are difficult (in the sense that they make the grammar blow up in size) or impossible to express using CFGs. These aspects usually go by the name of static semantics. We will take up the issue of types and type checking later in the semester.

Dynamic Semantics

• Operational semantics - Describe precisely the meaning of each statement in a high-level language in terms of a low-level language. My description of PostScript was essentially done by giving an informal operational semantics.
• Axiomatic semantics - Useful in proving correctness of programs. Think of program as a proof and each statement as an axiom. The axiom relates a precondition (about the state) to a postcondition (about the state).
• Denotational semantics - Each statement can be modeled as a function that relates the input (the state prior to the statement) to the output (the state after the statement). The program is modeled by composing functions.

Operational Semantics

  if <predicate> then
    <stmt_list>1
  else
    <stmt_list>2

     T(<predicate>)
     # Assume boolean result of predicate ends up in R1
     eq  R1, false, L1:
     T(<stmt_list>1)
     goto L2:
L1:
      T(<stmt_list>2)
L2:

Axiomatic Semantics

Review the material covered in Math 216 on propositional and predicate logic as a prelude to tackling this section. You are likely to need DeMorgan's laws for negation of conjunctions (and) and disjunctions (or) and also their extension to statements quantified using "for all" and "there exists".

Fundamental to understanding axiomatic semantics is an understanding of state. For our purposes here, a state of a computation (of some program) is simply the values of all the variables in the program. We use predicate logic formulas to describe properties of states that are of interest to us. Examples

    x = y            %% true in states where x and y have equal values
    z < x + y        %% true in states where z is less than x+y

  {P} S {Q}

The fundamental insight of axiomatic semantics is that if we want some property to be true of the state after executing a statement it is straightforward to determine what must be true of the state before executing the statement. The before-to-after direction isn't nearly as easy, so axiomatic semantics is initially counter-intuitive and feels like it works "backwards" to many people.

Suppose that I have some statement S with postcondition Q that I wish to be true of the state after executing S. The weakest precondition of S with respect to Q, written wp(S, {Q}), is a predicate that describes all of the states from which executing S leads to a state satisfying Q.

An axiomatic semantics is essentially a set of rules for reasoning about and deriving weakest preconditions for statements of a programming language.

Notice that wp() is a bit like an integral expression in calculus in the following way: it has a well-defined meaning, but without applying some rules to transform it to a simpler form, we won't understand very much about what it is telling us of the initial state. Indeed, axiomatic semantics is sometimes called the weakest-precondition calculus.

Assignment

   Qx -> E

  wp(x = y * 5, {x = 10 and z = 4})

  wp(x = x * 5, {x < 10 and z = 4})

We want the weakest precondition since often there are many possible preconditions. Consider

  wp(x = y * 5, {x < 10})

Sequences

   wp( S1; S2, {Q})

   wp(S1, wp(S2, {Q})

   wp(x1 = E1 ; x2 = E2, {Q})

  wp(x1 = E1, {P'})

  P' = Qx2 -> E2

  wp(x1 = E1 ; x2 = E2, {Q})

  (Qx2 -> E2)x1 -> E1

  wp(x=z+1; y=x*2, {y=10})

  wp(x=z+1, {x*2=10})

  (z+1)*2=10

  z = 4

A compact representation of the sequence rule is in asserted program form

   {P} S1 {Q} S2 {R}

Selection (if)

  wp(if B then S1 else S2, {Q})

  (B => wp(S1, {Q})) and (not B => wp(S2, {Q}))

  wp(if x < 0 then x = y + 1 else x = y - 1, {x = 4})

 (x < 0 => y=3) and (x >= 0 => y=5)

  (x < 0 and y = 3) or (x >= 0 and y = 5) 

  (y = 3 or y = 5)

   {P}
   if B then {P and B} S1 {Q} else {P and not B} S2 {Q}
   {Q} 

Loops

Loops are a powerful programming tool to represent much computation with little code, and axiomatic semantics has an equally powerful tool to reason about what loops do. The key to reasoning about loops is to identify a loop invariant, denoted I. The invariant is assertion that is true before each execution of the loop body. Using invariants is like using induction: we show that it is true for the base case and show that if it is true for n-1 iterations it is true for n iterations. The rule for

  while B do S end

  {I and B} S {I} implies {I} while B do S end {I and (not B)}

  (I and B) => wp(S, {I})

  I => wp(while B do S, {I and not B})

  1) P implies I
  2) {I and B} S {I}
  3) (I and (not B)) implies Q
  4) the loop terminates

  while x != y do y = y - 1 {x = y}

  {x = y}

  {x = y - 1}

  {x = y - 2}

  {x = y - n}

  {x = y - n} implies {x <= y}

  {x <= y}

  {x <= y and x != y} y = y - 1 {x <= y}

  {x <= y and x != y} implies {x < y} 

  {x < y} y = y - 1 {x <= y}

  {x <= y and (not x != y)} implies {x = y}

  {x <= y and x = y} implies {x = y}

  P and Q implies Q

Denotational Semantics

  numbers, e.g., 3, -10
  a plus operation, e.g., [3 + 4]
  a print operation, e.g., print [3 + 4] would output 7
  an if-then-else statement (with non-zero for "truth"), e.g., 
     if [3 + 4] then 4 else [4 + 5]

  M('0') =def 0
  M('1') =def 1
   ....
  M([x + y]) =def M(x) + M(y)
  M(if B then expr1 else expr2) =def 
           if M(B) != 0 then M(expr1) else M(expr2)
  M(print expr) =def output M(expr)

  print if [[3 + 4] + -7] then 5 else 6

  M(print if [[3 + 4] + -7] then 5 else 6) 
    -> output M(if [[3 + 4] + -7] then 5 else 6) 
    -> output if M([[3 + 4] + -7]) != 0 then M(5) else M(6)
    -> output if M([3 + 4]) + M(-7) != 0 then 5 else 6
    -> output if M(3) + M(4) + -7 != 0 then 5 else 6
    -> output if 3 + 4 + -7 != 0 then 5 else 6

Capturing state

  M(x = E, state) =def statex -> M(E,state)

Loops

   M(while B do S, state)  =def 
                  if (B,state) then M(while B do S, M(S,state))
                  else state

Source of Information