README.BTYACC revision 264790
1264790Sbapt-- $Id: README.BTYACC,v 1.1 2014/03/25 19:21:31 Tom.Shields Exp $ 2264790Sbapt 3264790SbaptThe original README from btyacc is below. 4264790Sbapt 5264790SbaptThe backtracking enhancements to byacc have been merged into Thomas Dickey's 6264790Sbaptbyacc baseline. 7264790Sbapt 8264790SbaptThe %include and %define/%ifdef enhancements described below are not currently 9264790Sbaptincorporated. 10264790Sbapt 11264790Sbapt------------------------------------------------------------------------------- 12264790Sbapt BTYACC -- backtracking yacc 13264790Sbapt =========================== 14264790Sbapt 15264790SbaptBTYACC was created by Chris Dodd using ideas from many 16264790Sbaptplaces and lots of code from the Berkeley Yacc 17264790Sbaptdistribution, which is a public domain yacc clone put 18264790Sbapttogether by the good folks at Berkeley. This code is 19264790Sbaptdistributed with NO WARRANTY and is public domain. 20264790SbaptIt is certain to contain bugs, which you should 21264790Sbaptreport to: chrisd@collins.com. 22264790Sbapt 23264790SbaptVadim Maslov of Siber Systems <vadik@siber.com> 24264790Sbaptconsiderably modified BTYACC to make it suitable 25264790Sbaptfor production environment. 26264790Sbapt 27264790SbaptSeveral people have suggested bug fixes that 28264790Sbaptwere incorporated into BtYacc. 29264790Sbapt 30264790SbaptSee the README.BYACC files for more about 31264790SbaptBerkeley Yacc and other sources of info. 32264790Sbapt 33264790Sbapthttp://www.siber.com/btyacc/ is the current home of BtYacc. 34264790SbaptIt is provided courtesy of Siber Systems http://www.siber.com/. 35264790Sbapt 36264790Sbapt 37264790Sbapt Version 3.0 changes 38264790Sbapt ------------------- 39264790Sbapt by Vadim Maslov 40264790Sbapt 41264790SbaptChanges mostly occurred in btyaccpa.ske file that 42264790Sbaptcontains the parsing shift/reduce/backtrack algorithm. 43264790Sbapt 44264790SbaptVersion 3.0 innovations focus on: 45264790Sbapt- text position computation and propagation, 46264790Sbapt- industrial-strength error processing and recovery. 47264790Sbapt 48264790Sbapt 49264790Sbapt** Added mechanism for computing and propagating 50264790Sbapttext position of tokens and non-terminals. 51264790Sbapt 52264790SbaptCompilers often need to build AST trees such that every node 53264790Sbaptin a tree can relate to the parsed program source it came from. 54264790SbaptThe following applications are very likely to need this: 55264790Sbapt- debuggers that show actual source of the debugged program, 56264790Sbapt- source-to-source translators that want 57264790Sbapt unchanged parts of the tree to generate the unchanged code. 58264790Sbapt 59264790SbaptThe new YYPOSN mechanism added in this version of BtYacc 60264790Sbapthelps you in automating the text position computation 61264790Sbaptand in assigning the computed text positions to the AST. 62264790SbaptThis mechanism is successfully used in commercial 63264790Sbaptparsers and source-to-source translators. 64264790Sbapt 65264790SbaptIn standard Yaccs every token and every non-terminal 66264790Sbapthas an YYSTYPE semantic value attached to it. 67264790SbaptIn this new version every token and every non-terminal 68264790Sbaptalso has an YYPOSN text position attached to it. 69264790SbaptYYPOSN is a user-defined type that can be anything and 70264790Sbaptthat has a meaning of text position attached to 71264790Sbapttoken or non-terminal. 72264790Sbapt 73264790SbaptIn addition to semantic value stack BtYacc now maintains 74264790Sbapttext position stack. Behavior of the text position stack 75264790Sbaptis similar to the behavior of the semantic value stack. 76264790Sbapt 77264790SbaptIf using text position mechanism, 78264790Sbaptyou need to define the following: 79264790Sbapt 80264790SbaptYYPOSN Preprocessor variable that contains C/C++ type of 81264790Sbapt the text position attached to 82264790Sbapt every token and non-terminal. 83264790Sbapt 84264790Sbaptyyposn Global variable of type YYPOSN. 85264790Sbapt The lexer must assign text position of 86264790Sbapt the returned token to yyposn, just like it assigns 87264790Sbapt semantic value of the returned token to yylval. 88264790Sbapt 89264790SbaptYYREDUCEPOSNFUNC 90264790Sbapt Preprocessor variable that points to function that 91264790Sbapt is called after the grammar rule reduction 92264790Sbapt to reduce text positions located on the stack. 93264790Sbapt 94264790Sbapt This function is called by BtYacc to reduce text 95264790Sbapt positions. The function is called immediately after 96264790Sbapt the regular rule reduction occurs. 97264790Sbapt 98264790Sbapt The function has the following prototype: 99264790Sbapt void ReducePosn(YYPOSN &ret, 100264790Sbapt YYPOSN *terms, 101264790Sbapt YYSTYPE *term_vals, 102264790Sbapt int term_no, 103264790Sbapt int stk_pos, 104264790Sbapt int yychar, 105264790Sbapt YYPOSN &yyposn, 106264790Sbapt UserType extra); 107264790Sbapt 108264790Sbapt The function arguments are: 109264790Sbapt - ret 110264790Sbapt Reference to the text position returned by 111264790Sbapt the rule. The function must write the computed 112264790Sbapt text position returned by the rule to ret. 113264790Sbapt This is analogue of the $$ semantic value. 114264790Sbapt 115264790Sbapt - term_posns 116264790Sbapt Array of the right-hand side rule components 117264790Sbapt YYPOSN text positions. These are analogues of 118264790Sbapt $1, $2, ..., $N in the text position world. 119264790Sbapt 120264790Sbapt - term_vals 121264790Sbapt Array of the right-hand side (RHS) rule components 122264790Sbapt YYSTYPE values. These are the $1,...,$N themselves. 123264790Sbapt 124264790Sbapt - term_no 125264790Sbapt Number of the components in RHS of the reduced rule. 126264790Sbapt Equal to size of arrays term_posns and term_vals. 127264790Sbapt Also equal to N in $1,...,$N in the reduced rule. 128264790Sbapt 129264790Sbapt - stk_pos 130264790Sbapt YYSTYPE/YYPOSN stack position before the reduction. 131264790Sbapt 132264790Sbapt - yychar 133264790Sbapt Lookahead token that immediately follows 134264790Sbapt the reduced RHS components. 135264790Sbapt 136264790Sbapt - yyposn 137264790Sbapt YYPOSN of the token that immediately follows 138264790Sbapt the reduced RHS components. 139264790Sbapt 140264790Sbapt - extra 141264790Sbapt User-defined extra argument passed to ReducePosn. 142264790Sbapt 143264790Sbapt Typically this function extracts text positions from 144264790Sbapt the right-hand side rule components and either 145264790Sbapt assigns them to the returned $$ structure/tree or 146264790Sbapt if no $$ value is returned, puts them into 147264790Sbapt the ret text position from where 148264790Sbapt it will be picked up by the later reduced rules. 149264790Sbapt 150264790SbaptYYREDUCEPOSNFUNCARG 151264790Sbapt Extra user-defined argument passed to 152264790Sbapt the ReducePosn function. This argument can use 153264790Sbapt any variables defined in btyaccpa.ske. 154264790Sbapt 155264790Sbapt 156264790Sbapt** Added code to btyaccpa.ske that automatically cleans up 157264790Sbaptsemantic semantic values and text positions of tokens 158264790Sbaptand non-terminals that are discarded and deleted as 159264790Sbapta result of error processing. 160264790Sbapt 161264790SbaptIn the previous versions the discarded token and non-terminal 162264790Sbaptsemantic values were not cleaned that caused quite severe 163264790Sbaptleaks. The only way to fix it was to add garbage collection 164264790Sbaptto YYSTYPE class. 165264790Sbapt 166264790SbaptNow BtYacc skeleton calls delete functions for semantic 167264790Sbaptvalues and positions of the discarded tokens and 168264790Sbaptnon-terminals. 169264790Sbapt 170264790SbaptYou need to define the following functions that BtYacc 171264790Sbaptcalls when it needs to delete semantic value or text position. 172264790Sbapt 173264790SbaptYYDELETEVAL 174264790Sbapt User-defined function that is called by BtYacc 175264790Sbapt to delete semantic value of the token or non-terminal. 176264790Sbapt 177264790Sbapt The user-defined function must have the prototype: 178264790Sbapt void DeleteYYval(YYSTYPE v, int type); 179264790Sbapt v is semantic value to delete, 180264790Sbapt type is one of the following: 181264790Sbapt 0 discarding token 182264790Sbapt 1 discarding state 183264790Sbapt 2 cleaning up stack when aborting 184264790Sbapt 185264790SbaptYYDELETEPOSN 186264790Sbapt User-defined function that is called by BtYacc 187264790Sbapt to delete text position of the token or non-terminal. 188264790Sbapt 189264790Sbapt The user-defined function must have the prototype: 190264790Sbapt void DeleteYYposn(YYPOSN p, int type); 191264790Sbapt v is semantic value to delete, 192264790Sbapt type is one of the following: 193264790Sbapt 0 discarding token 194264790Sbapt 1 discarding state 195264790Sbapt 2 cleaning up stack when aborting 196264790Sbapt 197264790Sbapt 198264790Sbapt** User can define "detailed" syntax error processing 199264790Sbaptfunction that reports an *exact* position of 200264790Sbaptthe token that caused the error. 201264790Sbapt 202264790SbaptIf you define preprocessor variable YYERROR_DETAILED in 203264790Sbaptyour grammar then you need define the following 204264790Sbapterror processing function: 205264790Sbapt 206264790Sbaptvoid yyerror_detailed(char *text, 207264790Sbapt int errt, 208264790Sbapt YYSTYPE &errt_value, 209264790Sbapt YYPOSN &errt_posn); 210264790Sbapt 211264790SbaptIt receives the following arguments: 212264790Sbapttext Error message. 213264790Sbapterrt Code of the token that caused the error. 214264790Sbapterrt_value Value of the token that caused the error. 215264790Sbapterrt_posn Text position of token that caused error. 216264790Sbapt 217264790Sbapt 218264790Sbapt** Dropped compatibility with C. 219264790Sbapt 220264790SbaptCompatibility with C became increasingly difficult 221264790Sbaptto maintain as new features were added to btyaccpa.ske. 222264790SbaptSo we dropped it. If anybody wants to make the new version 223264790Sbaptcompatible with C, we would gladly accept the changes. 224264790Sbapt 225264790SbaptMeanwhile we expect that you use C++ to write grammar 226264790Sbaptactions and everything else in grammar files. 227264790SbaptSince C is (in a sense) subset of C++, your C-based 228264790Sbaptgrammar may work if you use C++ compiler to compile it. 229264790Sbapt 230264790Sbapt Version 3.0 bugs fixed 231264790Sbapt ---------------------- 232264790Sbapt 233264790SbaptMatthias Meixner <meixner@mes.th-darmstadt.de> fixed a bug: 234264790SbaptBtYacc does not correctly handle typenames, if one typename 235264790Sbaptis a prefix of another one and if this type is used after 236264790Sbaptthe longer one. In this case BTYacc produces invalid code. 237264790Sbapt 238264790Sbapt 239264790Sbapt Version 2.1 changes 240264790Sbapt ------------------- 241264790Sbapt by Vadim Maslov 242264790Sbapt 243264790Sbapt** Added preprocessor statements to BtYacc that are similar 244264790Sbaptin function and behavior to C/C++ preprocessor statements. 245264790Sbapt 246264790SbaptThese statements are used to: 247264790Sbapt 248264790Sbapt- Introduce modularity into a grammar by breaking it 249264790Sbapt into several *.y files and assembling different 250264790Sbapt grammars from the *.y modules using %include and %ifdef. 251264790Sbapt 252264790Sbapt- Have several versions of the same grammar 253264790Sbapt by using %ifdef and $endif. 254264790Sbapt 255264790Sbapt- To include automatically generated grammar fragment. 256264790Sbapt For instance, we use %include to include 257264790Sbapt automatically generated list of tokens. 258264790Sbapt 259264790SbaptPreprocessor statements are: 260264790Sbapt 261264790Sbapt%define <var-name> 262264790Sbapt Define preprocessor variable named <var-name>. 263264790Sbapt 264264790Sbapt%ifdef <var-name> 265264790Sbapt If preprocessor variable named <var-name> 266264790Sbapt is defined by %define, then process the text from 267264790Sbapt this %ifdef to the closing %endif. 268264790Sbapt 269264790Sbapt%endif 270264790Sbapt Closing bracket for %ifdef preprocessor statement. 271264790Sbapt Only one nesting level of %ifdef-%endif is allowed. 272264790Sbapt 273264790Sbapt%include <file-name> 274264790Sbapt Process contents of the file named <file-name>. 275264790Sbapt If <file-name> is a relative name, it is looked up 276264790Sbapt in a directory in which btyacc was started. 277264790Sbapt Only one nesting level of %include is allowed. 278264790Sbapt 279264790Sbapt 280264790Sbapt Version 2.0 changes 281264790Sbapt ------------------- 282264790Sbapt by Vadim Maslov 283264790Sbapt 284264790Sbapt 285264790Sbapt** Changed 16-bit short numbers to 32-bit int numbers in 286264790Sbaptgrammar tables, so that huge grammar tables (tables that 287264790Sbaptare larger than 32768 elements) resulting from huge 288264790Sbaptgrammars (Cobol grammar, for instance) can work correctly. 289264790SbaptYou need to have 32-bit integer to index table bigger than 290264790Sbapt32768 elements, 16-bit integer is not enough. 291264790Sbapt 292264790SbaptThe original BtYacc just generated non-working tables 293264790Sbaptlarger than 32768 elements without even notifying about 294264790Sbaptthe table overflow. 295264790Sbapt 296264790Sbapt 297264790Sbapt** Make error recovery work correctly when error happens 298264790Sbaptwhile processing nested conflicts. Original BtYacc could 299264790Sbaptinfinitely cycle in certain situations that involved error 300264790Sbaptrecovery while in nested conflict. 301264790Sbapt 302264790SbaptMore detailed explanation: when we have nested conflicts 303264790Sbapt(conflict that happens while trial-processing another 304264790Sbaptconflict), it leads btyacc into NP-complete searching of 305264790Sbaptconflict tree. The ultimate goal is YYVALID operator that 306264790Sbaptselects a particular branch of that tree as a valid one. 307264790Sbapt 308264790SbaptIf no YYVALID is found on the tree, then error recovery 309264790Sbapttakes over. The problem with this is that error recovery 310264790Sbaptis started in the same state context that exists on the 311264790Sbaptlast surveyed branch of the conflict tree. Sometimes this 312264790Sbaptlast branch may be of zero length and it results in 313264790Sbaptrecovering to exactly the same state as existed before 314264790Sbaptentering the conflict. BtYacc cycles then. 315264790Sbapt 316264790SbaptWe solved this problem by memorizing the longest path in 317264790Sbaptthe conflict tree while browsing it. If we ever get into 318264790Sbapterror recovery, we restore state that existed on the 319264790Sbaptlongest path. Effectively we say: if we have an error, 320264790Sbaptlet us move forward as far as we possibly could while we 321264790Sbaptwere browsing the conflict tree. 322264790Sbapt 323264790Sbapt 324264790Sbapt** Introduce YYVALID_NESTED operation in addition to 325264790Sbaptsimply YYVALID. When we have a nested conflict (conflict 326264790Sbaptwhile processing in trial mode for another conflict), we 327264790Sbaptwant to relate YYVALID to a particular level of conflict 328264790Sbaptbeing in trial. 329264790Sbapt 330264790SbaptSince we mostly anticipate only 2-level nested conflicts 331264790SbaptYYVALID_NESTED tells the parser to satisfy only the 332264790Sbaptinternal conflict. Therefore, in 1-level conflict 333264790Sbaptsituation YYVALID_NESTED acts like a regular YYVALID, but 334264790Sbaptin 2-level conflict it is a no-op and the other YYVALID 335264790Sbaptfor outer conflict will be searched for. 336264790Sbapt 337264790Sbapt 338264790Sbapt** Improved handling of situation where /tmp directory is 339264790Sbaptmissing. Original btyacc just died quietly when /tmp 340264790Sbaptdirectory was missing. We added code that states the 341264790Sbaptproblem explicitly. While on UNIX /tmp directory is always 342264790Sbaptpresent, it may be missing on WIN32 systems, therefore 343264790Sbaptdiagnosing this situation is important. 344264790Sbapt 345264790Sbapt 346264790Sbapt Version 1.0 changes: BackTracking 347264790Sbapt ================================= 348264790Sbapt by Chris Dodd 349264790Sbapt 350264790SbaptBTYACC is a modified version of yacc that supports 351264790Sbaptautomatic backtracking and semantic disambiguation to 352264790Sbaptparse ambiguous grammars, as well as syntactic sugar for 353264790Sbaptinherited attributes (which tend to introduce conflicts). 354264790SbaptWhenever a btyacc generated parser runs into a 355264790Sbaptshift-reduce or reduce-reduce error in the parse table, it 356264790Sbaptremembers the current parse point (yacc stack and input 357264790Sbaptstream state), and goes into trial parse mode. It then 358264790Sbaptcontinues parsing, ignoring most rule actions. If it runs 359264790Sbaptinto an error (either through the parse table or through 360264790Sbaptan action calling YYERROR), it backtracks to the most 361264790Sbaptrecent conflict point and tries a different alternative. 362264790SbaptIf it finds a successful parse (reaches the end of the 363264790Sbaptinput or an action calls YYVALID), it backtracks to the 364264790Sbaptpoint where it first entered trial parse mode, and 365264790Sbaptcontinues with a full parse (executing all actions), 366264790Sbaptfollowing the path of the successful trial. 367264790Sbapt 368264790SbaptActions in btyacc come in two flavors -- {}-actions, which 369264790Sbaptare only executed when not in trial mode, and []-actions 370264790Sbaptwhich are executed regardless of mode. There are also 371264790Sbaptinherited attributes, which look like arguments (they are 372264790Sbaptenclosed in "()") and act like []-actions. 373264790Sbapt 374264790SbaptWhat this buys you: 375264790Sbapt 376264790Sbapt* No more lexer feedback hack. In yacc grammars for C, a 377264790Sbaptstandard hack, know as the "lexer feedback hack" is used 378264790Sbaptto find typedef names. The lexer uses semantic 379264790Sbaptinformation to decide if any given identifier is a 380264790Sbapttypedef-name or not and returns a special token. With 381264790Sbaptbtyacc, you no longer need to do this; the lexer should 382264790Sbaptjust always return an identifier. The btyacc grammar then 383264790Sbaptneeds a rule of the form: 384264790Sbapt 385264790Sbapttypename: ID [ if (!IsTypeName(LookupId($1))) YYERROR; ] 386264790Sbapt 387264790SbaptWhile the hack works adequately well for parsing C, it 388264790Sbaptbecomes a nightmare when you try to parse something like 389264790SbaptC++, where treating an ID as a typedef becomes heavily 390264790Sbaptdependent on context. 391264790Sbapt 392264790Sbapt* Easy disambiguation via simple ordering. Btyacc runs 393264790Sbaptits trials via the rule "try shifting first, then try 394264790Sbaptreducing by the order that the conflicting rules appear in 395264790Sbaptthe input file". This means you can deal with semantic a 396264790Sbaptdisambiguation rule like: 397264790Sbapt [1] If it looks like a declaration it is, otherwise 398264790Sbapt [2] If it looks like an expression it is, otherwise 399264790Sbapt [3] it is a syntax error 400264790Sbapt [Ellis&Stroustrup, Annotated C++ Reference Manual, p93] 401264790Sbapt 402264790SbaptTo deal with this, you need only put all the rules for 403264790Sbaptdeclarations before the rules for expressions in the 404264790Sbaptgrammar file. 405264790Sbapt 406264790Sbapt* No extra cost if you do not use it. Backtracking is 407264790Sbaptonly triggered when the parse hits a shift/reduce or 408264790Sbaptreduce/reduce conflict in the table. If you have no 409264790Sbaptconflicts in your grammar, there is no extra cost, other 410264790Sbaptthan some extra code which will never be invoked. 411264790Sbapt 412264790Sbapt* C++ and ANSI C compatible parsers. The parsers produced 413264790Sbaptby btyacc can be compiled with C++ correctly. If you 414264790Sbapt"#define" YYSTYPE to be some C++ type with constructor and 415264790Sbaptdestructor, everything will work fine. My favorite is 416264790Sbapt"#define YYSTYPE SmartPointer", where SmartPointer is a 417264790Sbaptsmart pointer type that does garbage collection on the 418264790Sbaptpointed to objects. 419264790Sbapt 420264790SbaptBTYACC was originally written to make it easy to write a 421264790SbaptC++ parser (my goal was to be able to use the grammar out 422264790Sbaptof the back of the ARM with as few modifications as 423264790Sbaptpossible). Anyone who has ever looked at Jim Roskind 424264790Sbaptpublic domain C++ yacc grammar, or the yacc-based grammar 425264790Sbaptused in g++ knows how difficult this is. BTYACC is very 426264790Sbaptuseful for parsing any ambiguous grammar, particularly 427264790Sbaptones that come from trying to merge two (or more) complete 428264790Sbaptgrammars. 429264790Sbapt 430264790SbaptLimitations of the backtracking: Currently, the generated 431264790Sbaptparser does NO pruning of alternate parsing paths. To 432264790Sbaptavoid an exponential explosion of possible paths (and 433264790Sbaptparsing time), you need to manually tell the parser when 434264790Sbaptit can throw away saved paths using YYVALID. In practice, 435264790Sbaptthis turns out to be fairly easy to do. A C++ parser (for 436264790Sbaptexample) can just put a [YYVALID;] after every complete 437264790Sbaptdeclaration and statement rule, corresponding to pruning 438264790Sbaptthe backtracking state after seeing a ';' or '}' -- there 439264790Sbaptwill never be a situation in which it is useful to 440264790Sbaptbacktrack past either of these. 441264790Sbapt 442264790SbaptInherited attributes in btyacc: 443264790Sbapt 444264790SbaptInherited attributes look a lot like function arguments to 445264790Sbaptnon-terminals, which is what they end up being in a 446264790Sbaptrecursive descent parser, but NOT how they are implemented 447264790Sbaptin btyacc. Basically they are just syntactic sugar for 448264790Sbaptembedded semantic actions and $0, $-1, ... in normal yacc. 449264790Sbaptbtyacc gives you two big advantages besides just the 450264790Sbaptsyntax: 451264790Sbapt 1. it does type checking on the inherited attributes, 452264790Sbapt so you do not have to specify $<type>0 and makes sure 453264790Sbapt you give the correct number of arguments (inherited 454264790Sbapt attributes) to every use of a non-terminal. 455264790Sbapt 2. It "collapses" identical actions from that are produced 456264790Sbapt from inherited attributes. This eliminates many 457264790Sbapt potential reduce-reduce conflicts arising from 458264790Sbapt the inherited attributes. 459264790Sbapt 460264790SbaptYou use inherited attributes by declaring the types of the 461264790Sbaptattributes in the preamble with a type declaration and 462264790Sbaptdeclaring names of the attributes on the lhs of the yacc 463264790Sbaptrule. You can of course have more than one rule with the 464264790Sbaptsame lhs, and you can even give them different names in 465264790Sbapteach, but the type and number must be the same. 466264790Sbapt 467264790SbaptHere is a small example: 468264790Sbapt /* lhs takes 2 inherited attributes */ 469264790Sbapt%type <t1> lhs(<t1>, <t2>) 470264790Sbapt stuff(<t1>, <t2>) 471264790Sbapt%% 472264790Sbaptlhs($i1, $i2) : { $$ = $i1 } 473264790Sbapt | lhs($i1, $i2) stuff($1,$i2) { $$ = $2; } 474264790Sbapt 475264790SbaptThis is roughly equivalent to the following yacc code: 476264790Sbaptlhs : 477264790Sbapt { $$ = $<t1>-1; } 478264790Sbapt | lhs [ $<t1>$ = $-1; ] [ $<t2>$ = $<t2>0; ] stuff 479264790Sbapt { $$ = $4; } 480264790Sbapt ; 481264790Sbapt 482264790SbaptSee the file "test/t2.y" for a longer and more complete 483264790Sbaptexample. At the current time, the start symbol cannot 484264790Sbapthave any arguments. 485264790Sbapt 486264790SbaptVariant parsers: 487264790Sbapt 488264790SbaptBtyacc supports the -S flag to use a different parser 489264790Sbaptskeleton, changing the way that the parser is called and 490264790Sbaptused. The skeleton "push.skel" is included to produce a 491264790Sbapt"passive" parser that you feed tokens to (rather than 492264790Sbapthaving the parser call a separate yylex routine). With 493264790Sbaptpush.skel, yyparse is defined as follows: 494264790Sbapt 495264790Sbaptint yyparse(int token, YYSTYPE yylval) 496264790Sbapt 497264790SbaptYou should call yyparse repeatedly with successive tokens 498264790Sbaptof input. It returns 0 if more input is needed, 1 for a 499264790Sbaptsuccessful parse, and -1 for an unrecoverable parse error. 500264790Sbapt 501264790Sbapt 502264790Sbapt Miscellaneous Features in ver. 1.0 503264790Sbapt ---------------------------------- 504264790Sbapt by Chris Dodd 505264790Sbapt 506264790Sbapt The -r option has been implemented. The -r option tells 507264790SbaptYacc to put the read-only tables in y.tab.c and the code and 508264790Sbaptvariables in y.code.c. Keith Bostic asked for this option so 509264790Sbaptthat :yyfix could be eliminated. 510264790Sbapt 511264790Sbapt The -l and -t options have been implemented. The -l 512264790Sbaptoption tells Yacc not to include #line directives in the code 513264790Sbaptit produces. The -t option causes debugging code to be 514264790Sbaptincluded in the compiled parser. 515264790Sbapt 516264790Sbapt The code for error recovery has been changed to 517264790Sbaptimplement the same algorithm as AT&T Yacc. There will still 518264790Sbaptbe differences in the way error recovery works because AT&T 519264790SbaptYacc uses more default reductions than Berkeley Yacc. 520264790Sbapt 521264790Sbapt The environment variable TMPDIR determines the directory 522264790Sbaptwhere temporary files will be created. If TMPDIR is defined, 523264790Sbapttemporary files will be created in the directory whose 524264790Sbaptpathname is the value of TMPDIR. By default, temporary files 525264790Sbaptare created in /tmp. 526264790Sbapt 527264790Sbapt The keywords are now case-insensitive. For example, 528264790Sbapt%nonassoc, %NONASSOC, %NonAssoc, and %nOnAsSoC are 529264790Sbaptall equivalent. 530264790Sbapt 531264790Sbapt Commas and semicolons that are not part of C code are 532264790Sbapttreated as commentary. 533264790Sbapt 534264790Sbapt Line-end comments, as in BCPL, are permitted. Line-end 535264790Sbaptcomments begin with // and end at the next end-of-line. 536264790SbaptLine-end comments are permitted in C code; they are converted 537264790Sbaptto C comments on output. 538264790Sbapt 539264790Sbapt The form of y.output files has been changed to look more 540264790Sbaptlike those produced by AT&T Yacc. 541264790Sbapt 542264790Sbapt A new kind of declaration has been added. 543264790SbaptThe form of the declaration is 544264790Sbapt 545264790Sbapt %ident string 546264790Sbapt 547264790Sbaptwhere string is a sequence of characters beginning with a 548264790Sbaptdouble quote and ending with either a double quote or the 549264790Sbaptnext end-of-line, whichever comes first. The declaration 550264790Sbaptwill cause a #ident directive to be written near the start 551264790Sbaptof the output file. 552264790Sbapt 553264790Sbapt If a parser has been compiled with debugging code, that 554264790Sbaptcode can be enabled by setting an environment variable. 555264790SbaptIf the environment variable YYDEBUG is set to 0, debugging 556264790Sbaptoutput is suppressed. If it is set to 1, debugging output 557264790Sbaptis written to standard output. 558264790Sbapt 559264790Sbapt 560264790Sbapt Building BtYacc 561264790Sbapt --------------- 562264790Sbapt by Chris Dodd and Vadim Maslov 563264790Sbapt 564264790SbaptWe used GCC and GNU make to compile BtYacc both on UNIX and 565264790SbaptWIN32 paltforms. You are welcome to try different 566264790Sbaptcombinations of makes and compilers. Most likely it will 567264790Sbaptwork, but it may require Makefile changes. 568264790Sbapt 569264790SbaptThere is no config script. 570264790SbaptJust type "make" and it should compile. 571264790Sbapt 572264790SbaptAWK. If you want to change file btyaccpa.ske (backtracking 573264790Sbaptparser skeleton), you will need awk to compile it into 574264790Sbaptskeleton.c file. We used GNU AWK (gawk) version 3.0. 575264790Sbapt 576264790SbaptIt is known that using older versions of gawk 577264790Sbaptmay create problems in compilation, because older awks 578264790Sbapthave problems with backslashes at the end of a line. 579264790Sbapt 580264790SbaptFor MSDOS, there a "makefile.dos" that should do the trick. 581264790SbaptNote: makefile.dos was not tested for a long time. 582264790Sbapt 583264790SbaptThe result of compilation should be a single executable called 584264790Sbapt"btyacc" which you can install anywhere you like; 585264790Sbaptit does not require any other files in the distribution to run. 586264790Sbapt 587264790Sbapt 588264790Sbapt Legal Stuff 589264790Sbapt ----------- 590264790Sbapt by Chris Dodd and Vadim Maslov 591264790Sbapt 592264790SbaptIn English: BtYacc is freeware. BtYacc is distributed with 593264790Sbaptno warranty whatsoever. The author and any other contributors 594264790Sbapttake no responsibility for any and all consequences of its use. 595264790Sbapt 596264790SbaptIn Legalese: LIMITATION OF LIABILITY. NEITHER SIBER SYSTEMS 597264790SbaptNOR ANY OF ITS LICENSORS NOR ANY BTYACC CONTRIBUTOR SHALL BE 598264790SbaptLIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL OR CONSEQUENTIAL 599264790SbaptDAMAGES, OR DAMAGES FOR LOSS OF PROFITS, REVENUE, DATA OR 600264790SbaptDATA USE, CAUSED BY BTYACC AND INCURRED BY CUSTOMER OR ANY 601264790SbaptTHIRD PARTY, WHETHER IN AN ACTION IN CONTRACT OR TORT, EVEN 602264790SbaptIF SIBER SYSTEMS HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH 603264790SbaptDAMAGES. 604