{"id":106,"date":"2018-07-19T12:06:30","date_gmt":"2018-07-19T12:06:30","guid":{"rendered":"http:\/\/csp10.epgpbooks.inflibnet.ac.in\/?post_type=chapter&#038;p=106"},"modified":"2018-07-19T12:07:10","modified_gmt":"2018-07-19T12:07:10","slug":"parser-generator","status":"publish","type":"chapter","link":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/chapter\/parser-generator\/","title":{"rendered":"PARSER GENERATOR"},"content":{"raw":"In this module we will learn to use the parser generator to parse a given string. We will learn the YACC parser tool.\r\n\r\n&nbsp;\r\n\r\n<strong>19.1 Parsers<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">The LL(k) and LR(k) parsers discussed in the previous modules uses the grammar definition of a programming language and verifies whether an input string belongs to a grammar by constructing a parsing table. The construction of the parsing table is a tedious process as can be understood from the previous modules and hence we check whether it is possible for a tool to do the parsing action. We have already discussed the LEX tool to do the action of tokenizing. We also know that there is enough interaction between the lexical phase and the syntactic phase, where the lexer issues a token based on a request from the parser. Due to the interaction between the lexer and parser we could use a tool for the parser and integrate it with the lexer. The following are some of the tools available for parsing:<\/p>\r\n&nbsp;\r\n<ul>\r\n \t<li>ANTLR (ANother Tool for Language Recognition) tool generates LL(k) parsers<\/li>\r\n \t<li>YACC (Yet Another Compiler Compiler) generates LALR(1) parsers<\/li>\r\n \t<li>Bison \u2013 It is an improved version of YACC<\/li>\r\n<\/ul>\r\nAs bottom up parsers are preferred, YACC is a preferred tool for parsing.\r\n\r\n&nbsp;\r\n\r\n<strong>19.2 YACC Tool<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">The overall working of the YACC tool is shown in figure 19.1. The YACC is a LALR parser and hence avoids shift\/reduce conflicts to a greater extent. The input program is a YACC specification program and is named with a \u201c.y\u201d extension. This program consists of the grammar rules of a programming language and the corresponding action that needs to be taken. This \u201c.y\u201d file is compiled using a YACC compiler. The output of the YACC compiler is a file named \u201cy.tab.c\u201d which can be compiled using a C compiler to generate an output file. The \u201c.y\u201d file in-turn would call the \u201c.l\u201d LEX specifications file to tokenize the given input.<\/p>\r\n<img class=\"size-full wp-image-107 aligncenter\" src=\"http:\/\/csp10.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-54.png\" alt=\"\" width=\"564\" height=\"236\" \/>\r\n<div>\r\n\r\n19.2.1 Structure of a YACC program\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">We can observe from figure 19.1 that YACC provides a general tool for describing the input to a computer program. The YACC file specifies the structures of the input, along with code to be called to recognize each structure. YACC converts the specification into a subroutine that handles the input process handled by this subroutine.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\">The input subroutine produced by YACC calls a user-supplied routine to return the next basic input item. Thus, the user can specify his inp ut in terms of individual characters or in terms of higher level constructs such as names and numbers. The user-supplied routine may also handle idiomatic features such as comment and continuation conventions, which typically defy easy grammatical specification.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\">As in the case of a LEX program, the YACC is also a rule-based programming language. The YACC specification consists of the three parts: YACC declarations, translation rules and User- defined auxiliary procedures. The individual sections are delimited with a \u201c%%\u201d. The following is a skeleton of a YACC specification file.\u00a0<em>yacc declarations, and C declarations in <\/em><strong>%{ %}\u00a0<\/strong><strong>%%<\/strong><\/p>\r\n&nbsp;\r\n\r\n<em>translation rules<\/em>\r\n\r\n&nbsp;\r\n\r\n<strong>%%<\/strong>\r\n\r\n&nbsp;\r\n\r\n<em>user-defined auxiliary procedures<\/em>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">The declarations section consists of variables declarations that could be used in the program. The declaration section may be empty also. The next section is the translation rules section where we have grammar productions along with the actions. The productions correspond to the rules and the action corresponds to things that need to be done if the rule matches. The following is a sample of the translation rules<\/p>\r\n&nbsp;\r\n<table class=\"aligncenter\" border=\"1\">\r\n<tbody>\r\n<tr>\r\n<td><em>production<\/em>1<\/td>\r\n<td>{ <em>semantic action<\/em>1<\/td>\r\n<td>}<\/td>\r\n<td><\/td>\r\n<\/tr>\r\n<tr>\r\n<td><em>production<\/em>2<\/td>\r\n<td>{ <em>semantic action<\/em>2<\/td>\r\n<td>}<\/td>\r\n<td><\/td>\r\n<\/tr>\r\n<tr>\r\n<td>\u2026<\/td>\r\n<td><\/td>\r\n<td><\/td>\r\n<td><\/td>\r\n<\/tr>\r\n<tr>\r\n<td><em>production<\/em><em>n<\/em><\/td>\r\n<td>{ <em>semantic action<\/em><em>n<\/em> }<\/td>\r\n<td>\u00e0 (19.1)<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n&nbsp;\r\n\r\nIn YACC the productions are defined to accommodate multiple RHS\u00a0 for a single LHS\u00a0 non- terminal by separating the individual productions with the \u201c|\u201d symbol. However, the action that\u00a0 has to match the RHS is given immediately after the RHS of the production. The following is an example.\r\n\r\n&nbsp;\r\n<table class=\"aligncenter\" border=\"1\">\r\n<tbody>\r\n<tr>\r\n<td style=\"width: 567.063px\"><em>Nonterminal\u00a0\u00a0 <\/em><strong>:<\/strong> tokens\/nonterminals {<em> action <\/em>}<\/td>\r\n<td style=\"width: 93.0625px\"><\/td>\r\n<\/tr>\r\n<tr>\r\n<td style=\"width: 567.063px\"><strong>| <\/strong>tokens\/nonterminals { <em>action<\/em> }<\/td>\r\n<td style=\"width: 93.0625px\"><\/td>\r\n<\/tr>\r\n<tr>\r\n<td style=\"width: 567.063px\">\u2026<\/td>\r\n<td style=\"width: 93.0625px\"><\/td>\r\n<\/tr>\r\n<tr>\r\n<td style=\"width: 567.063px\"><strong>;<\/strong><\/td>\r\n<td style=\"width: 93.0625px\">\u00e0 (19.2)<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\r\n&nbsp;\r\n<p style=\"text-align: justify\">From equation (19.2) we can find that the tokens can be either single character or a sequence of characters. If the tokens are single characters then they can be used directly within productions, e.g. <strong>\u2018+\u2019<\/strong>. On the other hand, if the tokens have more number of characters then they are given a name and these named tokens must be declared first in the declaration part as given in equation (19.3).<\/p>\r\n&nbsp;\r\n\r\n&nbsp;\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td><strong>%token <\/strong><em>TokenName<\/em><\/td>\r\n<td>\u00e0 (19.3)<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n&nbsp;\r\n\r\nIn equation (19.1), semantic actions may refer to values of the <em>synthesized attributes<\/em> of terminals and non-terminals in a production:\r\n\r\n<em>X <\/em>:<em> Y<\/em>1<em> Y<\/em>2<em> Y<\/em>3 \u2026<em> Y<\/em><em>n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 { <em>action<\/em> }\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00e0 (19.4)\r\n\r\n&nbsp;\r\n\r\nIn (19.4) to associate a value to the LHS and RHS, the action part of the translation rule is used. To associate the values for X and Yi we could use \u201c<strong>$$\u201d<\/strong>to refer to the LHS value of the attribute of <em>X<\/em> while, \u201c<strong>$<\/strong><em>i<\/em>\u201d is used to refer to the value of the attribute of <em>Y<\/em><em>i<\/em> in the RHS of the production.\r\n\r\nConsider the following example of translation rule for the production,\r\n\r\n&nbsp;\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td>factor \u00e0 (expr)<\/td>\r\n<td>\u00e0 (19.5)<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n&nbsp;\r\n\r\nThe production of (19.5) is represented as follows in the production section:\r\n\r\n&nbsp;\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td><strong>factor : \u2018(\u2019 expr \u2018)\u2019 { $$=$2; }<\/strong><\/td>\r\n<td>\u00e0 (19.6)<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n&nbsp;\r\n\r\nFrom (19.6) we can observe that the production of (19.5) is converted, where the LHS variable remains as it is, the \u201c\u00e0\u201d is replaced with \u201c:\u201d. The RHS has two symbols \u2018(\u2018 and \u2018)\u2019, which are stated within quotes to indicate it is a constant. Now, the action section indicates, \u201c$$\u201d to specify this corresponds to the LHS of the production \u201cfactor\u201d and \u201c$2\u201d indicates that the value of the RHS variable is \u201c2\u201d. This is shown in figure 19.2\r\n\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\n<img class=\"size-full wp-image-108 aligncenter\" src=\"http:\/\/csp10.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-55.png\" alt=\"\" width=\"663\" height=\"251\" \/>\r\n\r\n19.2.2 YACC program entry point\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">yyparse() is the entry point of the YACC program. This function is called once from main() and this function repeatedly calls yylex() until parsing is completed. If a syntax error is encountered yyparse() calls a yyerror() function which is user specified. The yyparse() function returns 0 if all of the input was processed without any error and returns 1 if there is syntax error.<\/p>\r\n&nbsp;\r\n\r\nExample:\r\n\r\n&nbsp;\r\n\r\nint main() { return yyparse(); }\r\n\r\n19.2.3 YACC declarations\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">The YACC specification file contains declarations which have the information about tokens. The tokens are given names and is declared using \u2018<strong>%token<\/strong>\u2019. In this section, single-character tokens need not be declared. In addition, any name not declared as a token is assumed to be a non-terminal. The start symbol of a grammar is declared using \u2018<strong>%start<\/strong>\u2019 which is optional. The precedence and associativity associated with the operators are also stated in this section. The information that needs to be copied into the y.tab.c file is also stated, but they are enclosed in a pair of \u201c%\u201d.<\/p>\r\n&nbsp;\r\n\r\n19.2.4. YACC rules\r\n\r\n&nbsp;\r\n\r\nThe grammar productions are mapped as YACC rules. Consider the following grammar productions\r\n\r\n<em>A <\/em>\u00ae<em> B<\/em>1<em> B<\/em><em>2<\/em><em> \u2026 B<\/em><em>m<\/em>\r\n\r\n<em>A <\/em>\u00ae<em> C<\/em>1<em> C<\/em><em>2<\/em><em> \u2026 C<\/em><em>n<\/em>\r\n<table>\r\n<tbody>\r\n<tr>\r\n<td><em>A <\/em>\u00ae<em> D<\/em>1<em> D<\/em><em>2<\/em><em> \u2026 D<\/em><em>k<\/em><\/td>\r\n<td>\u00e0 (19.7)<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n&nbsp;\r\n\r\nThe productions in (19.7) is mapped into the following YACC rule <em>A <\/em>\u00ae<em> B<\/em>1<em> B<\/em><em>2<\/em><em> \u2026 B<\/em><em>m<\/em>\r\n\r\n&nbsp;\r\n\r\n<em>| C<\/em>1<em> C<\/em><em>2<\/em><em> \u2026 C<\/em><em>n<\/em>\r\n\r\n&nbsp;\r\n\r\n<em>| D<\/em>1<em> D<\/em><em>2<\/em><em> \u2026 D<\/em><em>k\u00a0<\/em>;\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">The multiple productions of A are merged into one rule with each production being separated from the other using the \u2018|\u2019 symbol. Each symbol that is available at the RHS of the production can have arbitrary actions in terms of C code, statements, actions, etc. For example, the grammar of (19.7) can have the following as the YACC rule.<\/p>\r\n&nbsp;\r\n\r\nA : B1 { printf(\u201cafter B1 \\n\u201d); x = 0; } B2 { x++; } B3\r\n\r\n&nbsp;\r\n<div>\r\n\r\nIn this example, B1 is to print something and initializes a variable \u2018x\u2019, B2 increments \u2018x\u2019 and B3 could do something with it.\r\n\r\n&nbsp;\r\n\r\n19.2.5 YACC Conflicts\r\n\r\n&nbsp;\r\n\r\nFor a YACC parser, the parser considers a left recursive grammar more efficient than right-recursive one. Conflicts arise when there is more than one way to proceed with parsing. The two types of conflicts that the YACC has to handle are shift-reduce and reduce-reduce. The YACC parser handles the shift-reduce conflict in favor of shift while the reduce\/reduce conflict is handled by reducing it with the first rule listed. However, the YACC parser avoids conflicts by specifying the operator precedence and associativity. The YACC parser also restructures the grammar to avoid the conflict. The YACC uses the y.output to identify reasons for the conflict and takes corrective measures to avoid the conflicts.\r\n\r\n&nbsp;\r\n\r\nThe following example discusses how the YACC parser associative precedence and associativity to avoid conflicts.\r\n\r\n&nbsp;\r\n\r\nBinary operators: <strong>%left<\/strong>, <strong>%right<\/strong>, <strong>%nonassoc<\/strong>:\r\n\r\n&nbsp;\r\n\r\n%left '+'\u00a0 '-'\r\n\r\n&nbsp;\r\n\r\n%left '*' \u00a0'\/'\r\n\r\n&nbsp;\r\n\r\n%right '^\u2018\r\n\r\n&nbsp;\r\n\r\nUnary operators: <strong>%prec<\/strong>\r\n\r\n&nbsp;\r\n\r\nWe can change the precedence of a rule to be that of the token specified. Consider the following:\r\n\r\n&nbsp;\r\n\r\n%left '+'\u00a0 '-'\r\n\r\n&nbsp;\r\n\r\n%left '*'\u00a0 '\/\u2018\r\n\r\n&nbsp;\r\n\r\nExpr: expr \u2018+\u2019 expr\r\n\r\n&nbsp;\r\n\r\n| \u2018\u2013\u2019 expr\u00a0\u00a0\u00a0\u00a0 %prec \u2018*\u2019\r\n\r\n&nbsp;\r\n\r\n| \u2026\r\n\r\n&nbsp;\r\n\r\nThe precedence indicates that for this grammar the unary \u2018-\u2019 has higher precedence where \u201cprec\u201d is a keyword.\r\n\r\n&nbsp;\r\n\r\nYACC follows a general approach to avoid conflicts and is listed below:\r\n\r\n&nbsp;\r\n\r\n1.\u00a0\u00a0\u00a0 Use \u201cyacc - v\u201d to generate the file <strong>y.output<\/strong>.\r\n\r\n<\/div>\r\n<ol start=\"2\">\r\n \t<li>Examine <strong>y.output<\/strong> to find parser states with conflicts.<\/li>\r\n \t<li>For each such state, examine the items to figure why the conflict is occurring.<\/li>\r\n \t<li>Transform the grammar to eliminate the conflict.<\/li>\r\n<\/ol>\r\n&nbsp;\r\n\r\nSteps 1 to 4 could be iterated as many times to eliminate and resolve conflict. Table 19.1 summarizes some reasons for conflict and the method to resolve them.\r\n\r\n&nbsp;\r\n<div>\r\n\r\nTable 19.1 Conflicts and solution\r\n\r\n&nbsp;\r\n<table class=\"aligncenter\" border=\"1\">\r\n<tbody>\r\n<tr>\r\n<td style=\"width: 318.063px\"><strong>Reason for conflict<\/strong><\/td>\r\n<td style=\"width: 342.063px\"><strong>Possible grammar transformation<\/strong><\/td>\r\n<\/tr>\r\n<tr>\r\n<td style=\"width: 318.063px\">Ambiguity with operators in expressions<\/td>\r\n<td style=\"width: 342.063px\">Specify associativity, precedence<\/td>\r\n<\/tr>\r\n<tr>\r\n<td style=\"width: 318.063px\">Error action<\/td>\r\n<td style=\"width: 342.063px\">Remove or eliminate offending error action<\/td>\r\n<\/tr>\r\n<tr>\r\n<td style=\"width: 318.063px\">Semantic action<\/td>\r\n<td style=\"width: 342.063px\">Remove the offending semantic action<\/td>\r\n<\/tr>\r\n<tr>\r\n<td style=\"width: 318.063px\">Insufficient look-ahead<\/td>\r\n<td style=\"width: 342.063px\">Expand the non-terminal involved<\/td>\r\n<\/tr>\r\n<tr>\r\n<td style=\"width: 318.063px\">Other<\/td>\r\n<td style=\"width: 342.063px\">Start all over<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n&nbsp;\r\n\r\n&nbsp;\r\n\r\n19.2.6 Error handling\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">Errors are handled by the YACC parser similar to the manner in which errors are handled in LR parsers. The \u201ctoken\u201d \u2018error\u2019 is reserved for error handling. This token can be used in rules or it could suggest places where errors might be detected and recovery can occur. Consider the following example where it indicates the error handling situation for an \u201cif- then\u201d grammar construct.<\/p>\r\n&nbsp;\r\n\r\n<em>Example<\/em>:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 stmt\u00a0 : IF '(' expr ')' stmt\r\n\r\n| IF '(' error ')' stmt\r\n\r\n| FOR \u2026\r\n\r\n&nbsp;\r\n\r\n| \u2026\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">The grammar production is defined for an error situation in the translation rules section. When an error occurs, the parser pops its stack until it enters a state where the token \u2018error\u2019 is legal and then behaves as if it saw the token \u2018error\u2019, performs the action encountered and resets the look-ahead token to the token that caused the error. If no \u2018error\u2019 rules are specified then the parser halts the processing.<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\">The YACC Parser remains in error state until three tokens are correctly read in and shifted. The parser prevents cascaded error messages. If an error is detected while parser in error state the parser ensures no error message is given and the input token causing the error is deleted. The following functions are provided in YACC for error handling in addition to the user-defined procedure yyerror()<\/p>\r\n&nbsp;\r\n\r\n\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <strong>yyerrok <\/strong>: - To force the parser to believe that an error has been fully recovered\r\n\r\n&nbsp;\r\n\r\n\u2022\u00a0\u00a0 <strong>yyclearin: -<\/strong> To clear the token that caused the error\r\n\r\n<\/div>\r\n&nbsp;\r\n<p style=\"text-align: justify\">The YACC parser tries to place the error tokens closer to the start symbol of the grammar to allow recovery without discarding all input. The YACC parser also places error tokens near terminal symbols to help permit a small amount of input to be discarded in the event of an error. Error messages are also issued by the YACC parser on finding an error. The parser calls a function <strong>void yye rror(char *s) ,<\/strong> where * s points to an error message which the user has provided and prints out the error messages. YACC provides more informative error messages using the \u201cint yychar\u201d which indicates the token number that causes the error by keeping track of line numbers, as well as any additional desired information.<\/p>\r\n&nbsp;\r\n\r\n<strong>19.3\u00a0\u00a0 Integration of LEX and YACC<\/strong>\r\n\r\n&nbsp;\r\n<p style=\"text-align: justify\">The LEX tool is typically used as a tokenizer and the YACC is a parser. To parse a programming language construct, the input needs to be tokenized. So, the YACC specification program works with a LEX file. The user specifications are written in the LEX file for tokenizing with a \u201c.l\u201d extension and is compiled by a LEX compiler to generate lex.yy.c. The user\u2019s YACC specification is compiled to generate a y.tab.c and y.tab.h. The three files, y.tab.c, y.tab.h, lex.yy.c are fed to a C compiler to generate the C output file and is shown in figure 19.3<\/p>\r\n&nbsp;\r\n<p style=\"text-align: justify\"><img class=\"size-full wp-image-109 aligncenter\" src=\"http:\/\/csp10.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-56.png\" alt=\"\" width=\"691\" height=\"400\" \/>.<\/p>\r\n<strong>Summary<\/strong>:\r\n\r\n&nbsp;\r\n\r\nIn this module we discussed the features of YACC and the need for YACC to perform parsing. The tool is more convenient to use than starting to code the parser from scratch. The subsequent module will discuss the next phase of the compiler, Semantic phase.","rendered":"<p>In this module we will learn to use the parser generator to parse a given string. We will learn the YACC parser tool.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>19.1 Parsers<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The LL(k) and LR(k) parsers discussed in the previous modules uses the grammar definition of a programming language and verifies whether an input string belongs to a grammar by constructing a parsing table. The construction of the parsing table is a tedious process as can be understood from the previous modules and hence we check whether it is possible for a tool to do the parsing action. We have already discussed the LEX tool to do the action of tokenizing. We also know that there is enough interaction between the lexical phase and the syntactic phase, where the lexer issues a token based on a request from the parser. Due to the interaction between the lexer and parser we could use a tool for the parser and integrate it with the lexer. The following are some of the tools available for parsing:<\/p>\n<p>&nbsp;<\/p>\n<ul>\n<li>ANTLR (ANother Tool for Language Recognition) tool generates LL(k) parsers<\/li>\n<li>YACC (Yet Another Compiler Compiler) generates LALR(1) parsers<\/li>\n<li>Bison \u2013 It is an improved version of YACC<\/li>\n<\/ul>\n<p>As bottom up parsers are preferred, YACC is a preferred tool for parsing.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>19.2 YACC Tool<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The overall working of the YACC tool is shown in figure 19.1. The YACC is a LALR parser and hence avoids shift\/reduce conflicts to a greater extent. The input program is a YACC specification program and is named with a \u201c.y\u201d extension. This program consists of the grammar rules of a programming language and the corresponding action that needs to be taken. This \u201c.y\u201d file is compiled using a YACC compiler. The output of the YACC compiler is a file named \u201cy.tab.c\u201d which can be compiled using a C compiler to generate an output file. The \u201c.y\u201d file in-turn would call the \u201c.l\u201d LEX specifications file to tokenize the given input.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-107 aligncenter\" src=\"http:\/\/csp10.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-54.png\" alt=\"\" width=\"564\" height=\"236\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-54.png 564w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-54-300x126.png 300w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-54-65x27.png 65w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-54-225x94.png 225w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-54-350x146.png 350w\" sizes=\"auto, (max-width: 564px) 100vw, 564px\" \/><\/p>\n<div>\n<p>19.2.1 Structure of a YACC program<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">We can observe from figure 19.1 that YACC provides a general tool for describing the input to a computer program. The YACC file specifies the structures of the input, along with code to be called to recognize each structure. YACC converts the specification into a subroutine that handles the input process handled by this subroutine.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The input subroutine produced by YACC calls a user-supplied routine to return the next basic input item. Thus, the user can specify his inp ut in terms of individual characters or in terms of higher level constructs such as names and numbers. The user-supplied routine may also handle idiomatic features such as comment and continuation conventions, which typically defy easy grammatical specification.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">As in the case of a LEX program, the YACC is also a rule-based programming language. The YACC specification consists of the three parts: YACC declarations, translation rules and User- defined auxiliary procedures. The individual sections are delimited with a \u201c%%\u201d. The following is a skeleton of a YACC specification file.\u00a0<em>yacc declarations, and C declarations in <\/em><strong>%{ %}\u00a0<\/strong><strong>%%<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p><em>translation rules<\/em><\/p>\n<p>&nbsp;<\/p>\n<p><strong>%%<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p><em>user-defined auxiliary procedures<\/em><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The declarations section consists of variables declarations that could be used in the program. The declaration section may be empty also. The next section is the translation rules section where we have grammar productions along with the actions. The productions correspond to the rules and the action corresponds to things that need to be done if the rule matches. The following is a sample of the translation rules<\/p>\n<p>&nbsp;<\/p>\n<table class=\"aligncenter\">\n<tbody>\n<tr>\n<td><em>production<\/em>1<\/td>\n<td>{ <em>semantic action<\/em>1<\/td>\n<td>}<\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><em>production<\/em>2<\/td>\n<td>{ <em>semantic action<\/em>2<\/td>\n<td>}<\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td>\u2026<\/td>\n<td><\/td>\n<td><\/td>\n<td><\/td>\n<\/tr>\n<tr>\n<td><em>production<\/em><em>n<\/em><\/td>\n<td>{ <em>semantic action<\/em><em>n<\/em> }<\/td>\n<td>\u00e0 (19.1)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p>In YACC the productions are defined to accommodate multiple RHS\u00a0 for a single LHS\u00a0 non- terminal by separating the individual productions with the \u201c|\u201d symbol. However, the action that\u00a0 has to match the RHS is given immediately after the RHS of the production. The following is an example.<\/p>\n<p>&nbsp;<\/p>\n<table class=\"aligncenter\">\n<tbody>\n<tr>\n<td style=\"width: 567.063px\"><em>Nonterminal\u00a0\u00a0 <\/em><strong>:<\/strong> tokens\/nonterminals {<em> action <\/em>}<\/td>\n<td style=\"width: 93.0625px\"><\/td>\n<\/tr>\n<tr>\n<td style=\"width: 567.063px\"><strong>| <\/strong>tokens\/nonterminals { <em>action<\/em> }<\/td>\n<td style=\"width: 93.0625px\"><\/td>\n<\/tr>\n<tr>\n<td style=\"width: 567.063px\">\u2026<\/td>\n<td style=\"width: 93.0625px\"><\/td>\n<\/tr>\n<tr>\n<td style=\"width: 567.063px\"><strong>;<\/strong><\/td>\n<td style=\"width: 93.0625px\">\u00e0 (19.2)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">From equation (19.2) we can find that the tokens can be either single character or a sequence of characters. If the tokens are single characters then they can be used directly within productions, e.g. <strong>\u2018+\u2019<\/strong>. On the other hand, if the tokens have more number of characters then they are given a name and these named tokens must be declared first in the declaration part as given in equation (19.3).<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<table>\n<tbody>\n<tr>\n<td><strong>%token <\/strong><em>TokenName<\/em><\/td>\n<td>\u00e0 (19.3)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p>In equation (19.1), semantic actions may refer to values of the <em>synthesized attributes<\/em> of terminals and non-terminals in a production:<\/p>\n<p><em>X <\/em>:<em> Y<\/em>1<em> Y<\/em>2<em> Y<\/em>3 \u2026<em> Y<\/em><em>n<\/em>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 { <em>action<\/em> }\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 \u00e0 (19.4)<\/p>\n<p>&nbsp;<\/p>\n<p>In (19.4) to associate a value to the LHS and RHS, the action part of the translation rule is used. To associate the values for X and Yi we could use \u201c<strong>$$\u201d<\/strong>to refer to the LHS value of the attribute of <em>X<\/em> while, \u201c<strong>$<\/strong><em>i<\/em>\u201d is used to refer to the value of the attribute of <em>Y<\/em><em>i<\/em> in the RHS of the production.<\/p>\n<p>Consider the following example of translation rule for the production,<\/p>\n<p>&nbsp;<\/p>\n<table>\n<tbody>\n<tr>\n<td>factor \u00e0 (expr)<\/td>\n<td>\u00e0 (19.5)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p>The production of (19.5) is represented as follows in the production section:<\/p>\n<p>&nbsp;<\/p>\n<table>\n<tbody>\n<tr>\n<td><strong>factor : \u2018(\u2019 expr \u2018)\u2019 { $$=$2; }<\/strong><\/td>\n<td>\u00e0 (19.6)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p>From (19.6) we can observe that the production of (19.5) is converted, where the LHS variable remains as it is, the \u201c\u00e0\u201d is replaced with \u201c:\u201d. The RHS has two symbols \u2018(\u2018 and \u2018)\u2019, which are stated within quotes to indicate it is a constant. Now, the action section indicates, \u201c$$\u201d to specify this corresponds to the LHS of the production \u201cfactor\u201d and \u201c$2\u201d indicates that the value of the RHS variable is \u201c2\u201d. This is shown in figure 19.2<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-108 aligncenter\" src=\"http:\/\/csp10.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-55.png\" alt=\"\" width=\"663\" height=\"251\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-55.png 663w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-55-300x114.png 300w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-55-65x25.png 65w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-55-225x85.png 225w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-55-350x133.png 350w\" sizes=\"auto, (max-width: 663px) 100vw, 663px\" \/><\/p>\n<p>19.2.2 YACC program entry point<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">yyparse() is the entry point of the YACC program. This function is called once from main() and this function repeatedly calls yylex() until parsing is completed. If a syntax error is encountered yyparse() calls a yyerror() function which is user specified. The yyparse() function returns 0 if all of the input was processed without any error and returns 1 if there is syntax error.<\/p>\n<p>&nbsp;<\/p>\n<p>Example:<\/p>\n<p>&nbsp;<\/p>\n<p>int main() { return yyparse(); }<\/p>\n<p>19.2.3 YACC declarations<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The YACC specification file contains declarations which have the information about tokens. The tokens are given names and is declared using \u2018<strong>%token<\/strong>\u2019. In this section, single-character tokens need not be declared. In addition, any name not declared as a token is assumed to be a non-terminal. The start symbol of a grammar is declared using \u2018<strong>%start<\/strong>\u2019 which is optional. The precedence and associativity associated with the operators are also stated in this section. The information that needs to be copied into the y.tab.c file is also stated, but they are enclosed in a pair of \u201c%\u201d.<\/p>\n<p>&nbsp;<\/p>\n<p>19.2.4. YACC rules<\/p>\n<p>&nbsp;<\/p>\n<p>The grammar productions are mapped as YACC rules. Consider the following grammar productions<\/p>\n<p><em>A <\/em>\u00ae<em> B<\/em>1<em> B<\/em><em>2<\/em><em> \u2026 B<\/em><em>m<\/em><\/p>\n<p><em>A <\/em>\u00ae<em> C<\/em>1<em> C<\/em><em>2<\/em><em> \u2026 C<\/em><em>n<\/em><\/p>\n<table>\n<tbody>\n<tr>\n<td><em>A <\/em>\u00ae<em> D<\/em>1<em> D<\/em><em>2<\/em><em> \u2026 D<\/em><em>k<\/em><\/td>\n<td>\u00e0 (19.7)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p>The productions in (19.7) is mapped into the following YACC rule <em>A <\/em>\u00ae<em> B<\/em>1<em> B<\/em><em>2<\/em><em> \u2026 B<\/em><em>m<\/em><\/p>\n<p>&nbsp;<\/p>\n<p><em>| C<\/em>1<em> C<\/em><em>2<\/em><em> \u2026 C<\/em><em>n<\/em><\/p>\n<p>&nbsp;<\/p>\n<p><em>| D<\/em>1<em> D<\/em><em>2<\/em><em> \u2026 D<\/em><em>k\u00a0<\/em>;<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The multiple productions of A are merged into one rule with each production being separated from the other using the \u2018|\u2019 symbol. Each symbol that is available at the RHS of the production can have arbitrary actions in terms of C code, statements, actions, etc. For example, the grammar of (19.7) can have the following as the YACC rule.<\/p>\n<p>&nbsp;<\/p>\n<p>A : B1 { printf(\u201cafter B1 \\n\u201d); x = 0; } B2 { x++; } B3<\/p>\n<p>&nbsp;<\/p>\n<div>\n<p>In this example, B1 is to print something and initializes a variable \u2018x\u2019, B2 increments \u2018x\u2019 and B3 could do something with it.<\/p>\n<p>&nbsp;<\/p>\n<p>19.2.5 YACC Conflicts<\/p>\n<p>&nbsp;<\/p>\n<p>For a YACC parser, the parser considers a left recursive grammar more efficient than right-recursive one. Conflicts arise when there is more than one way to proceed with parsing. The two types of conflicts that the YACC has to handle are shift-reduce and reduce-reduce. The YACC parser handles the shift-reduce conflict in favor of shift while the reduce\/reduce conflict is handled by reducing it with the first rule listed. However, the YACC parser avoids conflicts by specifying the operator precedence and associativity. The YACC parser also restructures the grammar to avoid the conflict. The YACC uses the y.output to identify reasons for the conflict and takes corrective measures to avoid the conflicts.<\/p>\n<p>&nbsp;<\/p>\n<p>The following example discusses how the YACC parser associative precedence and associativity to avoid conflicts.<\/p>\n<p>&nbsp;<\/p>\n<p>Binary operators: <strong>%left<\/strong>, <strong>%right<\/strong>, <strong>%nonassoc<\/strong>:<\/p>\n<p>&nbsp;<\/p>\n<p>%left &#8216;+&#8217;\u00a0 &#8216;-&#8216;<\/p>\n<p>&nbsp;<\/p>\n<p>%left &#8216;*&#8217; \u00a0&#8216;\/&#8217;<\/p>\n<p>&nbsp;<\/p>\n<p>%right &#8216;^\u2018<\/p>\n<p>&nbsp;<\/p>\n<p>Unary operators: <strong>%prec<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p>We can change the precedence of a rule to be that of the token specified. Consider the following:<\/p>\n<p>&nbsp;<\/p>\n<p>%left &#8216;+&#8217;\u00a0 &#8216;-&#8216;<\/p>\n<p>&nbsp;<\/p>\n<p>%left &#8216;*&#8217;\u00a0 &#8216;\/\u2018<\/p>\n<p>&nbsp;<\/p>\n<p>Expr: expr \u2018+\u2019 expr<\/p>\n<p>&nbsp;<\/p>\n<p>| \u2018\u2013\u2019 expr\u00a0\u00a0\u00a0\u00a0 %prec \u2018*\u2019<\/p>\n<p>&nbsp;<\/p>\n<p>| \u2026<\/p>\n<p>&nbsp;<\/p>\n<p>The precedence indicates that for this grammar the unary \u2018-\u2019 has higher precedence where \u201cprec\u201d is a keyword.<\/p>\n<p>&nbsp;<\/p>\n<p>YACC follows a general approach to avoid conflicts and is listed below:<\/p>\n<p>&nbsp;<\/p>\n<p>1.\u00a0\u00a0\u00a0 Use \u201cyacc &#8211; v\u201d to generate the file <strong>y.output<\/strong>.<\/p>\n<\/div>\n<ol start=\"2\">\n<li>Examine <strong>y.output<\/strong> to find parser states with conflicts.<\/li>\n<li>For each such state, examine the items to figure why the conflict is occurring.<\/li>\n<li>Transform the grammar to eliminate the conflict.<\/li>\n<\/ol>\n<p>&nbsp;<\/p>\n<p>Steps 1 to 4 could be iterated as many times to eliminate and resolve conflict. Table 19.1 summarizes some reasons for conflict and the method to resolve them.<\/p>\n<p>&nbsp;<\/p>\n<div>\n<p>Table 19.1 Conflicts and solution<\/p>\n<p>&nbsp;<\/p>\n<table class=\"aligncenter\">\n<tbody>\n<tr>\n<td style=\"width: 318.063px\"><strong>Reason for conflict<\/strong><\/td>\n<td style=\"width: 342.063px\"><strong>Possible grammar transformation<\/strong><\/td>\n<\/tr>\n<tr>\n<td style=\"width: 318.063px\">Ambiguity with operators in expressions<\/td>\n<td style=\"width: 342.063px\">Specify associativity, precedence<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 318.063px\">Error action<\/td>\n<td style=\"width: 342.063px\">Remove or eliminate offending error action<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 318.063px\">Semantic action<\/td>\n<td style=\"width: 342.063px\">Remove the offending semantic action<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 318.063px\">Insufficient look-ahead<\/td>\n<td style=\"width: 342.063px\">Expand the non-terminal involved<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 318.063px\">Other<\/td>\n<td style=\"width: 342.063px\">Start all over<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>19.2.6 Error handling<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">Errors are handled by the YACC parser similar to the manner in which errors are handled in LR parsers. The \u201ctoken\u201d \u2018error\u2019 is reserved for error handling. This token can be used in rules or it could suggest places where errors might be detected and recovery can occur. Consider the following example where it indicates the error handling situation for an \u201cif- then\u201d grammar construct.<\/p>\n<p>&nbsp;<\/p>\n<p><em>Example<\/em>:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 stmt\u00a0 : IF &#8216;(&#8216; expr &#8216;)&#8217; stmt<\/p>\n<p>| IF &#8216;(&#8216; error &#8216;)&#8217; stmt<\/p>\n<p>| FOR \u2026<\/p>\n<p>&nbsp;<\/p>\n<p>| \u2026<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The grammar production is defined for an error situation in the translation rules section. When an error occurs, the parser pops its stack until it enters a state where the token \u2018error\u2019 is legal and then behaves as if it saw the token \u2018error\u2019, performs the action encountered and resets the look-ahead token to the token that caused the error. If no \u2018error\u2019 rules are specified then the parser halts the processing.<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The YACC Parser remains in error state until three tokens are correctly read in and shifted. The parser prevents cascaded error messages. If an error is detected while parser in error state the parser ensures no error message is given and the input token causing the error is deleted. The following functions are provided in YACC for error handling in addition to the user-defined procedure yyerror()<\/p>\n<p>&nbsp;<\/p>\n<p>\u00b7\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <strong>yyerrok <\/strong>: &#8211; To force the parser to believe that an error has been fully recovered<\/p>\n<p>&nbsp;<\/p>\n<p>\u2022\u00a0\u00a0 <strong>yyclearin: &#8211;<\/strong> To clear the token that caused the error<\/p>\n<\/div>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The YACC parser tries to place the error tokens closer to the start symbol of the grammar to allow recovery without discarding all input. The YACC parser also places error tokens near terminal symbols to help permit a small amount of input to be discarded in the event of an error. Error messages are also issued by the YACC parser on finding an error. The parser calls a function <strong>void yye rror(char *s) ,<\/strong> where * s points to an error message which the user has provided and prints out the error messages. YACC provides more informative error messages using the \u201cint yychar\u201d which indicates the token number that causes the error by keeping track of line numbers, as well as any additional desired information.<\/p>\n<p>&nbsp;<\/p>\n<p><strong>19.3\u00a0\u00a0 Integration of LEX and YACC<\/strong><\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\">The LEX tool is typically used as a tokenizer and the YACC is a parser. To parse a programming language construct, the input needs to be tokenized. So, the YACC specification program works with a LEX file. The user specifications are written in the LEX file for tokenizing with a \u201c.l\u201d extension and is compiled by a LEX compiler to generate lex.yy.c. The user\u2019s YACC specification is compiled to generate a y.tab.c and y.tab.h. The three files, y.tab.c, y.tab.h, lex.yy.c are fed to a C compiler to generate the C output file and is shown in figure 19.3<\/p>\n<p>&nbsp;<\/p>\n<p style=\"text-align: justify\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-109 aligncenter\" src=\"http:\/\/csp10.epgpbooks.inflibnet.ac.in\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-56.png\" alt=\"\" width=\"691\" height=\"400\" srcset=\"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-56.png 691w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-56-300x174.png 300w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-56-65x38.png 65w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-56-225x130.png 225w, https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-content\/uploads\/sites\/50\/2018\/07\/Untitled-56-350x203.png 350w\" sizes=\"auto, (max-width: 691px) 100vw, 691px\" \/>.<\/p>\n<p><strong>Summary<\/strong>:<\/p>\n<p>&nbsp;<\/p>\n<p>In this module we discussed the features of YACC and the need for YACC to perform parsing. The tool is more convenient to use than starting to code the parser from scratch. The subsequent module will discuss the next phase of the compiler, Semantic phase.<\/p>\n","protected":false},"author":4,"menu_order":19,"template":"","meta":{"_acf_changed":false,"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["dr-rajeswari-sridhar"],"pb_section_license":""},"chapter-type":[],"contributor":[59],"license":[],"class_list":["post-106","chapter","type-chapter","status-publish","hentry","contributor-dr-rajeswari-sridhar"],"part":3,"_links":{"self":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/pressbooks\/v2\/chapters\/106","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/wp\/v2\/users\/4"}],"version-history":[{"count":2,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/pressbooks\/v2\/chapters\/106\/revisions"}],"predecessor-version":[{"id":111,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/pressbooks\/v2\/chapters\/106\/revisions\/111"}],"part":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/pressbooks\/v2\/chapters\/106\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/wp\/v2\/media?parent=106"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/pressbooks\/v2\/chapter-type?post=106"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/wp\/v2\/contributor?post=106"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp10\/wp-json\/wp\/v2\/license?post=106"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}