CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann

Michael Eckmann - Skidmore College - CS Fall 2008 Today’s Topics Questions/comments? Describing Syntax & Semantics (Chapter 3)‏ –Short review –Mini pascal grammar –Attribute grammars to allow for specifying static semantics –Semantics Operational Axiomatics Denotational (next time)‏

Michael Eckmann - Skidmore College - CS Fall 2008 Chapter 3 so far Generator / recognizer Is a grammar a generator or recognizer, do you think? CFG and BNF are what? CFG and BNF are used for what? Derivation for a sentence (program)‏ Parse tree for a sentence (program)‏ What is ambiguity and why is it bad?

Michael Eckmann - Skidmore College - CS Fall 2008 Chapter 3 and 4 Just as an aside, I think it is important in this course at Skidmore to spend a good deal of time and effort on chapters 3 and 4 because there is no separate Compiler Design course taught at Skidmore. I think this material is interesting and informative and relates directly to Programming Languages.

A more complex grammar Let's take a look at the handout for the mini-pascal language. Let's first randomly generate a valid sentence (program) or two given this description. Then let's in our mind sort of create a parser from this EBNF description and use that to determine if some programs are syntactically correct. Michael Eckmann - Skidmore College - CS Fall 2008

Limitations of CFG and EBNF Do you think that the EBNF for mini-pascal is the complete description for the syntax of the language? Is anything missing? --- think of some syntax errors that you are used to seeing in your favorite language. Michael Eckmann - Skidmore College - CS Fall 2008

Attribute Grammars Hence the creation of attribute grammars. An attribute grammar is an extension to a CFG. There are some rules of programming languages that cannot be specified in BNF (or by a CFG for that matter.)‏ e.g. All variables must be declared before they are used. Also, there are things that are possible, but just too hairy to specify using CFG's, (e.g. Type compatibility) so Attribute Grammars are used. These kinds of things are termed “static semantics.” This is a bit of a misnomer because they are really still syntax rules not semantics. Michael Eckmann - Skidmore College - CS Fall 2008

Attribute Grammars Michael Eckmann - Skidmore College - CS Fall 2008 An attribute grammar is a CFG (S, N, T, P) with the following additions: –For each grammar symbol x there is a set A(x) of attribute values –Each production (rule) has a set of functions that define certain attributes of the nonterminals in the production –Each production has a (possibly empty) set of predicates to check for attribute consistency Proposed by Knuth in In practice (e.g. Actual compilers) attribute grammars are not generally used in a formal way, but the concepts are most definitely incorporated in compilers.

Attribute Grammars Michael Eckmann - Skidmore College - CS Fall 2008 The example on page 138 shows the use of an attribute grammar to enhance the BNF of an assignment statement with rules that specify the allowable types (int / real) that can be assigned to each other. e.g. A real (float) cannot be assigned to a variable whose type is int and an int cannot be assigned to a real. Also, the example shows how one can determine the resulting type of an expression.

Attribute Grammars Michael Eckmann - Skidmore College - CS Fall 2008 I'm not concerned with following the example in the text very closely and knowing all the ins and outs of attribute grammars, but what I feel is important is the general concepts involved and the intended purpose of them. Attribute grammars are generally not used in practice for a few reasons. Can you guess them?

Attribute Grammars Michael Eckmann - Skidmore College - CS Fall 2008 Attribute grammars are generally not used in practice for a few reasons. Can you guess them? –Size and complexity of the grammar will be high for a typical modern programming language –The many attributes and rules that need to be added cause the grammar to be difficult to read and write, formally –The attribute values during parsing would be costly to evaluate (the way it is described in the text.)‏ So, in practice less formal ways are used to check for “static semantics” at compile-time but the ideas are the same.

Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Now that we know how to specify the syntax of a language, we move to specifying the semantics of a language. The text uses the phrase “dynamic semantics” and semantics interchangeably. Semantics is harder to describe than syntax. Programmers need to know the semantics of the syntax and so do compiler writers.

Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Both programmers and compiler writers often rely on English descriptions of the language. Why might you think? And are there any problems with this?

Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Our text describes 3 different ways to formally describe the semantics of a programming language. –Operational semantics –Axiomatic semantics –Denotational semantics

Operational Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Operational semantics – describe the meaning of a program (or part of a program) by specifying it with more easily understood constructs (usually in a lower level language.)‏ Operational semantics is the least formal among the three we ways we'll talk about to describe semantics. The other two, Axiomatic and Denotational are based on logic and mathematics.

Operational Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Operational semantics, if used informally, are good to communicate the meaning of constructs to a programmer (e.g. in programming manuals).

Operational Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Example: –To describe a while loop in Java using operational semantics one might do the following: while (expr)‏ { // statements } So, assuming the programmer can understand all the code in the “lower level” language in the operational semantics description of the code, then he/she can understand how the while loop construct works. Operational semantics for a while loop: label: if (expr)‏ { // statements goto label; }

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Based on formal logic (predicate calculus)‏ –Original purpose was for formal program verification --- that is, to prove the correctness of programs –In a proof, logical expressions containing constraints on variables appear before and after each statement of a program. –The logic expressions are called assertions or predicates.

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 An assertion before a statement is a precondition and states the relationships and constraints among variables that are true at that point in execution An assertion after a statement is a postcondition A weakest precondition is the least restrictive precondition that will guarantee the postcondition

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Notation for specifying the Axiomatic semantics of a statement: {P} statement {Q} {P} is precondition, {Q} is postcondition Example: a = b + 1 {a > 1} –Read this as a must be greater than one after this statement executes. So, –One possible precondition: {b > 4} –What's the weakest precondition here?

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 For: a = b + 1 {a > 1} –The weakest precondition is: {b > 0} –Because a > 1 implies that b + 1 has to be > 1 which implies that b must be > 0.

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Jumping ahead to the big picture, we might be able to gleam from the example that to prove program correctness, one might have a post condition for the entire program and then work backwards through the program until we get to the beginning and generate a weakest precondition for the entire program. If that is within the program specifications, then it is correct. What does that mean? What would we do as we went backwards through the program?

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 When multiple statements or more complex structures are involved, we need what are called inference rules. For a sequence of statements S1;S2: {P1} S1 {P2} {P2} S2 {P3} The inference rule is: And it is read like: If {P1}S1 {P2} is true and {P2} S2 {P3} is true, then we infer that {P1} S1,S2 {P3} is true.

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 It gets more complex to determine the precondition for while loops and other structures that might iterate different numbers of times depending on values of variables.

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Given a logical statement (with a precondition and a postcondition) that is true, the postcondition can be weakened and/or the precondition can be strengthened and it will remain true. (see page 146, “The rule of consequence”)‏ What does is mean to weaken or strengthen? Example: { a > 0 and b > 0 } - weaken it - strengthen it - change it in a way that is neither weakening nor strengthening it

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Given a logical statement (with a precondition and a postcondition) that is true, the postcondition can be weakened and/or the precondition can be strengthened and it will remain true. (see page 146, “The rule of consequence”)‏ What does is mean to weaken or strengthen? Example: { a > 0 and b > 0 } - weaken it { a > -5 and b > -5 } - strengthen it { a > 10 and b > 0 } - change it in a way that is neither weakening nor strengthening it { a 0 }

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Developing axioms or inference rules for all of the statements in a language is difficult It is a good tool for correctness proofs but there are limits to this (or any) approach that tries to prove correctness. It is an excellent framework for reasoning about programs It is not very useful for language users and compiler writers

Axiomatic Semantics Michael Eckmann - Skidmore College - CS Fall 2008 Before moving on to Denotational Semantics let's try problem 20 a) on page 165