Hi, I'm writing a parser for Cobol. If you know Cobol, you know that's a mouthful. Cobol predates BNF, and sometimes it shows.
Parser: https://git.symas.net/cobolworx/gcc-cobol/gcc/cobol/parse.y Documentation of the verb: https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statements-unstring-statement At the moment, I'm Just Confused. I have two verbs, STRING and UNSTRING, with similar syntax. Yet STRING is parsing correctly, and UNSTRING not. Both statements accept an OVERFLOW (and NOT OVERFLOW) phrase: 913 on_overflow: on_overflow1 statements 915 on_overflow: on_overflow1 statements $@37 on_overflow1 statements 916 on_overflow1: OVERFLOW 917 | NOT OVERFLOW Yet, when we get to the "on_overflow" nonterminal, only STRING recognizes NOT. How do I diagnose why bison is "ignoring" the NOT in when evaluating on_overflow1 for UNSTRING? The following comes from the bison report output; the "?" represents the bullet that indicates where the parser is. State 1138 894 string: STRING_kw str_delimiteds str_into ? on_overflow end_string 895 | STRING_kw str_delimiteds str_into ? 896 | STRING_kw str_delimiteds str_into ? END_STRING NOT shift, and go to state 1382 END_STRING shift, and go to state 1383 OVERFLOW shift, and go to state 1384 $default reduce using rule 895 (string) State 1528 918 unstring: UNSTRING scalar uns_delimited INTO uns_into ? on_overflow end_unstring 919 | UNSTRING scalar uns_delimited INTO uns_into ? 920 | UNSTRING scalar uns_delimited INTO uns_into ? END_UNSTRING END_UNSTRING shift, and go to state 1641 OVERFLOW shift, and go to state 1384 $default reduce using rule 919 (unstring) The grammar so far has 1000 rules, and I still feel like an amateur. I know the tool is deterministic, but sometimes what seem like minor changes make it go from working to nonworking, and vice-versa. In this particular case, I intentionally made the the two rules as similar as possible. I'm guessing the precedence of "NOT" is the culprit: that when we get to uns_into * on_overflow there's a terminal in uns_into that causes the NOT in on_overflow to be ... something. But every form of uns_into ends in "scalar" (a variable), so my theory doesn't explain anything. What should my strategy be to analyze why bison is producing the parser it is, instead of the parser I want? Many thanks, --jkl
