Chapter 3
Download
1 / 139

Chapter 3 - PowerPoint PPT Presentation


  • 834 Views
  • Updated On :

Chapter 3. Describing Syntax and Semantics. Syntax and Semantics. Syntax of a programming language : the form of its expressions, statements, and program units Semantics: the meaning of the expressions, statements, and program units Syntax and semantics provide a language’s definition.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Chapter 3' - Jeffrey


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Chapter 3 l.jpg

Chapter 3

Describing Syntax and Semantics


Syntax and semantics l.jpg
Syntax and Semantics

  • Syntax of a programming language: the form of its expressions, statements, and program units

  • Semantics: the meaning of the expressions, statements, and program units

    • Syntax and semantics provide a language’s definition


An example of syntax and semantic l.jpg
An Example of Syntax and Semantic

  • The syntax of a Java while statement:

    while (<boolean_expr>) <statement>

  • The semantic of the above statement:

    when the current value of the Boolean expression is true, the embedded statement is executed; otherwise, control continues after the while construct. Then control implicitly returns to the Boolean expression to repeat the process


Description easiness l.jpg
Description Easiness

  • Describing syntax is easier than describing semantics

    • partly because a concise and universally accepted notation is available for syntax description

    • but none has yet been developed for semantics


Definitions of languages and sentences l.jpg
Definitions of Languages and Sentences

  • A language, whether natural (such as English) or artificial (such as Java), is a set of strings of characters from some alphabet.

  • The strings of a language are called sentences or statements.


Syntax rules of a language l.jpg
Syntax Rules of a Language

  • The syntax rules of a language specify which strings of characters from the language’s alphabet are in the language.


Definitions of lexemes l.jpg
Definitions of Lexemes

  • The lexeme of a programming language include its

    • numeric literals

    • operators

    • and special words, among others.

      • (e.g., *, sum, begin)

  • Alexemeis the lowest level syntactic unit of a language:

    • for simplicity’s sake, formal descriptions of the syntax of programming languages often do not include description of them

    • However the description of lexemes can be given by a lexical specification which is usually separate from the syntactic description of the language.


An informal definition of a program l.jpg
An Informal Definition of a Program

  • A program could be thought as strings of lexemes rather than of characters.


Lexeme group l.jpg
Lexeme Group

  • Lexemes are partitioned into groups.

    • For example, in a programming language, the names of variables, methods, classes, and so forth form a group called identifier.

  • Each of these groups is represented by a name, or token.


Definitions of tokens l.jpg
Definitions of Tokens

  • A tokenis a category of lexemes (e.g., identifier)

    • a token may have only a single lexeme

      • For example, the token for the arithmetic operator symbol +, which may have the name plus_op, has just one possible lexeme.

    • a lexeme of a token can also be called an instance of the token


Example of tokens l.jpg
Example of Tokens

  • Identifier is a token that can have lexemes, or instances, such as sum and total.


Lexemes and tokens csusb lee l.jpg
Lexemes and Tokens [csusb], [Lee]

  • Lexemes: a string of characters in a language that is treated as a single unit in the syntax and semantics.

    • For example identifiers, numbers, and operators are often lexemes

  • In a programming language, there are a very large number of lexemes, perhaps even an infinite number; however, there are only a small number of tokens.


Examples of lexemes and tokens lee l.jpg
Examples of Lexemes and Tokens [Lee]

  • while (y  >=  t) y  =  y - 3 ; will be represented by the set of pairs:

a token with only one lexeme


Ways to define a language l.jpg
Ways to Define a Language

  • In general, languages can be formally defined in two distinct ways: by recognition and by generation.

    • P.S.: Although neither provides a definition that is practical by itself for people trying to lean or even use a programming language.


Language recognizer l.jpg
Language Recognizer

  • a recognition device that

    • reads strings of characters from the alphabet of a language and

    • decides whether an input string was or was not in the language

  • Example: syntax analysis part of a compiler is a recognizer for the language the compiler translates

  • are not used to enumerate all of the sentences of a language


Language generators l.jpg
Language Generators

  • a device that generates the sentences of a language.

  • We can think of the generator as having a button that produces a sentence of the language every time it is pushed

    • However, the particular sentence that is produced by a generator when its button is pushed is unpredictable

  • One can determine if the syntax of a particular sentence is correct by comparing it to the structure of the generator

    • People learn a language from examples of its sentences


Grammars wiki l.jpg
Grammars [wiki]

  • In computer science and linguistics, a formal grammar, or sometimes simply grammar, is a precise description of a formal language — that is, of a set of strings.

  • Commonly used to describe the syntax of programming languages


Formal grammars wiki l.jpg
Formal Grammars [wiki]

  • A formal grammar, or sometimes simply grammar, consists of:

    • a finite set of terminal symbols;

    • a finite set of nonterminal symbols;

    • a finite set of production rules with a left- and a right-hand side consisting of a sequence of these symbols

    • a start symbol.


Grammar example wiki l.jpg
Grammar Example [wiki]

  • Nonterminals are usually represented by uppercase letters

  • terminals by lowercase letters

  • the start symbol by S.

  • For example, the grammar with

    • terminals {a,b},

    • nonterminals {S,A,B},

    • production rules

      • SABS

      • S ε (where ε is the empty string)

      • BAAB

      • BS b

      • Bb bb

      • Abab

      • Aa aa

    • start symbol S,

    • defines the language of all words of the form anbn (i.e. n copies of a followed by n copies of b).


Formal grammars and formal languages wiki l.jpg
Formal Grammars and Formal Languages [wiki]

  • A formal grammar defines (or generates) a formal language, which is a (possibly infinite) set of sequences of symbols that may be constructed by applying production rules to a sequence of symbols which initially contains just the start symbol.


Grammar classes wiki l.jpg
Grammar Classes [wiki]

  • In the mid-1950s, according to the format of the production rules, Chomsky described four classes of generative devices or grammars that define four classes of languages:

    • recursively enumerable

    • context-sensitive

    • context-free

    • regular


Application of context free and regular grammars l.jpg
Application of Context-free and Regular Grammars

  • The tokens of programming languages can be described by regular grammars.

  • Whole programming languages, with minor exceptions, can be described by context-free grammars.


Review of context free grammars l.jpg
Review of Context-Free Grammars

  • Context-Free Grammars

    • Developed by Noam Chomsky in the mid-1950s

    • Language generators, meant to describe the syntax of natural languages

    • Define a class of languages called context-free languages


Terminology metalanguage l.jpg
Terminology - metalanguage

  • A metalanguage is a language that is used to describe another language.


Backus naur form bnf l.jpg
Backus-Naur Form (BNF)

  • Backus-Naur Form (1959)

    • Invented by John Backus to describe Algol 58

    • Most widely known method for describing programming language syntax

    • BNF is equivalent to context-free grammars

    • BNF is a metalanguage used to describe another language


Extended bnf l.jpg
Extended BNF

  • Extended BNF

    • Improves readability and writability of BNF


Bnf abstraction l.jpg
BNF Abstraction

  • BNF uses abstractions for syntactic structures

    • For example, a simple Javaassignment statement might be represented by the abstraction <assign>.

      • (pointed brackets are often used to delimit names of abstractions)

  • In fact, tokens are also abstractions.


Synonym l.jpg
Synonym

Nonterminals symbols (nonterminals)

BNF abstractions

Terminals

Lexemes and tokens


Bnf rules l.jpg
BNF Rules

  • A rule, also called a production, has a left-hand side (LHS) and a right-hand side (RHS), and consists of terminal and nonterminal symbols.

  • An abstraction is defined by a rule.

    • Examples of BNF rules:

      <ident_list> → identifier | identifier,<ident_list>

      <if_stmt> → if <logic_expr> then <stmt>

  • A grammar is a finite nonempty set of rules.


Multiple definitions of a nonterminal l.jpg
Multiple Definitions of a Nonterminal

  • Nonterminal symbols can have two or more distinct definitions, representing two or more possible syntactic forms in the language.

  • Multiple definitions can be written as a single rule, with different definitions separated by the symbol |.


Example of multiple definitions of a nonterminal l.jpg
Example of Multiple Definitions of a Nonterminal

  • For example, an Adaif statement can be described with the rules:

    <if_stmt> if <logic_expr> then <stmt>

    <if_stmt> if <logic_expr> then <stmt> else <stmt>

    Or with the rule

    <if_stmt> if <logic_expr> then <stmt>

    | if <logic_expr> then <stmt> else <stmt>


A rule example l.jpg
A Rule Example

<assign>  <var> = <expression>

  • The above rule specifies that the abstraction <assign> is defined as an instance of the of the abstraction <var>, followed by the lexeme =, followed by an instance of the abstraction <expression>.

  • One example whose syntactic structure is described by the rule is:

    total = subtotal1 + subtotal2


Expressive capability of bnf l.jpg
Expressive Capability of BNF

  • Although BNF is simple, it is sufficiently powerful to describe nearly all of the syntax of programming languages.

  • BNF can describe

    • Lists of similar construct

    • The order in which different constructs must appear

    • Nested structures to any depth

    • Imply operator precedence

    • Imply operator associativity


Variable length lists and recursive rules l.jpg
Variable-length Lists and Recursive Rules

  • Variable-length lists in mathematics are often written using an ellipsis (…).

    • 1,2, … is an example.

  • BNF does not include the ellipsis, it uses recursive rules as an alternative.

    • A rule is recursive if its LHS appears in its RHS.


Example of a recursive rule l.jpg
Example of a Recursive Rule

  • Syntactic lists are described using recursion

    <ident_list>  ident

    | ident, <ident_list>

    the above rule defines <ident_list> as either a single token (identifier) or an identifier followed by a comma followed by another instance of <ident_list>.


Grammar and derivation l.jpg
Grammar and Derivation

  • A grammar is a generative device for defining languages.

  • The sentences of a languages are created through deviations.

  • A derivation is a repeated application of rules, starting with a special nonterminal of the grammar called the start symbol and ending with a sentence (all terminal symbols)


An example of start symbols l.jpg
An Example of Start Symbols

  • In a grammar for a complete programming language, the start symbol represents a complete program and is usually named <program>.


Example 3 1 an example grammar l.jpg
Example 3.1 - An Example Grammar

  • What follows is a grammar for a small language.

P.S.:<program> is the start symbol.


Language defined by the grammar in example 3 1 l.jpg
Language Defined by the Grammar in Example 3.1

  • The language in Example 3.1 has only one statement form: assignment.

  • A program consists of the special word begin, followed by a list of statements separated by semicolons, followed by the special word end.

  • An expression is either a single variable, or two variables separated by either a + or – operator.

  • The only variable names in this language are A, B, and C.


An example derivation l.jpg
An Example Derivation

<program>=> begin <stmt_list> end

=> begin <stmt> ; <stmt_list> end

=> begin <var> = <expression>; <stmt_list> end

=> begin A = <expression> ; <stmt_list> end

=> begin A = <var> + < var > ; <stmt_list> end

=> begin A = B + <var> ; <stmt_list> end

=> begin A = B + C ; <stmtjist> end

=> begin A = B + C ; <stmt> end

=> begin A = B + C ; <var> := <expression> end

=> begin A=B + C;B=<expression> end

=> begin A = B + C ;B= <var> end

=> begin A = B + C ; B = C end

derive


Sentential form l.jpg
Sentential Form

  • In the previous slide, each successive string in the sequence is derived from the previous string by replacing one of the nonterminals with one of that nonterminal’s definitions.

  • Every string of symbols in the derivation is a sentential form.


Order of derivation l.jpg
Order of Derivation

  • A leftmost derivation is one in which the leftmost nonterminal in each sentential form is the one that is expanded.

    • The derivation continues until the sentential form contains no nonterminals.

    • The sentential form, consisting of only terminals, or lexemes, is the generated sentence.

  • Rightmost derivation

  • A derivation may be neither leftmost nor rightmost.

    • However the derivation order has no effect on the language generated by a grammar.


Using the grammar in example 3 1 to generate different sentences l.jpg
Using the Grammar in Example 3.1 to Generate Different Sentences

  • By choosing alternative RHSs of rules with which to replace nonterminals in the derivation, different sentences in the language can be generated.

  • By exhaustively choosing all combinations of choices, the entire language can be generated.

  • This language, like most others, is infinite, so one cannot generate all the sentences in the language in finite time.


Example 3 2 l.jpg
Example 3.2 Sentences

  • This grammar describes assignment statements whose right sides are arithmetic expressions with multiplication and addition operators and parentheses.


The leftmost derivation for a b a c l.jpg
The Leftmost Derivation for SentencesA=B*(A+C)

<assign> => <id> = <expr>

=> A = <expr>

=> A = <id> * <expr>

=> A = B * <expr>

=> A = B * (< expr >)

=> A = B * (<id> + <expr>)

=> A = B * (A + <expr>)

=> A = B * (A + <id>)

=> A = B * (A + C)


Parse trees l.jpg
Parse Trees Sentences

  • One of the most attractive features of grammars is that they naturally describe the hierarchical syntactic structure of the sentences of the languages they define.

  • These hierarchical structures are called parse trees.


Figure 3 1 a parse tree for a b a c l.jpg
Figure 3.1 - a Parse Tree for A=B*(A+C) Sentences

  • The right side figure is a parse tree.

  • This parse tree shows the structure of the assignment statement derived previously.


A derivation and its corresponding parse tree l.jpg
A Derivation and Its Corresponding Parse Tree Sentences

<assign> => <id> = <expr>

=> A = <expr>

=> A=<id>*<expr>

=> A = B * <expr>

=> A = B * (< expr >)

=> A = B* ( <id> + <expr> )

=> A = B* (A+<expr> )

=> A = B*<A+<id> )

=> A=B*(A+C)


Mapping between a grammar and its corresponding parse tree l.jpg
Mapping between a Grammar and Its Corresponding Parse Tree Sentences

  • Every internal node of a parse tree is labeled with a nonterminal symbol.

  • Every leaf is labeled with a terminal symbol.

  • Every subtree of a parse tree describes one instance of an abstraction in the statement.


Ambiguity in grammars l.jpg
Ambiguity in Grammars Sentences

  • A grammar is ambiguous if and only if it generates a sentential form that has two or more distinct parse trees.




Causes of ambiguity l.jpg
Causes of Ambiguity Statements

  • Rather than allowing the parse tree of an expression to grow only on the right, this grammar allows growth on both the left and the right.


Drawbacks of ambiguous grammars l.jpg
Drawbacks of Ambiguous Grammars Statements

  • Syntactic ambiguity of language structures is a problem because compilers often base the semantics of those structures on their syntactic form.

  • In particular, the compiler decides what code to generate for a statement by examining its parse tree.

  • If a language structure has more than one parse tree, then the meaning of the structure cannot be determined uniquely.


Using nonprogrammatical information to improve ambiguous grammars l.jpg
Using Nonprogrammatical Information to Improve Ambiguous Grammars

  • Some parsing algorithms can be based on ambiguous grammars.

    • When such a parser encounters an ambiguous construct, it uses nongrammatical information provided by the designer to construct the correct parse tree.

  • In many case, an ambiguous grammar can be rewritten to be unambiguous, but still generate the desired language.


Operator precedence l.jpg
Operator Precedence Grammars

  • When an expression includes two different operators, for example, x + y * z, one obvious semantic issue is the order of evaluation of the two operators (is it add and then multiply (i.e. (x + y) * z), or vice versa (i.e. x + (y * z)) in the expression above).


Order of evaluation of operators l.jpg
Order of Evaluation of Operators Grammars

  • The previous semantic question can be solved by assigning different precedence levels to operators.

    • For example, if * has been assigned higher precedence than + (by the language designer), multiplication will be done first, regardless of the order of appearance of the two operators in the expression.


Parse trees heights represent precedence levels l.jpg
Parse Trees Heights Represent Precedence Levels Grammars

  • An operator in an arithmetic expression is generated lower (further to the root) in the parse tree (and therefore must be evaluated first) can be used to indicate that it has precedence over an operator produced higher up in the tree.


Conflicting operator precedence due to a ambiguous grammar l.jpg
Conflicting Grammars Operator Precedence due to a Ambiguous Grammar

  • In the first parse tree of Figure 3.2, for example, the multiplication operator is generated lower in the tree, which could indicate that it has precedence over the addition operator in the expression.

  • The second parse tree, however, indicates just the opposite.


Unusual operator precedence created by the grammar in example 3 2 l.jpg
Unusual Grammars Operator Precedence Created by the Grammar in Example 3.2

  • In the grammar of example 3.2, a parse tree of a sentence with multiple operators, regardless of the particular operators involved, has the rightmost operator in the expression at the lowest point in the parse tree

    • with the other operators in the tree moving progressively higher as one moves to the left in the expression.

      • For example, in the parse tree in Figure 3.1, the plus operator is the rightmost operator in the expression and the lowest in the tree, giving it precedence over the multiplication operator to its left.


Example 3 4 an unambiguous grammar for assignment statements l.jpg
Example 3.4 – An Unambiguous Grammar for Assignment Statements

  • The above grammar specifies a the usual precedence order of the + and * operators, regardless of the order in which the operators appear in an expression.

  • The above grammar generates the same language as the grammars of Examples 3.2 and 3.3.


A derivation of sentence a b c a using the grammar of example 3 4 l.jpg
A Derivation of Sentence StatementsA = B + C * A Using the Grammar of Example 3.4.

<assign> => <id> = <expr>

=> <id> = <expr> + <term>

=> <id> = <expr> + <term> * <factor>

=> <id> = <expr> + <term> * <id>

=> <id> = <expr> + <term> * A

=> <id> = <expr> + <factor> * A

=> <id> = <expr> + <id> * A

=> <id> = <expr> + C * A

=> <id> = <term> + C * A

=> <id> = <factor> + C * A

=> <id> = <id> + C * A

=> <id> = B + C * A

=> A = B + C * A

rightmost derivation


Derivations vs parse trees l.jpg
Derivations vs. Parse Trees Statements

  • The connection between parse trees and derivations is very close: Either can easily be constructed from the other.

  • Every derivation with an unambiguous grammar has a unique parse tree, although that tree can be represented by different derivations.


Another derivation of a b c a using the grammar of example 3 4 l.jpg
Another Derivation of StatementsA = B + C * A Using the Grammar of Example 3.4.

leftmost derivation

<assign> => <id> = <expr>

=> A = <expr>

=> A = <expr> + <term>

=> A = <term > + <term>

=> A = <factor> + <term>

=> A = <id> + <term>

=> A = B + <term>

=> A = B + <term> * <factor>

=> A = B + <factor> * <factor>

=> A = B + <id> * <factor>

=> A = B + C * <factor>

=> A = B + C * A

  • The above derivation is different from the derivation of the same sentence given previously.


Derivations vs parse trees65 l.jpg
Derivations vs. Parse Trees Statements

<assign> => <id> = <expr>

=> <id> = <expr> + <term>

=> <id> = <expr> + <term> * <factor>

=> <id> = <expr> + <term> * <id>

=> <id> = <expr> + <term> * A

=> <id> = <expr> + <factor> * A

=> <id> = <expr> + <id> * A

=> <id> = <expr> + C * A

=> <id> = <term> + C * A

=> <id> = <factor> + C * A

=> <id> = <id>+C*A

=> <id> = B + C*A

=> A = B + C*A

<assign> = > <id> = <expr>

=> A = <expr>

=> A = <expr> + <term>

=> A = <term > + <term>

=> A = <factor> + <term>

=> A= <id> + <term>

=> A = B + <term>

=> A = B + <term> * <factor>

=> A = B + <factor> * <factor>

=> A = B+<id>*<factor>

=> A = B + C* <factor>

=> A = B+C*A

  • Both of the above derivations are represented by the same parse tree as shown in the following slide.

rightmost derivation

leftmost derivation


Figure 3 3 the unique parse tree for a b c a using an unambiguous grammar l.jpg
Figure 3.3 – the Unique Parse Tree for StatementsA = B + C * A Using an Unambiguous Grammar


Sentences derivations and parse trees l.jpg
Sentences, Derivations, and Parse Trees Statements

parse tree 1

derivation 1

sentence a

parse tree 2

derivation 2

See Figure 3.3

unambiguous grammar

parse tree 3

derivation 3

sentence b

derivation 4

parse tree 4

See Figure 3.2

ambiguous grammar


Associativity l.jpg
Associativity Statements

  • When an expression includes two operators that have the same precedence (as * and / usually have), for example A/B*C, a semantic rule is required to specify which should have precedence.

  • This rule is named associativity.


Grammars and associativity l.jpg
Grammars and Associativity Statements

  • A grammar for expressions may correctly imply operator associativity.


Figure 3 4 parse tree for a b c a l.jpg
Figure 3.4 - Parse Tree for StatementsA = B + C + A

  • The parse tree of the right figure shows the left addition operator lower than the right addition operator.

    • This is the correct order if addition is meant to be left associative, which is typical.

    • In most cases, the associativity of addition in a computer is irrelevant.


Left recursive l.jpg
Left Recursive Statements

  • When a grammar rule has its LHS also appearing at the beginning of its RHS, the rule is said to be left recursive.

  • This left recursion specifies left associativity.

  • For example, the left recursion of the rules of the grammar of Example 3.4 causes it to make both addition and multiplication left associative.


Right recursion l.jpg
Right Recursion Statements

  • In most languages that provide it, the exponentiation operator is right associative.

  • To indicate right associativity, right recursion can be used.

  • A grammar rule is right recursive if the LHS appears at the right end of the RHS, Rules such as

    <factor> -> <exp> * * <factor>

    | <exp>

    <exp> -> (< expr >)

    | id

    could be used to describe exponentiation as a right-associative

    operator.


Motivation for an extended bnf l.jpg
Motivation for an Extended StatementsBNF

  • Because of a few minor inconveniences in BNF, it has been extended in several ways.

  • Most extended versions are called Extended BNF, or simply EBNF, even though they are not all exactly the same.

  • The extensions do NOT enhance the descriptive power of BNF; they only increase its readability and writability.


Commonly used extensions in various extended bnf l.jpg
Commonly Used Extensions in Various Extended StatementsBNF

  • Optional parts of RHS are placed in brackets []

    <selection>-> if ( <expression> ) <statement> [else <statement>];

  • Repetitions (0 or more) are placed inside braces {}

    <ident_list> -> < identifier > {, < identifier >}

  • Alternative parts of RHSs are placed inside parentheses and separated via vertical bars

    <term> → <term>(*|/|%) <factor>


Bnf and ebnf versions of an expression grammar l.jpg
BNF Statements and EBNF Versions of an Expression Grammar


Metasymbols l.jpg
Metasymbols Statements

  • Brackets, braces, and parentheses in the EBNF extensions are metasymbols, which means they are notational tools and not terminal symbols in the syntactic entities they help describe.

  • In cases where these metasymbols are also terminal symbols in the language being described, the instances that are terminal symbols can be underlined or quoted.


More extensions in some ebnf l.jpg
More Extensions in Some StatementsEBNF

  • Some versions of EBNF allow a numeric superscript to be attached to the right brace to indicate an upper limit to the number of times the enclosed part can be repeated.

  • Also, some versions use a plus (+) superscript to indicate one or more repetitions.

    • For example,

      <compound> -> begin <stmt> {<stmt>} end

      and

      <compound> -> begin { <stmt> } + end

      are equivalent.


Grammars and recognizers l.jpg
Grammars and Recognizers Statements

  • There was a close relationship between generationandrecognition devices for a given language.

  • In fact, given a context-free grammar, a recognizer for the language generated by the grammar can be algorithmically constructed.

  • A number of software systems allow the quick creation of thesyntax analysis part of a compiler for a new language and are therefore quite valuable.

    • One of the first of these syntax analyzer generators is named yacc.


Attribute grammars l.jpg
Attribute Grammars Statements

  • An attribute grammar is a device used to describe more of the structure of a programming language that can be described with a CFG.

  • An attribute grammar is an extension to a context-free grammar.

  • The extension allows certain language rules to be conveniently described, such as type compatibility.


Limitations of bnf l.jpg
Limitations of StatementsBNF

  • Context-free grammars (CFGs) cannot describe all of the syntax of programming languages.

  • There are some characteristics of the structure of programming languages that are difficult to describe with BNF, and some that are impossible.


Example a language rule difficult to be specified by bnf l.jpg
Example - a Language Rule Difficult to be Specified by StatementsBNF

  • Consider type compatibility rules.

  • In Java, for example, a floating-point value cannot be assigned to an integer type variable, although the opposite is legal.

  • Although this restriction can be specified in BNF, it requires additional nonterminal symbols and rules.

    • If all of the typing rules of Java were specified in BNF, the grammar would become too large to be useful because the size of the grammar determines the size of the parser.


Example a language rule that cannot be specified in bnf l.jpg
Example – a StatementsLanguage Rule That Cannot Be Specified in BNF

  • Consider the common rule that all variables must he declaredbefore they are referenced.

  • It can be proven that this rule cannot be specified in BNF.


Static semantics l.jpg
Static Semantics Statements

  • The example in the previous slide exemplifies the category of language rules called static semantics rules.

  • The static semantics of a language is only indirectly related to the meaning of programs during execution; rather, it has to do with the legal forms of programs (syntax rather than semantics).

  • In many cases, the static semantic rules of a language state its type constraints.

  • Static semantics is so named because the analysis required to check these specifications can be done at compile time.


Motivation for the creation of attribute grammars l.jpg
Motivation for the Creation of Attribute Grammars Statements

  • Because of the problems of describing static semantics with BNF, a variety of more powerful mechanisms has been devised for that task.

    • One such mechanism, attribute grammars, was designed by Knuth (1968a) to describe both the syntax and the static semantics of programs.


Usage of attribute grammars l.jpg
Usage of Attribute Grammars Statements

  • Attribute grammars are a formal approach to both describing and checking the correctness of the static semantics rules of a program.

  • Although they are not always used in a formal way in compiler design, the basic concepts of attribute grammars are at least informally used in every compiler.


Components of attribute grammars l.jpg
Components of Attribute Grammars Statements

  • Attribute grammars are context-free grammars to which have been added

    • attributes,

    • attribute computation functions

    • predicate functions


Attributes l.jpg
Attributes Statements

  • Attributes, which are associated with grammar symbols(the terminal and nonterminal symbols), are similar to variables in the sense that they can have values assigned to them.


Attribute computation functions l.jpg
Attribute Computation Functions Statements

  • Attribute computation functions, sometimes called semantic functions, are associated with grammar rules.

  • They are used to specify how attribute values are computed.


Predicate functions l.jpg
Predicate Functions Statements

  • Predicate functions, which state some of the static semantic rules of the language, are associated with grammar rules.


Attribute grammars definition l.jpg
Attribute Grammars Statements : Definition

  • An attribute grammar is a context-free grammar G = (S, N, T, P) with the following additions:

    • For each grammar symbol X there is a set of attributesA(X)

    • Associated with each grammar rule is a set of semantic functions and a possibly empty set of predicate functions over the attributes of the symbols in the grammar rule.

    • Each rule has a (possibly empty) set of predicates to check for attribute consistency


Attributes of grammar symbols l.jpg
Attributes of Grammar Symbols Statements

  • Associated with each grammar symbol X is a set of attributes A(X).

  • The set A(X) consists of two disjoint sets S(X) and I(X), called synthesized and inherited attributes, respectively.

    • synthesized attributes are used to pass semantic information up a parse tree

    • inherited attributes pass semantic information down a tree.


Attribute definition l.jpg
Attribute Definition Statements

  • Let X0 X1 ... Xn be a rule

  • The synthesized attributes of X0 are computed with semantic functions of the formS(X0) = f(A(X1), ... , A(Xn)).

    • So the value of a synthesized attribute on a parse tree node depends only on the values of the attributes on that node's children nodes.

  • Inherited attributes of symbols Xj, 1 ≤ j ≤ n (in the rule above), are computed with a semantic function of the form I(Xj) = f(A(X0), ... , A(Xn)),

    • So the value of an inherited attribute on a parse tree node depends on the attribute values of that node's parent node and those of its sibling nodes.

  • Initially, there are intrinsic attributeson the leaves


Circularity l.jpg
Circularity Statements

  • To avoid circularity, inherited attributes are often restricted to functions of the form I(Xj) = f(A(X0), ..., A(XJ-1)))

  • The above form prevents an inherited attribute from depending on itself or on attributes to the right in the parse tree.


Predicate functions94 l.jpg
Predicate Functions Statements

  • A predicate function has the form of a Boolean expression on the attribute set {(A(X0),...,A(Xn)} and a set of literal attribute values.

  • The only derivations allowed with an attribute grammar are those in which every predicate associated with every nonterminal is true.

    • A false predicate function value indicates a violation of the syntax or static semantics rules of the language.


A parse tree of an attribute grammar l.jpg
A Parse Tree of an Attribute Grammar Statements

  • A parse tree of an attribute grammar is the parse tree based on its underlying BNF grammar, with a possibly empty set of attribute values attached to each node.

  • If all the attribute values in a parse tree have been computed, the tree is said to be fully attributed.

    • Although in practice it is not always done this way, it is convenient to think of attribute values as being computed after the complete unattributed parse tree has been constructed by the compiler.


Intrinsic attributes l.jpg
Intrinsic Attributes Statements

  • Intrinsic attributes are synthesized attributes of leaf nodes whose values are determined outside the parse tree.

    • For example, the type of an instance of a variable in a program could come from the symbol table, which is used to store variable names and their types.

      • The contents of the symbol table are determined from earlier declaration statements.


From intrinsic attributes to all attributes l.jpg
From Intrinsic Attributes to All Attributes Statements

  • Initially, assuming that an unattributed parse tree has been constructed and that attribute values are desired, the ONLY attributes with values are the intrinsic attributes of the leaf nodes.

  • Given the intrinsic attribute values on a parse tree, thesemantic functions can be used to compute the remaining attribute values.


Subscript l.jpg
Subscript Statements

  • Notice that when there is more than one occurrence of a nonterminal in a syntax rule in an attribute grammar, the nonterminals are subscripted with brackets to distinguish them.

  • Neither the subscript nor the brackets are part of the described language.


An attribute grammar example l.jpg
An Attribute Grammar Example Statements

  • The following is a fragment of an attribute grammar that describes the rule that the name on the end of an Ada procedure must match the procedure's name.

  • The string attribute of <proc_name>, denoted by <proc_name>.string, is the actual string of characters that were found by the lexical analyzer.

    Syntax rule:

    <proc_def> → procedure <proc_name>[l] <proc_body> end <proc_name>[2];

    Predicate:

    <proc_name>[1].string == <proc_name>[2].string


Use an attribute grammar to check the type rules of a simple assignment statement assumptions 1 l.jpg
Use an Attribute Grammar to Check the Type Rules of a Simple Assignment Statement – Assumptions (1)

  • The syntax and semantics of this assignment statement are as follows: The only variable names are A, B, and C.

    • The right side of the assignments can either be a variable or an expression in the form of a variable added to another variable.

    • The variables can be one of two types: int or real.

    • When there are two variables on the right side of an assignment, they need not be the same type.


Use an attribute grammar to check the type rules of a simple assignment statement assumptions 2 l.jpg
Use an Attribute Grammar to Check the Type Rules of a Simple Assignment Statement – Assumptions (2)

  • The type of the expression when the operand types are not the same is always real.

  • When they are the same, the expression type is that of the operands.

  • The type of the left side of the assignment must match the type of the right side.

  • So the types of operands in the right side can be mixed, but the assignment is valid only if the LHS and the value resulting from evaluating the RHS have the same type.


Use an attribute grammar to check the type rules of a simple assignment statement syntax l.jpg
Use an Attribute Grammar to Check the Type Rules of a Simple Assignment Statement - Syntax

  • The syntax portion of our example attribute grammar is

    <assign> → <var> = <expr>

    <expr> → <var> + <var>

    | <var>

    <var> → A | B | C


Use an attribute grammar to check the type rules of a simple assignment statement attributes l.jpg
Use an Attribute Grammar to Check the Type Rules of a Simple Assignment Statement - Attributes

  • The attributes for the nonterminals in the example attribute grammar are described as follows:

  • actual_type

    • A synthesized attribute associated with the nonterminals <var> and <expr>.

    • It is used to store the actual type, int or real in the example, of a variable or expression.

    • In the case of a variable, the actual type is intrinsic.

    • In the case of an expression, it is determined from the actual types of the child node or children nodes of the <expr> nonterminal,

  • expected_type

    • An inherited attribute associated with the nonterminal <expr>.

    • It is used to store the type, either int or real, that is expected for the expression, as determined by the type of the variable on the left side of the assignment statement.


Example 3 6 l.jpg
Example 3.6 Assignment Statement - Attributes



Decorating a parse tree l.jpg
Decorating a Parse Tree of Example 3.6

  • The process of computing the attribute values of a parse tree is sometimes called decorating the parse tree.


The process of decorating the parse tree with attributes l.jpg
The Process of Decorating the Parse Tree with Attributes of Example 3.6

  • This could proceed in a completely top-down order, from the root to the leaves, if all attributes were inherited.

  • Alternatively, it could proceed in a completely bottom-up order, from the leaves to the root, if all the attributes were synthesized.

  • Because our grammar has both synthesized and inherited attributes, the evaluation process cannot be in any single direction.


An example of attribute evaluation l.jpg
An Example of Attribute Evaluation of Example 3.6

The following is an evaluation of the attributes in Figure 3.6, in an order in which it is possible to compute them.

  • <var>.actual_type ← look-up(A) (Rule 4)

  • <expr>.expected_type ← <var>.actual_type (Rule 1)

  • <var>[2].actual_type ← look-up(A) (Rule 4) <var>[3].actual_type ← look-up(B) (Rule 4)

  • < expr>,actual_type ← either int or real (Rule 2)

  • <expr>.expected_type == <expr>.actual_type is either TRUE or FALSE (Rule 2)


The flow of attributes in the tree l.jpg
The Flow of Attributes in the Tree of Example 3.6

  • Solid lines are used for the parse tree.

  • Dashed lines show attribute flow in the tree.


A fully attributed parse tree l.jpg
A Fully Attributed Parse Tree of Example 3.6

  • A is defined as a real and B is defined as an int.


Evaluation order for the general case of an attribute grammar l.jpg
Evaluation Order for the General Case of an Attribute Grammar

  • Determining attribute evaluation order for the general case of an attribute grammar is a complex problem, requiring the construction of a dependency graph to show all attribute dependencies.


Pro and con l.jpg
Pro and Con Grammar

  • One of the main difficulties in using an attribute grammar to describe all of the syntax and static semantics of a real contemporary programming language is its SIZE and COMPLEXITY.

  • The large number of attributes and semantic rules required for a complete programming language make such grammars difficult to write and read.

  • Furthermore, the attribute values on a large parse tree are costly to evaluate.

  • On the other hand, less formal attribute grammars are a powerful and commonly used tool for compiler writers, who are more interested in the process of producing a compiler than they are in formalism.


Semantics l.jpg
Semantics Grammar

  • There is no single widely acceptable notation or formalism for describing semantics.

  • People usually find out the semantic of a programming language by reading English explanations in language manuals.



Operational semantics 1 l.jpg
Operational Semantics – (1) course !!!

  • Describe the meaning of a program by executing its statements on a machine, either simulated or actual. The change in the state of the machine (memory, registers, etc.) defines the meaning of the statement


Operational semantics 2 l.jpg
Operational Semantics – (2) course !!!

  • To use operational semantics for a high-level language, a virtual machine is needed

  • A hardwarepure interpreter would be too expensive

  • A software pure interpreter also has problems

    • The detailed characteristics of the particular computer would make actions difficult to understand

    • Such a semantic definition would be machine- dependent


Operational semantics continued l.jpg
Operational Semantics (continued) course !!!

  • A better alternative: A complete computer simulation

  • The process:

    • Build a translator (translates source code to the machine code of an idealized computer)

    • Build a simulator for the idealized computer

  • Evaluation of operational semantics:

    • Good if used informally (language manuals, etc.)

    • Extremely complex if used formally (e.g., VDL), it was used for describing semantics of PL/I.


Axiomatic semantics l.jpg
Axiomatic Semantics course !!!

  • Based on formal logic (predicate calculus)

  • Original purpose: formal program verification

  • Axioms or inference rules are defined for each statement type in the language (to allow transformations of expressions to other expressions)

  • The expressions are called assertions


Axiomatic semantics continued l.jpg
Axiomatic Semantics (continued) course !!!

  • An assertion before a statement (a precondition) 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 form l.jpg
Axiomatic Semantics Form course !!!

  • Pre-, post form: {P} statement {Q}

  • An example

    • a = b + 1 {a > 1}

    • One possible precondition: {b > 10}

    • Weakest precondition: {b > 0}


Program proof process l.jpg
Program Proof Process course !!!

  • The postcondition for the entire program is the desired result

    • Work back through the program to the first statement. If the precondition on the first statement is the same as the program specification, the program is correct.


Axiomatic semantics axioms l.jpg
Axiomatic Semantics: Axioms course !!!

  • An axiom for assignment statements (x = E): {Qx->E} x = E {Q}

  • The Rule of Consequence:


Axiomatic semantics axioms123 l.jpg
Axiomatic Semantics: Axioms course !!!

  • An inference rule for sequences

    {P1} S1 {P2}

    {P2} S2 {P3}


Axiomatic semantics axioms124 l.jpg
Axiomatic Semantics: Axioms course !!!

  • An inference rule for logical pretest loops

    {P} while B do S end {Q}

    where I is the loop invariant (the inductive hypothesis)


Axiomatic semantics axioms125 l.jpg
Axiomatic Semantics: Axioms course !!!

  • Characteristics of the loop invariant: I must meet the following conditions:

    • P => I -- the loop invariant must be true initially

    • {I} B {I} -- evaluation of the Boolean must not change the validity of I

    • {I and B} S {I} -- I is not changed by executing the body of the loop

    • (I and (not B)) => Q -- if I is true and B is false, is implied

    • The loop terminates


Loop invariant l.jpg
Loop Invariant course !!!

  • The loop invariant I is a weakened version of the loop postcondition, and it is also a precondition.

  • I must be weak enough to be satisfied prior to the beginning of the loop, but when combined with the loop exit condition, it must be strong enough to force the truth of the postcondition


Evaluation of axiomatic semantics l.jpg
Evaluation of Axiomatic Semantics course !!!

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

  • It is a good tool for correctness proofs, and an excellent framework for reasoning about programs, but it is not as useful for language users and compiler writers

  • Its usefulness in describing the meaning of a programming language is limited for language users or compiler writers


Denotational semantics l.jpg
Denotational Semantics course !!!

  • Based on recursive function theory

  • The most abstract semantics description method

  • Originally developed by Scott and Strachey (1970)


Denotational semantics continued l.jpg
Denotational Semantics (continued) course !!!

  • The process of building a denotational specification for a language 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

  • The meaning of language constructs are defined by only the values of the program's variables


Denotation semantics vs operational semantics l.jpg
Denotation Semantics vs Operational Semantics course !!!

  • In operational semantics, the state changes are defined by coded algorithms

  • In denotational semantics, the state changes are defined by rigorous mathematical functions


Denotational semantics program state l.jpg
Denotational Semantics: Program State course !!!

  • The state of a program is the values of all its current variables

    s = {<i1, v1>, <i2, v2>, …, <in, vn>}

  • Let VARMAP be a function that, when given a variable name and a state, returns the current value of the variable

    VARMAP(ij, s) = vj


Decimal numbers l.jpg
Decimal Numbers course !!!

<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('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


Expressions l.jpg
Expressions course !!!

  • Map expressions onto Z  {error}

  • We assume expressions are decimal numbers, variables, or binary expressions having one arithmetic operator and two operands, each of which can be an expression


3 5 semantics cont l.jpg
3.5 Semantics course !!! (cont.)

Me(<expr>, s) =

case <expr> of

<dec_num> => Mdec(<dec_num>, s)

<var> =>

if VARMAP(<var>, s) == undef

then error

else VARMAP(<var>, s)

<binary_expr> =>

if (Me(<binary_expr>.<left_expr>, s) == undef

OR Me(<binary_expr>.<right_expr>, s) =

undef)

then error

else

if (<binary_expr>.<operator> == ‘+’ then

Me(<binary_expr>.<left_expr>, s) +

Me(<binary_expr>.<right_expr>, s)

else Me(<binary_expr>.<left_expr>, s) *

Me(<binary_expr>.<right_expr>, s)

...


Assignment statements l.jpg
Assignment Statements course !!!

  • Maps state sets to state sets

    Ma(x := E, s) =

    if Me(E, s) == error

    then error

    else s’ = {<i1’,v1’>,<i2’,v2’>,...,<in’,vn’>},

    where for j = 1, 2, ..., n,

    vj’ = VARMAP(ij, s) if ij <> x

    = Me(E, s) if ij == x


Logical pretest loops l.jpg
Logical Pretest Loops course !!!

  • Maps state sets to state sets

    Ml(while B do L, s) =

    if Mb(B, s) == undef

    then error

    else if Mb(B, s) == false

    then s

    else if Msl(L, s) == error

    then error

    else Ml(while B do L, Msl(L, s))


Loop meaning l.jpg
Loop Meaning course !!!

  • The meaning of the loop is the value of the program variables after the statements in the loop have been executed the prescribed number of times, assuming there have been no errors

  • In essence, the loop has been converted from iteration to recursion, where the recursive control is mathematically defined by other recursive state mapping functions

  • Recursion, when compared to iteration, is easier to describe with mathematical rigor


Evaluation of denotational semantics l.jpg
Evaluation of Denotational Semantics course !!!

  • Can be used to prove the correctness of programs

  • Provides a rigorous way to think about programs

  • Can be an aid to language design

  • Has been used in compiler generation systems

  • Because of its complexity, they are of little use to language users


Summary l.jpg
Summary course !!!

  • BNF and context-free grammars are equivalent meta-languages

    • Well-suited for describing the syntax of programming languages

  • An attribute grammar is a descriptive formalism that can describe both the syntax and the semantics of a language

  • Three primary methods of semantics description

    • Operation, axiomatic, denotational


ad