Semantics Overview • Syntax is about form and semantics 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 (e.g., static semantics) and attribute grammars • Finally 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 Motivation: Some Reasons • Capturing what a program in some • How to convey to the programming language programming language means is very difficult compiler/interpreter writer what she should do? • We can’t really do it in any practical sense – Natural language may be too ambiguous – For most work-a-day programming • How to know that the compiler/interpreter did languages (e.g., C, C++, Java, Perl, C#, the right thing when it executed our code? Python) – We can’t answer this w/o a very solid idea of what – For large programs the right thing is • So, why is worth trying? • How to be sure that the program satisfies its specification? – Maybe we can do this automatically if we know what the program means CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc. Program Verification Program Verification • Program verification is the process of formally proving that the computer program does exactly • There are applications where it is worth it to what is stated in the program’s specification (1) use a simplified programming language • Program verification can be done for simple (2) work out formal specs for a program programming languages and small or moderately sized programs (3) capture the semantics of the simplified PL and (4) do the hard work of putting it all together and • It requires a formal specification for what the proving program correctness. program should do – e.g., its inputs and the actions to take or output to generate given the inputs • What are they? • That’s a hard task in itself! 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, and • It’s also a mechanism for building a parser that 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 many nodes that • Attribute Grammars (AGs) were developed are artifacts of how the grammar was written by Donald Knuth in ~1968 • An abstract syntax tree (AST) eliminates useless structural nodes • It uses nodes corresponding to constructs in the programming • Motivation: language and is easier to interpret or generate code from it • CFGs can’t describe all of the syntax of • Consider 1 + 2 + 3: programming languages e! +! +! • Additions to CFGs to annotate the parse e!! +! intint!! e+!! int! e+!! 3! tree with some “semantic” info e! +! int! 3! inte!! int! 3! 1! 2! • Primary value of AGs: int! 2! 1! 2! • Static semantics specification 1! • Compiler design (static semantics checking) 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 of non-terminal symbols <proc> => procedure <prName> <prBody> end <prName> ; • T is a set of terminal symbols G=(S,N,T,P) • P is a set of productions or rules • The name after procedure must 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 add a “semantic” rules or constraints to the syntactic attributes of the non-terminals in the rule rule in the grammar – Each rule has a (possibly empty) set of predicates to check for attribute consistency rule: <proc> => procedure <prName>[1] <prBody> end <prName>[2] ; 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 Suppose we process the expression A+B • AGs are a practical extension to CFGs that allow us to using rule <expr> -> <var>[1] + <var>[2] annotate the parse tree with information needed for semantic processing <expr>.expected_type ← inherited from parent – e.g., interpretation or compilation <var>[1].actual_type ← lookup (A, <var>[1]) <var>[2].actual_type ← lookup (B, <var>[2]) • We call the annotated tree an abstract syntax tree <var>[1].actual_type == <var>[2].actual_type – It no longer just reflects the derivation <expr>.actual_type ← <var>[1].actual_type • AGs can move information from anywhere in abstract <expr>.actual_type == <expr>.expected_type syntax tree to anywhere else in a controlled way – Needed for no-local syntactic dependencies (e.g., Ada example) and for semantics CMSC 331, Some material © 1998 by Addison Wesley Longman, Inc.