DOCSLIB.ORG

Chapter 3 Syntax

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Chapter 3 Syntax Topics Introduction Chapter 3 English Description Syntax Regular Expressions Syntax BNF Variations of BNF Chomsky Hierarchy Parsing Ambiguity, associativity, and precedence. Chapter 3: Syntax 2 Introduction Introduction: English Description Language definition n Early days n Syntax Syntax and semantics: lengthy English explanations and many examples n Semantics Example (Syntax): the if-statement in Pascal may be Syntax described in words: n Form, format, well-formedness, and compositional An if-statement consists of the word “if” followed by a condition, followed by the word “then”, followed by a statement, followed by an structure of the language. optional else part consisting of the word “else ” and another statement. n Description of the ways different parts of the language n Example (Semantics): the if-statement in Pascal may be combined to form other parts. may be described in words: Semantics An if-statement is executed by first evaluating its conditions. If the condition evaluates to true, then the statement following n Meaning and interpretation of the language. the “then” is executed. If the condition evaluates to false, and there is an else part, then the statement following the “ else” is n Description of what happens during the exsecution of a executed. program. Chapter 3: Syntax 3 Chapter 3: Syntax 4 Syntax Definition of a Language (Programming language) Definition of what Formal language: set of finite string of constitutes a grammatically valid program in atomic symbols. that language. Alphabet: set of symbols. Syntax is specified as a set of rules, just as it Sentences: the strings that belong to the is for natural languages. language. Clear, concise, and formal definition syntax is Alphabet: {a,b} especially important for programmers, L1 = {a, b, ab} This language is finite: just three strings implementers, language designer, etc. L2 = {aa, aba, abba, abbba, … } The syntax of a language has a profound This language is infinite effect on the ease of use of a language. n More precise methods for defining languages are desirable than just using “…”. Chapter 3: Syntax 5 Chapter 3: Syntax 6 1 Definition of a Regular Expression Regular Expressions Invented by a mathematical logician Stephen 4. Concatenation. If r and r are regular Kleene 1 2 expressions, then (r1×r2) is a regular expression. The A regular expression over A denotes a language it denotes is the set of all strings formed by concatenating a string from the set denoted by r to the language with alphabet A and is defined by the 1 end of a string in the set denoted by r2. following set or rules: 3. Closure. If r is a regular expression, then r* is a 1. Empty. The symbol Æis a regular expression, denoting regular expression. The language it denotes consists of the language consisting of no strings {}. all strings formed by concatenating zero or more strings 2. Atom. Any single symbol of aÎA is a regular in the language denoted by r. expression denoting the language consisting of the single string {a}. 3. Alternation. If r is a regular expression and r is a - Plus, dot, asterisk, the empty set symbol, and parentheses 1 2 are part of the notation for regular expressions, not part of the regular expression, then (r1+r2) is a regular expression. The language it denotes has all the strings from the language languages being defined. - Definitions are recursive. denoted by r1 and all the strings from the language denoted by r2. Chapter 3: Syntax 7 Chapter 3: Syntax 8 Conventions for Writing Regular Regular Expressions: Example Expressions Sequences of ASCII characters make up Regular Expression Meaning a legal identifier x A character (stand for itself) l stand for the regular expression denoting any “xyz” A literal string (stands for itself) M | N M or N lowercase or uppercase letter M N M followed by N (concatenation) d stand for the regular expression denoting any M* Zero or more occurrences of M decimal digit. M+ One or more occurrences of M [a- zA - Z] Any alphabetic character n Modula-3 l × ( l+d+_ )* [0-9] Any digit n ML l × ( l+d+_+’ )* . Any single charcater n Ada l × ( l+d )* × ( _ × ( l+d ) × ( l+d )* )* Chapter 3: Syntax 9 Chapter 3: Syntax 10 Formal Methods of Describing Regular Expressions Syntax: BNF Very popular tool in language design. Metalanguage: is a language used to define Generic lexical-analyzer generator: other language. n The regular expression is submitted directly. n Two commonly used generators: BNF: notation invented to describe the syntax of “Lex” (generating C code). ALGOL 60 “Jlex” (for generating Java code). What is the problem with regular expressions? n Backus-Naur Form in honor of John Backus and Why don’t we use them to describe the syntax of programming Peter Naur, who developed the notation of this languages? metalanguage in unrelated research efforts. n Major shortcoming: bracketing is not expressible n Language: a sequence of tokens. n n n Regular expressions are incapable of generating the language {a b } where the number of as must be equal to the number of bs, very useful for n Tokens:identifiers, numbers, keywords, punctuation, matching nested beginning and ending tags, such as occur in expressions etc. that constitute the lexicon of the language. (parentheses) and statement lists (braces). Chapter 3: Syntax 11 Chapter 3: Syntax 12 2 BNF: Grammar BNF: Notation n BNF grammar: a set of rewriting rules. A BNF definition typically contains the A a left-hand side: syntactic categories n A syntactic category is a name for a set of token sequences following meta-symbols: A right-hand side: sequences of tokens and syntactic “::=” meaning “is defined to be” categories. “<>” to delimit syntactic categories <name> ::= sequence of tokens and syntactic categories There may be many rules with the same left-hand side. “|” meaning “or” n A token sequence belongs to a syntactic category if it Strictly speaking, the symbol for “or” is not can be derived by taking the right-hand sides of rules necessary, but it is convenient for combining multiple for the category and replacing the syntactic category right-hand sides for the same syntactic category. occurring in right-hand side with any token sequence belonging to that category. Chapter 3: Syntax 13 Chapter 3: Syntax 14 BNF: Examples (1) BNF: Examples (2) Describe the syntax of regular expressions over the Describe the ALGOL 60 for construct. alphabet {a,b} <for statement> ::= <for clause> <statement> | <label> : <for statement> <for clause> ::= for <variable> := <for list> do <RE> ::= Æ| a| b| (<RE>+<RE}) | (<RE>×<RE>) | <RE>* <for list> ::= <for list element> | <for list> , <for list element> n The syntactic category of regular expressions is defined to be <for list element> ::= <arith expr> either the symbol Æ, or the symbol a, or the symbol b, or an | < ariht expr> step <arith expr> until <arith expr> opening parenthesis, followed by a regular expression, followed by a plus sign followed by another regular expression | < arith expr> while <boolean exp> followed by a closing parenthesis, and so on. The set of tokens used in this definition is { Æ,a,b,(,),+,×,*} Sample for statements in ALGOL 60 for i := j step 1 until n do <statement> A: B: for k := 1 step-1 until n, i+1 whilej>1 do <statement> Chapter 3: Syntax 15 Chapter 3: Syntax 16 BNF: Examples (3) BNF: A Stream of Tokens Describe simple integer arithmetic expressions with addition and multiplication. Previous categories allow the compiler to <exp> ::= <exp> + <exp> | <exp> * <exp> look at a program as a stream of tokens. | (<exp>) | <number> n Each one a member of a particular grammatical <number> ::= <number> <digit> | <digit> <digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 category Lexicon of a programming language contains the n Separated from the next token by whitespaces or grammatical categories: a comment. n Identifier (variable names, function names, etc) n Literal or constants (integer and decimal numbers) Comment // compute result = the nth Fibonacci number void main () { n Operator (+,-,*,/,etc) int n; Keyword Separator n Separator (;,.,{,},etc) n = 8; Identifier n Keyword or reserved words (int, main, if, for, etc) Literal Operator Chapter 3: Syntax 17 Chapter 3: Syntax 18 3 Variations of BNF: EBNF EBNF: Example Describe simple integer arithmetic expressions with Several extensions to BNF have been proposed to addition and multiplication. make BNF definitions more readable. <digit> ::= 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 <number> ::= <digit> {<digit} n Improve the clarity of syntax description and the efficiency of syntax analysis. <exp> ::= <term> {+ <term>} | <term> {- <term>} n Do not add to the expressive power of the formalism, just to the The curly brackets “{ }” denote zero or more repetitions. convenience. The square brackets enclose a series of alternatives from which one must Extended BNF (EBNF for short) was introduced to choose. simplify the specification of recursion in grammar rules Definitions of language syntax in EBNF tend to be (curly brackets), and to introduce the idea of optional slightly clearer and briefer than BNF definitions. part in a rule’s right-hand side (square brackets). EBNF does not force the use of recursive definitions on the reader in very instance. Chapter 3: Syntax 19 Chapter 3: Syntax 20 Variations of BNF: Syntax EBNF: Example Diagrams The Ada reference manual use extended BNF. Graphical representation that indicates the n Uses different convention to distinguish syntactic sequence of terminals and nonterminals categories from terminals. encountered in the right-hand side of the n Syntactic categories are denoted by simple identifiers rule. possibly containing underscores. n Circles or ovals for terminals n Keywords and punctuation are in bold face. n Squares or rectangles for nonterminals block ::= [ block_identifier: ] [ declare{declaration} ] n Connected with lines and arrows to indicate begin statement {statement} appropriate sequencing.
Load more

Recommended publications
  • Layout-Sensitive Generalized Parsing
    Layout-sensitive Generalized Parsing Sebastian Erdweg, Tillmann Rendel, Christian K¨astner,and Klaus Ostermann University of Marburg, Germany Abstract. The theory of context-free languages is well-understood and context-free parsers can be used as off-the-shelf tools in practice. In par- ticular, to use a context-free parser framework, a user does not need to understand its internals but can specify a language declaratively as a grammar. However, many languages in practice are not context-free. One particularly important class of such languages is layout-sensitive languages, in which the structure of code depends on indentation and whitespace. For example, Python, Haskell, F#, and Markdown use in- dentation instead of curly braces to determine the block structure of code. Their parsers (and lexers) are not declaratively specified but hand-tuned to account for layout-sensitivity. To support declarative specifications of layout-sensitive languages, we propose a parsing framework in which a user can annotate layout in a grammar. Annotations take the form of constraints on the relative posi- tioning of tokens in the parsed subtrees. For example, a user can declare that a block consists of statements that all start on the same column. We have integrated layout constraints into SDF and implemented a layout- sensitive generalized parser as an extension of generalized LR parsing. We evaluate the correctness and performance of our parser by parsing 33 290 open-source Haskell files. Layout-sensitive generalized parsing is easy to use, and its performance overhead compared to layout-insensitive parsing is small enough for practical application. 1 Introduction Most computer languages prescribe a textual syntax.
    [Show full text]
  • Parse Forest Diagnostics with Dr. Ambiguity
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by CWI's Institutional Repository Parse Forest Diagnostics with Dr. Ambiguity H. J. S. Basten and J. J. Vinju Centrum Wiskunde & Informatica (CWI) Science Park 123, 1098 XG Amsterdam, The Netherlands {Jurgen.Vinju,Bas.Basten}@cwi.nl Abstract In this paper we propose and evaluate a method for locating causes of ambiguity in context-free grammars by automatic analysis of parse forests. A parse forest is the set of parse trees of an ambiguous sentence. Deducing causes of ambiguity from observing parse forests is hard for grammar engineers because of (a) the size of the parse forests, (b) the complex shape of parse forests, and (c) the diversity of causes of ambiguity. We first analyze the diversity of ambiguities in grammars for programming lan- guages and the diversity of solutions to these ambiguities. Then we introduce DR.AMBIGUITY: a parse forest diagnostics tools that explains the causes of ambiguity by analyzing differences between parse trees and proposes solutions. We demonstrate its effectiveness using a small experiment with a grammar for Java 5. 1 Introduction This work is motivated by the use of parsers generated from general context-free gram- mars (CFGs). General parsing algorithms such as GLR and derivates [35,9,3,6,17], GLL [34,22], and Earley [16,32] support parser generation for highly non-deterministic context-free grammars. The advantages of constructing parsers using such technology are that grammars may be modular and that real programming languages (often requiring parser non-determinism) can be dealt with efficiently1.
    [Show full text]
  • Formal Languages - 3
    Formal Languages - 3 • Ambiguity in PLs – Problems with if-then-else constructs – Harder problems • Chomsky hierarchy for formal languages – Regular and context-free languages – Type 1: Context-sensitive languages – Type 0 languages and Turing machines Formal Languages-3, CS314 Fall 01© BGRyder 1 Dangling Else Ambiguity (Pascal) Start ::= Stmt Stmt ::= Ifstmt | Astmt Ifstmt ::= IF LogExp THEN Stmt | IF LogExp THEN Stmt ELSE Stmt Astmt ::= Id := Digit Digit ::= 0|1|2|3|4|5|6|7|8|9 LogExp::= Id = 0 Id ::= a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z How are compound if statements parsed using this grammar?? Formal Languages-3, CS314 Fall 01© BGRyder 2 1 IF x = 0 THEN IF y = 0 THEN z := 1 ELSE w := 2; Start Parse Tree 1 Stmt Ifstmt IF LogExp THEN Stmt Ifstmt Id = 0 IF LogExp THEN Stmt ELSE Stmt x Id = 0 Astmt Astmt Id := Digit y Id := Digit z 1 w 2 Formal Languages-3, CS314 Fall 01© BGRyder 3 IF x = 0 THEN IF y = 0 THEN z := 1 ELSE w := 2; Start Stmt Parse Tree 2 Ifstmt Q: which tree is correct? IF LogExp THEN Stmt ELSE Stmt Id = 0 Ifstmt Astmt IF LogExp THEN Stmt x Id := Digit Astmt Id = 0 w 2 Id := Digit y z 1 Formal Languages-3, CS314 Fall 01© BGRyder 4 2 How Solve the Dangling Else? • Algol60: use block structure if x = 0 then begin if y = 0 then z := 1 end else w := 2 • Algol68: use statement begin/end markers if x = 0 then if y = 0 then z := 1 fi else w := 2 fi • Pascal: change the if statement grammar to disallow parse tree 2; that is, always associate an else with the closest if Formal Languages-3, CS314 Fall 01© BGRyder 5 New Pascal Grammar Start ::= Stmt Stmt ::= Stmt1 | Stmt2 Stmt1 ::= IF LogExp THEN Stmt1 ELSE Stmt1 | Astmt Stmt2 ::= IF LogExp THEN Stmt | IF LogExp THEN Stmt1 ELSE Stmt2 Astmt ::= Id := Digit Digit ::= 0|1|2|3|4|5|6|7|8|9 LogExp::= Id = 0 Id ::= a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z Note: only if statements with IF..THEN..ELSE are allowed after the THEN clause of an IF-THEN-ELSE statement.
    [Show full text]
  • Ordered Sets in the Calculus of Data Structures
    Exercise 1: Balanced Parentheses Show that the following balanced parentheses grammar is ambiguous (by finding two parse trees for some input sequence) and find unambiguous grammar for the same language. B ::= | ( B ) | B B Remark • The same parse tree can be derived using two different derivations, e.g. B -> (B) -> (BB) -> ((B)B) -> ((B)) -> (()) B -> (B) -> (BB) -> ((B)B) -> (()B) -> (()) this correspond to different orders in which nodes in the tree are expanded • Ambiguity refers to the fact that there are actually multiple parse trees, not just multiple derivations. Towards Solution • (Note that we must preserve precisely the set of strings that can be derived) • This grammar: B ::= | A A ::= ( ) | A A | (A) solves the problem with multiple symbols generating different trees, but it is still ambiguous: string ( ) ( ) ( ) has two different parse trees Solution • Proposed solution: B ::= | B (B) • this is very smart! How to come up with it? • Clearly, rule B::= B B generates any sequence of B's. We can also encode it like this: B ::= C* C ::= (B) • Now we express sequence using recursive rule that does not create ambiguity: B ::= | C B C ::= (B) • but now, look, we "inline" C back into the rules for so we get exactly the rule B ::= | B (B) This grammar is not ambiguous and is the solution. We did not prove this fact (we only tried to find ambiguous trees but did not find any). Exercise 2: Dangling Else The dangling-else problem happens when the conditional statements are parsed using the following grammar. S ::= S ; S S ::= id := E S ::= if E then S S ::= if E then S else S Find an unambiguous grammar that accepts the same conditional statements and matches the else statement with the nearest unmatched if.
    [Show full text]
  • 14 a Simple Compiler - the Front End
    Compilers and Compiler Generators © P.D. Terry, 2000 14 A SIMPLE COMPILER - THE FRONT END At this point it may be of interest to consider the construction of a compiler for a simple programming language, specifically that of section 8.7. In a text of this nature it is impossible to discuss a full-blown compiler, and the value of our treatment may arguably be reduced by the fact that in dealing with toy languages and toy compilers we shall be evading some of the real issues that a compiler writer has to face. However, we hope the reader will find the ensuing discussion of interest, and that it will serve as a useful preparation for the study of much larger compilers. The technique we shall follow is one of slow refinement, supplementing the discussion with numerous asides on the issues that would be raised in compiling larger languages. Clearly, we could opt to develop a completely hand-crafted compiler, or simply to use a tool like Coco/R. We shall discuss both approaches. Even when a compiler is constructed by hand, having an attributed grammar to describe it is very worthwhile. On the source diskette can be found a great deal of code, illustrating different stages of development of our system. Although some of this code is listed in appendices, its volume precludes printing all of it. Some of it has deliberately been written in a way that allows for simple modification when attempting the exercises, and is thus not really of "production quality". For example, in order to allow components such as the symbol table handler and code generator to be used either with hand-crafted or with Coco/R generated systems, some compromises in design have been necessary.
    [Show full text]
  • Disambiguation Filters for Scannerless Generalized LR Parsers
    Disambiguation Filters for Scannerless Generalized LR Parsers Mark G. J. van den Brand1,4, Jeroen Scheerder2, Jurgen J. Vinju1, and Eelco Visser3 1 Centrum voor Wiskunde en Informatica (CWI) Kruislaan 413, 1098 SJ Amsterdam, The Netherlands {Mark.van.den.Brand,Jurgen.Vinju}@cwi.nl 2 Department of Philosophy, Utrecht University Heidelberglaan 8, 3584 CS Utrecht, The Netherlands [email protected] 3 Institute of Information and Computing Sciences, Utrecht University P.O. Box 80089, 3508TB Utrecht, The Netherlands [email protected] 4 LORIA-INRIA 615 rue du Jardin Botanique, BP 101, F-54602 Villers-l`es-Nancy Cedex, France Abstract. In this paper we present the fusion of generalized LR pars- ing and scannerless parsing. This combination supports syntax defini- tions in which all aspects (lexical and context-free) of the syntax of a language are defined explicitly in one formalism. Furthermore, there are no restrictions on the class of grammars, thus allowing a natural syntax tree structure. Ambiguities that arise through the use of unrestricted grammars are handled by explicit disambiguation constructs, instead of implicit defaults that are taken by traditional scanner and parser gener- ators. Hence, a syntax definition becomes a full declarative description of a language. Scannerless generalized LR parsing is a viable technique that has been applied in various industrial and academic projects. 1 Introduction Since the introduction of efficient deterministic parsing techniques, parsing is considered a closed topic for research, both by computer scientists and by practi- cioners in compiler construction. Tools based on deterministic parsing algorithms such as LEX & YACC [15,11] (LALR) and JavaCC (recursive descent), are con- sidered adequate for dealing with almost all modern (programming) languages.
    [Show full text]
  • Introduction to Programming Languages and Syntax
    Programming Languages Session 1 – Main Theme Programming Languages Overview & Syntax Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences Adapted from course textbook resources Programming Language Pragmatics (3rd Edition) Michael L. Scott, Copyright © 2009 Elsevier 1 Agenda 11 InstructorInstructor andand CourseCourse IntroductionIntroduction 22 IntroductionIntroduction toto ProgrammingProgramming LanguagesLanguages 33 ProgrammingProgramming LanguageLanguage SyntaxSyntax 44 ConclusionConclusion 2 Who am I? - Profile - ¾ 27 years of experience in the Information Technology Industry, including thirteen years of experience working for leading IT consulting firms such as Computer Sciences Corporation ¾ PhD in Computer Science from University of Colorado at Boulder ¾ Past CEO and CTO ¾ Held senior management and technical leadership roles in many large IT Strategy and Modernization projects for fortune 500 corporations in the insurance, banking, investment banking, pharmaceutical, retail, and information management industries ¾ Contributed to several high-profile ARPA and NSF research projects ¾ Played an active role as a member of the OMG, ODMG, and X3H2 standards committees and as a Professor of Computer Science at Columbia initially and New York University since 1997 ¾ Proven record of delivering business solutions on time and on budget ¾ Original designer and developer of jcrew.com and the suite of products now known as IBM InfoSphere DataStage ¾ Creator of the Enterprise
    [Show full text]
  • CS4200 | Compiler Construction | September 10, 2020 Disambiguation and Layout-Sensitive Syntax
    Disambiguation and Layout-Sensitive Syntax Eelco Visser CS4200 | Compiler Construction | September 10, 2020 Disambiguation and Layout-Sensitive Syntax Syntax Definition Summary Derivations - Generating sentences and trees from context-free grammars Ambiguity Declarative Disambiguation Rules - Associativity and priority Grammar Transformations - Eliminating ambiguity by transformation Layout-Sensitive Syntax - Disambiguation using layout constraints Structure Syntax = Structure module structure let inc = function(x) { x + 1 } imports Common in inc(3) context-free start-symbols Exp end context-free syntax Exp.Var = ID Exp.Int = INT Exp.Add = Exp "+" Exp Let( Exp.Fun = "function" "(" {ID ","}* ")" "{" Exp "}" [ Bnd( "inc" Exp.App = Exp "(" {Exp ","}* ")" , Fun(["x"], Add(Var("x"), Int("1"))) ) Exp.Let = "let" Bnd* "in" Exp "end" ] , App(Var("inc"), [Int("3")]) Bnd.Bnd = ID "=" Exp ) Token = Character module structure let inc = function(x) { x + 1 } imports Common in inc(3) context-free start-symbols Exp end context-free syntax Exp.Var = ID module Common Exp.Int = INT lexical syntax Exp.Add = Exp "+" Exp ID = [a-zA-Z] [a-zA-Z0-9]* Exp.Fun = "function" "(" {ID ","}* ")" "{" Exp "}" INT = [\-]? [0-9]+ Exp.App = Exp "(" {Exp ","}* ")" Exp.Let = "let" Bnd* "in" Exp "end" Lexical Syntax = Context-Free Syntax Bnd.Bnd = ID "=" Exp (But we don’t care about structure of lexical syntax) Literal = Non-Terminal module structure let inc = function(x) { x + 1 } imports Common in inc(3) context-free start-symbols Exp end context-free syntax syntax Exp.Var
    [Show full text]
  • Programming Languages
    Programming Languages CSCI-GA.2110-001 Summer 2011 Dr. Cory Plock What this course is ■ A study of programming language paradigms ◆ Imperitive ◆ Functional ◆ Logical ◆ Object-oriented ■ Tour of programming language history & roots. ■ Introduction to core language design & implementation concepts. ■ Exposure to new languages you may not have used before. ■ Ability to reason about language benefits/pitfalls. ■ A look at programming language implementation. ■ Offers an appreciation of language standards. ■ Provides the ability to more quickly learn new languages. 2 / 26 What this course isn’t ■ A comprehensive study of one or more languages. ■ An exercise in learning as many languages as possible. ■ A software engineering course. ■ A compiler course. 3 / 26 Introduction The main themes of programming language design and use: ■ Paradigm (Model of computation) ■ Expressiveness ◆ control structures ◆ abstraction mechanisms ◆ types and their operations ◆ tools for programming in the large ■ Ease of use: Writeability / Readability / Maintainability 4 / 26 Language as a tool for thought ■ Role of language as a communication vehicle among programmers can be just as important as ease of writing ■ All general-purpose languages are Turing complete (They can compute the same things) ■ But languages can make expression of certain algorithms difficult or easy. ◆ Try multiplying two Roman numerals ■ Idioms in language A may be useful inspiration when writing in language B. 5 / 26 Idioms ■ Copying a string q to p in C: while (*p++ = *q++) ; ■ Removing duplicates
    [Show full text]
  • A Practical Tutorial on Context Free Grammars
    A Practical Tutorial on Context Free Grammars Robert B. Heckendorn University of Idaho September 16, 2020 Contents 1 Some Definitions 3 2 Some Common Idioms and Hierarchical Development 5 2.1 A grammar for a language that allows a list of X's . .5 2.2 A Language that is a List of X's or Y's . .5 2.3 A Language that is a List of X's Terminated with a Semicolon . .5 2.4 Hierarchical Complexification . .6 2.5 A Language Where There are not Terminal Semicolons but Separating Commas . .6 2.6 A language where each X is followed by a terminating semicolon: . .6 2.7 An arg list of X's, Y's and Z's: . .6 2.8 A Simple Type Declaration: . .6 2.9 Augment the Type Grammar with the Keyword Static . .7 2.10 A Tree Structure as Nested Parentheses . .7 3 Associativity and Precedence 7 3.1 A Grammar for an Arithmetic Expression . .7 3.2 Grouping with Parentheses . .8 3.3 Unary operators . .9 3.4 An Example Problem . 10 4 How can Things go Wrong 10 4.1 Inescapable Productions . 10 4.2 Ambiguity . 11 4.2.1 Ambiguity by Ill-specified Associativity . 12 4.2.2 Ambiguity by Infinite Loop . 13 4.2.3 Ambiguity by Multiple Paths . 14 1 5 The Dangling Else 15 6 The Power of Context Free and incomplete grammars 16 7 Tips for Grammar Writing 18 8 Extended BNF 18 2 A grammar is used to specify the syntax of a language. It answers the question: What sentences are in the language and what are not? A sentence is a finite sequence of symbols from the alphabet of the language.
    [Show full text]
  • Context Free Languages
    Context Free Languages COMP2600 — Formal Methods for Software Engineering Katya Lebedeva Australian National University Semester 2, 2016 Slides by Katya Lebedeva and Ranald Clouston. COMP 2600 — Context Free Languages 1 Ambiguity The definition of CF grammars allow for the possibility of having more than one structure for a given sentence. This ambiguity may make the meaning of a sentence unclear. A context-free grammar G is unambiguous iff every string can be derived by at most one parse tree. G is ambiguous iff there exists any word w 2 L(G) derivable by more than one parse trees. COMP 2600 — Context Free Languages 2 Dangling else Take the code if e1 then if e2 then s1 else s2 where e1, e2 are boolean expressions and s1, s2 are subprograms. Does this mean if e1 then( if e2 then s1 else s2) or if e1 then( if e2 then s1) else s2 The dangling else is a problem in computer programming in which an optional else clause in an “ifthen(else)” statement results in nested conditionals being ambiguous. COMP 2600 — Context Free Languages 3 This is a problem that often comes up in compiler construction, especially parsing. COMP 2600 — Context Free Languages 4 Inherently Ambiguous Languages Not all context-free languages can be given unambiguous grammars – some are inherently ambiguous. Consider the language L = faib jck j i = j or j = kg How do we know that this is context-free? First, notice that L = faibickg [ faib jc jg We then combine CFGs for each side of this union (a standard trick): S ! T j W T ! UV W ! XY U ! aUb j e X ! aX j e V ! cV j e Y ! bYc j e COMP 2600 — Context Free Languages 5 The problem with L is that its sub-languages faibickg and faib jc jg have a non-empty intersection.
    [Show full text]
  • 165142A8ddd2a8637ad23690e
    CS 345 Lexical and Syntactic Analysis Vitaly Shmatikov slide 1 Reading Assignment Mitchell, Chapters 4.1 C Reference Manual, Chapters 2 and 7 slide 2 Syntax Syntax of a programming language is a precise description of all grammatically correct programs • Precise formal syntax was first used in ALGOL 60 Lexical syntax • Basic symbols (names, values, operators, etc.) Concrete syntax • Rules for writing expressions, statements, programs Abstract syntax • Internal representation of expressions and statements, capturing their “meaning” (i.e., semantics) slide 3 Grammars A meta-language is a language used to define other languages A grammar is a meta-language used to define the syntax of a language. It consists of: • Finite set of terminal symbols • Finite set of non-terminal symbols Backus-Naur • Finite set of production rules Form (BNF) • Start symbol • Language = (possibly infinite) set of all sequences of symbols that can be derived by applying production rules starting from the start symbol slide 4 Example: Decimal Numbers Grammar for unsigned decimal integers • Terminal symbols: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 • Non-terminal symbols: Digit, Integer Shorthand for • Production rules: Integer → Digit – Integer → Digit | Integer Digit Integer → Integer Digit – Digit → 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 • Start symbol: Integer Can derive any unsigned integer using this grammar • Language = set of all unsigned decimal integers slide 5 Derivation of 352 as an Integer Production rules: Integer → Digit | Integer Digit Integer ⇒ Integer Digit Digit
    [Show full text]