Semantics Overview • Syntax is about “form” and semantics about “meaning” – Boundary between syntax & semantics is not always clear • First we’ll motivate why semantics matters. • Then we’ll look at issues close to the syntax end, what some calls “static semantics”, and the technique of attribute grammars. • Then we’ll sketch three approaches to defining “deeper” semantics (1) Operational semantics (2) Axiomatic semantics (3) Denotational semantics CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Motivation Program Verification • Capturing what a program in some programming • Program verification can be done for simple programming language means is very difficult languages and small or moderately sized programs • We can’t really do it in any practical sense • It requires a formal specification for what the program – For most work-a-day programming languages (e.g., C, C++, should do – e.g., what it’s inputs will be and what actions Java, Perl, C#). it will take or output it will generate given the inputs – For large programs • That’s a hard task in itself! • So, why is worth trying? • There are applications where it is worth it to (1) use a • One reason: program verification! simplified programming language, (2) work out formal specs for a program, (3) capture the semantics of the • Program Verification is the process of formally simplified PL and (4) do the hard work of putting it all proving that the computer program does exactly what together and proving program correctness. is stated in the program specification it was written to • What are they? realize CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Program Verification Double Int kills Ariane 5 • There are applications where it is worth it to (1) use a simplified programming language, (2) work out formal • It took the European Space Agency specs for a program, (3) capture the semantics of the 10 years and $7B to produce simplified PL and (4) do the hard work of putting it all Ariane 5, a giant rocket capable of together and proving program correctness. Like… hurling a pair of three-ton satellites • Security and encryption into orbit with each launch and • Financial transactions intended to give Europe supremacy in the commercial space business • Applications on which lives depend (e.g., healthcare, aviation) • All it took to explode the rocket less • Expensive, one-shot, un-repairable applications (e.g., than a minute into its maiden voyage Martian rover) in 1996 was a small computer program trying to • Hardware design (e.g. Pentium chip) stuff a 64-bit number into a 16-bit space. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Intel Pentium Bug So… • In the mid 90’s a bug was found in • While automatic program verification is a the floating point hardware in Intel’s long range goal … latest Pentium microprocessor • Which might be restricted to applications • Unfortunately, the bug was only found where the extra cost is justified after many had been made and sold • We should try to design programming • The bug was subtle, effecting only the ninth languages that help, rather than hinder, our decimal place of some computations ability to make progress in this area. • But users cared • We should continue research on the semantics of programming languages … • Intel had to recall the chips, taking a $500M • And the ability to prove program correctness write-off CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Semantics Static Semantics • Static semantics covers some language features • Next we’ll look at issues close to the syntax difficult or impossible to handle in a BNF/CFG end, what some calls “static semantics”, • It’s also a mechanism for building a parser that and the technique of attribute grammars. produces an abstract syntax tree of its input • Then we’ll sketch three approaches to • Attribute grammars are one common technique defining “deeper” semantics • Categories attribute grammars can handle: (1) Operational semantics - Context-free but cumbersome (e.g., type (2) Axiomatic semantics checking) (3) Denotational semantics - Non-context-free (e.g., variables must be declared before they are used) CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Parse tree vs. abstract syntax tree Attribute Grammars • Parse trees follow a grammar and usually have lots of useless • Attribute Grammars (AGs) were nodes developed by Donald Knuth in ~1968 • An abstract syntax tree (AST) eliminates useless structural nodes • And uses just those nodes that correspond to constructs in the • Motivation: higher level programming language • CFGs cannot describe all of the syntax • It’s much easier to interpret an AST or generate code from it of programming languages e! +! +! • Additions to CFGs to annotate the parse e!! +! intint!! e+!! int! e+!! 3! tree with some “semantic” info • Primary value of AGs: e! +! int! 3! inte!! int! 3! 1! 2! • Static semantics specification int! 2! 1! 2! • Compiler design (static semantics checking) 1! parse tree an AST another AST CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Attribute Grammar Example Attribute Grammars A Grammar is formally defined by specifying four components. • Ada has this rule to describe procedure definitions: • S is the start symbol Def: An attribute grammar is a CFG• N is a set G= of non-terminal symbols <proc> => procedure <prName> <prBody> end <prName> ; • T is a set of terminal symbols (S,N,T,P) • P is a set of productions or rules • But the name after “procedure” has to be the same as the name after “end” with the following additions: – For each grammar symbol x there is a set A(x) of • This is not possible to capture in a CFG (in practice) because there are too many names attribute values – Each rule has a set of functions that define certain • Solution: annotate parse tree nodes with attributes and attributes of the non-terminals in the rule add a “semantic” rules or constraints to the syntactic rule in the grammar. – Each rule has a (possibly empty) set of predicates rule<proc> => procedure <prName>[1] <prBody> end <prName>[2] ; to check for attribute consistency constraint<prName][1].string == <prName>[2].string CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Attribute Grammars Attribute Grammars Example: expressions of the form id + id • Let X0 => X1 ... Xn be a grammar rule •id 's can be either int_type or real_type • Functions of the form S(X0) = f(A(X1),...A(Xn) • types of the two id's must be the same define synthesized attributes • type of the expression must match its expected type - i.e., attribute defined by a nodes children BNF: <expr> -> <var> + <var> • Functions of the form I(Xj) = f(A(X0),…A(Xn)) for i <= j <= n define inherited attributes <var> -> id - i.e., attribute defined by parent and siblings Attributes: • Initially, there are intrinsic attributes on the actual_type - synthesized for <var> and <expr> leaves expected_type - inherited for <expr> - i.e., attribute predefined CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Attribute Grammars Attribute Grammars (continued) Attribute Grammar: How are attribute values computed? 1. Syntax rule: <expr> -> <var>[1] + <var>[2] • If all attributes were inherited, the tree Semantic rules: could be decorated in top-down order <expr>.actual_type ← <var>[1].actual_type Predicate: ! • If all attributes were synthesized, the tree <var>[1].actual_type == <var>[2].actual_type <expr>.expected_type == <expr>.actual_type could be decorated in bottom-up order Compilers usually maintain a 2. Syntax rule: <var> -> id “symbol table” where they • In many cases, both kinds of attributes are record the names of proce- dures and variables along Semantic rule:! used, and it is some combination of top- with type type information. <var>.actual_type ← Looking up this information down and bottom-up that must be used in the symbol table is a com- lookup_type (id, <var>) mon operation. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Attribute Grammars (continued) Attribute Grammar Summary • AGs are a practical extension to CFGs that allow us to Suppose we process the expression A+B annotate the parse tree with information needed for using rule <expr> -> <var>[1] + <var>[2] semantic processing <expr>.expected_type ← inherited from parent – E.g., interpretation or compilation <var>[1].actual_type ← lookup (A, <var>[1]) • We call the annotated tree an abstract syntax tree <var>[2].actual_type ← lookup (B, <var>[2]) – It no longer just reflects the derivation <var>[1].actual_type == <var>[2].actual_type • AGs can move information from anywhere in the abstract syntax tree to anywhere else, in a controlled <expr>.actual_type ← <var>[1].actual_type way <expr>.actual_type == <expr>.expected_type – Needed for no-local syntactic dependencies (e.g., Ada example) and for semantics CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Static vs. Dynamic Semantics Dynamic Semantics • Attribute grammars are an example of static semantics (e.g., type checking) that don’t • No single widely acceptable notation or reason about how things change when a formalism for describing semantics. program is executed • But understanding what a program means often • Here are three approaches at which we’ll requires reasoning about how, for example, a briefly look: variable’s value changes – Operational semantics • Dynamic semantics tries to capture this – Axiomatic semantics – Denotational semantics – E.g., proving that an array index will never be out of its intended range CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc.