[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
explain why NOT is missing from generated parser
From: |
James K. Lowden |
Subject: |
explain why NOT is missing from generated parser |
Date: |
Tue, 24 May 2022 19:54:22 -0400 |
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
- explain why NOT is missing from generated parser,
James K. Lowden <=