The meaning of it all!The role of finite automata and grammars in compiler design

Compiler-Compilers!There are many applications of automata and grammars inside and outside computer science, the main applications in computer science being in the area of compiler design.Suppose we have designed (on paper) a new programming language with nice features. We have worked out their syntax and the way they should work. Now, all we need is a compiler for this language.Its too complex to write a compiler from scratch!What we could do is to make use of theoretical tools like automata and grammars that recognize/generate strings of symbols of various kinds* and formally specify the syntax of the new computer programming language. Such a formal specification (plus other details) can be used by magical programs known as compiler-compilers to automatically generate a compiler for the programming language!But for these theoretical tools we would have to spell out the syntax of a language in, say, plain English which will not be precise enough and programs would find it hard to understand such a description to be able to generate a compiler on its own.* A program can be viewed as a (very long!) string that adheres to certain rules dictated by the programming language.

Admiral Grace Hopper, Pioneer of compiler design

Lexical Analysis Lexical Analyzerfor(i=0;i

ParsingParse to relateFor ( I = 0 ; I

Finite state automata as lexical analysersAutomaton for recognizing keywordsAutomaton for recognizing identifiers

Converting a Finite state automaton into a computer programA: Read next_charIf next_char is a letter goto Belse FAIL( )

B: Read next_charIf next_char is either a letter or a digit goto Belse goto CNote: Instead of using A and B as labels for GOTO statements, one could use them as names of individual functions/procedures that can be invoked.FAIL( ) is a function that puts back the character just read and starts up the next transition diagram.

Grammars as syntax specification toolsFinite state automata are used to describe tokens. Grammars are much more expressive than finite state automata and can be used to describe more complicated syntactical structures in a program---for instance, the syntax of a FOR statement in C language.Grammars only describe/generate strings. We need a process which, given an input string (a statement in a program, say), pronounces whether it is derivable from a given grammar or not. Such a process is known as parsing.

Types of ParsingS aAcBeA Ab | bB da b b c d eAABSS(i)(ii)Reducing the input string to the start symbolExpanding the start symbol down to the input stringbAbdEXPANDING the start symbol (according to production rules of the given grammar), and subsequently every non-terminal symbol that occurs in the expansion* till we arrive at the input string. (* technically, it is called a sentential form)top downbottom upWe take a chunk of the input string and REDUCE it to (replace it with) the symbol on LHS of a production rule.In other words, the parse tree is constructed by beginning at the leaves and working up towards the root.

Shift-Reduce: a bottom up parsing techniqueabbcdeInput $ aWe shift symbols from input string (from left to right) usually onto a stack so that the chunk of symbols (matching the RHS of a production) which is to be reduced to the corresponding LHS wiil eventually appear on top of stack. (The chunk getting reduced is referred to as the handle.)S aAcBeA Ab | bB d$ b b c d e

What is a handle?A substring of the input string that matches the RHS of a production replacing which (by the corresponding LHS) would eventually lead to a reduction to the start symbol is called a handle.S aAcBeA Ab | bB dS aAcBeC aAcde aAbcde abbcdeA Right Most Derivation (RMD)Non-terminal symbols on the right get expanded first before those on the left get expanded. When we do this in reverse, though, (now reducing symbols---not expanding) pieces of string on the left get reduced first before those on the right.Bottom up parsing can be viewed as RMD in reverse direction.

The problem with discovering handlesDiscovering the handle may not be easy always!There may be more than one substring emerging on top-of-stack that matches the RHS of a production.a b b c d eAAS aAcBeA Ab | bB d?Theres no way a AAcde can be reduced to S. (When we make an incorrect choice of handle we get stuck half-way through, before we can arrive at the start symbol.)

The problem with discovering handlesIn the exercises we did, we took decisions as to when to shift and when to reduce symbols (by ourselves, using our cleverness!).However, these can (and must) be done automatically by the parser program in tune with the given grammar.The well-known LR parser can do this and is beyond our present scope.

Top down parsingFormal :Construct parse tree (for the input) by beginning at the root and creating the nodes (of the tree) in preorder. In other words, its an attempt to find a Left Most Derivation for an input string.Informal :Instead of starting to work on the input string and reduce it to the start symbol (by replacing chunks of it with non-terminal symbols), we begin with the start symbol itself and ask: How can I expand this in order to arrive (eventually) at the input string? We ask the same question for every non-terminal symbol occurring in the resulting expansions. We choose an appropriate expansion of a certain non-terminal by glancing at the input string, i.e. by taking cues from the symbol being scanned (and also the next few symbols) in the input.

Top down parsing: an exampleS cAdA ab | aAcdSabStart with S. Only one expansion is possible.OK! It matches with the first symbol in the input.Now, how to expand A? Try every expansion one by one! mismatch!(so, try another expansion)match!amatch!(so, move on!)match!(weredone!)(i)(ii)(iii)(iv)

Top down parsing: an examplefunction S( ){ if input_symbol = c then { ADVANCE( ); if A( ) then { if input_symbol = d then { ADVANCE( ); return TRUE; } } } return FALSE;}function A( ){ isave = input_pointer; if input_symbol = a then { ADVANCE( ); if input_symbol = b then { ADVANCE( ); return TRUE; } } input_pointer = isave; /* Try second expansion */ if input_symbol = a then { ADVANCE( ); return TRUE; } return FALSE;}A program to do top-down parsing might use a separate procedure for every non-terminal

Problems with this approach(i) Order in which the expansions are triedS cAdA a | abmatchmatchd is part of S and hence a new expansion for S will be tried (in vain!). Hence, cabd will be rejected as invalid (but is actually valid).Remedy: Rewrite grammar so that there is no more than ONE expansion for every non-terminal sharing the same prefix; use left factoring to realise this.

Problems with this approach(ii) Left recursionA AProduction rule of the said form exhibits (immediate) left recursion. (More precisely,) a grammar has left recursion if, at some point, A yields A, i.e. if A can be derived from A in one or more steps.Why is left recursion dangerous? Its because the function A( ) corresponding to non-terminal A) will be forced to invoke itself repeatedly and endlessly.Remedy:To eliminate left recursion (from the grammar)!

Eliminating (immediate) left recursionA A | A AA A | A A A A

E E + T | TT T * F | FF ( E ) | idE TEE +TE | T FTT *FT | F ( E ) | ide.g.

Left factoringA | A A A | S iCtS | iCtSeS | aC be.g.S iCtSS | aS eS | C b