CS 330 Programming Languages 09 / 19 / 2006 Instructor: Michael Eckmann.

CS 330Programming Languages

09 / 19 / 2006

Instructor: Michael Eckmann

Michael Eckmann - Skidmore College - CS 330 - Fall 2006

Today’s Topics• Homework from Chapter 3 to be assigned this afternoon

--- check your email.• Describing Syntax & Semantics (Chapter 3)

– Short review– Mini pascal grammar– Attribute grammars to allow for specifying static

semantics– Semantics

• Operational• Axiomatics• Denotational


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?• What is EBNF and what can you say about the

languages it can generate vs. BNF (or CFG)?


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 seperate Compiler Design course taught at Skidmore.

• I think this material is interesting and informative and I hope you feel the same.

A more complex grammar• Let's take a look at the handout for the mini-pascal

language.• Let's today try to generate a very short valid sentence

(program) given this description.• Then let's in our mind sort of create a parser from this

EBNF description and use that to determine if a program is syntactically correct.

• Notice how closely related grammars (aka generators) are to parsers (aka recognizers.)


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.


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 that cannot be specified using CFGs are termed “static semantics.” This is a bit of a misnomer because we still consider them to be syntax rules not semantics.


Attribute Grammars


• 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 rule– Each rule has a (possibly empty) set of predicates to

check for attribute consistency (answers “does it have valid static semantics?”)

• Proposed by Knuth in 1968.

Attribute Grammars


• The example on page 145 shows the use of an attribute grammar to enhance the BNF of an assignment statement with rules that specify the allowable types that can be assigned to each other.

• e.g. A float (real) cannot be assigned to a variable whose type is int. But the opposite is allowed.

• Also, the example shows how one can determine the resulting type of an expression.

Attribute Grammars


• I'm not concerned with us 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


• 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.

Practice Problems


• Before moving on to our discussion of formally describing the Semantics of a language, let's take a look at problem 8, 10 and 11 on page 171.

Semantics


• 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 interchangably.

• Semantics is harder to describe than syntax.• Programmers need to know the sematics of the

syntax and so do compiler writers.

Semantics


• Both programmers and compiler writers often rely on English descriptions of the language.

• Why might you think? • Are there any problems with this?

Semantics


• Our text describes 3 different ways to formally describe the semantics of a programming language.– Operational semantics– Axiomatic semantics– Denotational semantics

Operational Semantics


• First create a converter from the language you wish to describe semantically to some lower level language (e.g. assembly). Then, execute the statements of the lower level language on a real or simulated machine. Examine the behavior of the statements by looking at the state of the machine before and after.

• The state of a machine includes the values of CPU registers, values of memory locations, etc.

• The changes of the state determine the meaning of the language statements.



• The conversions that the converter from the language to a lower level language uses can be used to describe the semantics of the different language constructs to a programmer as is often done in manuals.

• This way is good if used informally as for programming manuals but extremely complex formally.



• 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;

}



• Operational semantics can be summed up as:

• The statements in one language (the one you're trying to describe semantically) are described in terms of a lower-level programming language. (page 150 in Sebesta).

• Operational semantics uses lower level programming languages not mathematics.

• The other two methods (which are about to be described) are more formal and based on logic and mathematics.

Axiomatic Semantics


• Based on formal logic (predicate calculus)– Original purpose was for formal program verification

--- that is, to prove the correctness of programs– We define axioms or inference rules for each

statement type in the language (to allow transformations of expressions to other expressions)

– The expressions are called assertions or predicates

Axiomatic Semantics


• 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 following a statement is a postcondition

• A weakest precondition is the least restrictive precondition that will guarantee the postcondition

Axiomatic Semantics


• 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


• 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


• 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 specs, then it is correct.

• What does that mean?• What would we do as we went backwards through

the program?

Axiomatic Semantics


• 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.

P1 S1 P2 , P2 S2 P3

P1 S1; S2 P3

Axiomatic Semantics


• 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


• Developing axioms or inference rules for all of the statements in a language is difficult

• It is a good tool for correctness proofs but proving that an arbitrary program is correct is incomputable, so obviously 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


• Before moving on to Denotational Semantics let's try problem 20 a) on page 173

Denotational Semantics


• This is the most widely known and rigorous method for describing the semantics (meaning) of programs.

• The book only touches on how it works and we will do the same.



• The process of building a denotational spec for a language (not necessarily easy):– Define a mathematical object for each language

entity– Define a function that maps instances of the

language entities onto instances of the corresponding mathematical objects



• Example:– The following (next slide) denotational semantics

description maps decimal numbers as strings of symbols into numeric values

– Mdec is the semantic function and it is used to map the syntactic objects to the decimal numbers



<dec_num> 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | <dec_num> (0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9)Mdec- a function that maps from the syntactic elements to their meaning

Mdec('0') = 0, Mdec ('1') = 1, …, Mdec ('9') = 9

Mdec (<dec_num> '0') = 10 * Mdec (<dec_num>)

Mdec (<dec_num> '1’) = 10 * Mdec (<dec_num>) + 1…

Mdec (<dec_num> '9') = 10 * Mdec (<dec_num>) + 9

CS 330 Programming Languages 09 / 19 / 2006 Instructor: Michael Eckmann.

Documents

Transcript of CS 330 Programming Languages 09 / 19 / 2006 Instructor: Michael Eckmann.