[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnubol: IBM nests conditionals
In the long dragon test case Tim posted there is a small item worth noting
....
In a message dated 12/6/99 8:29:16 AM EST, TIMJOSLING@prodigy.net writes:
<< 000010 PROCEDURE DIVISION.
000011 001.
000012 MOVE 8 TO X
Z 6 8
000013 MOVE 9 TO W
Y 5 7
000014
000015 ADD 1 TO
W 5
000016 SIZE ERROR
000017 1 DISPLAY "OVERFLOW ON W"
000018
000019 1 ADD 1 TO
X 6
000020 1 SIZE ERROR
000021 2 DISPLAY "OOPS - UNEXPECTED RESULT"
000022
000023 1 NOT SIZE ERROR
000024 2 DISPLAY "NO OVERFLOW ON X"
000025
000026 2 ADD 1 TO
Y 7
000027 2 SIZE ERROR
000028 3 DISPLAY "OVERFLOW ON Y"
000029
000030 3 ADD 1 TO
Z 8
000031 3 SIZE ERROR
000032 4 DISPLAY "OOPS - UNEXPECTED RESULT"
000033
000034 3 NOT SIZE ERROR
000035 4 DISPLAY "NO OVERFLOW ON Z"
000036 4 DISPLAY "RIGHT ASSOCIATION IS
SUFFICIENT"
000037
000038 2 NOT SIZE ERROR
000039 3 DISPLAY "OOPS - UNEXPECTED RESULT"
000040
000041 NOT SIZE ERROR
000042 1 DISPLAY "OOPS - UNEXPECTED RESULT"
000043
000044 END-ADD
000045
000046 .
19 IGYPS2112-E The "ADD" verb did not have a matching scope
terminator.
A scope terminator was inserted on line 41. The
execution results may not be correct.
Same message on line: 26
30 IGYPS2112-E The "ADD" verb did not have a matching scope
terminator.
A scope terminator was inserted on line 38. The
execution results may not be correct.
>>
It may be worthwhile to study the way the line 30 error reduced to a
diagnosible syntax at line 38. The compiler is not leaving an audit trail
here for us, but when you study this thing the product seems to have kept
track of things in a very deep manner.
Line 38 is a NOT ON SIZE error clause, so a clause of an outer statement is
triggering the reduction of the inner conditional arithmentic. So note that
it is not just a verb that reduces the foregoing syntax, but the next clause
of an outer statement. I think that clause belongs to the ADD arithmetic
that commences on line 26. _That_ arithmetic is contained in yet another more
outer arithmetic's conditional clause.
This vendor is parsing deeply nested conditionals. Which is quite relevant to
some comments in our work to the effect that some think we do not need to
nest conditionals. Bunches of mainframe code has nested conditionals of every
veriety. SEARCHES in EVALUATES and EVALUATES in SEARCHES, for example.
I do not think that three level deep situations are at all rare! We do _not_
have problems like
ADD...ADD...ADD,
but we have plenty of things like
EVALUATE ... SEARCH ... ADD,
nested along conditional branches, some portion of which is not conveniently
marked with the explicit scope terminators that we might prefer.
My own concern about the arithmetic conditionals was that their might be
different semantics (at just two levels of depth). I was wrong. But even at
that, the basic issue was at just two levels of depth on related conditionals
(related by the common interior glue pattern, such as the arithmetics are
commonly glued by [NOT] ON SIZE ERROR).
But when you get into the nesting of distinct categories of conditionals this
is a very different issue.
An unterminated conditional is a loose end of sorts. The compilers, I think
in general, are not at all concerned about a loose end that is only one level
deep.
The distinction we need to make here, though, is that multi-level loose ends
are of two very different varieties.
When we have two loose ends back to back, we have a real problem when they
are of the same type of conditional; as in
ADD ... ADD....
because it is not only loose but the bind point of the conditional following
the second (or nth) verb is ambiguous.
We do not have this problem when the conditions are in different families, as
in
READ ... ADD ...
because the ADD's conditional ([NOT] ON SIZE ERROR) can not bind back to the
READ, there is no ambiguity. (You can like this or hate it, I am just
pointing out that there is no ambiguity, so it is a different kind of
problem).
So the discussion about nesting arithmetics that we have been having does not
at all mean we can not nest conditioals. In that regard there is a large code
base issue.
I am not certain that the mainframe product flags all nested conditionals. It
is probably flagging ambiguous combinations. Like ADD ... ADD... and READ
... READ ... with two or more levels of unterminated conditionals.
Beyond all that I think we need to nest conditional grammar rules in
conditional grammar rules just to keep the parser on it's feet when junk
arrives. So we need to code that much complexity anyway.
Thus are task becomes, IMHO, 1) nest, 2) detect and crater ambiguous
conditional nesting, 3) maybe detect and maybe warn on harmless unambiguous
nesting of conditionals.
Also of note is the extremely subtle fact revealed by the listing showing
three errors that are exactly the same, but the advance
repetition-suppression algorithm sees that only the first two are really the
same and the third is different!
The difference is the end point. The problem on line 19 and the problem on 26
are the same problem AND both end at line 41. The very nearly same problem on
line 30 is differently only because it ends on line 38. That is not laziness,
that is extra hard work in the error printing routines! They avoided
suppressing the third messages, which is very useful.
But something else is revealed here. Line 19 and line 26 each commence a
concurrent scope that runs for some duration, indeed surviving the totality
of the internal matter, error trapping and all. But then notice that both
scopes reduce at the same point, line 41. That is instructive.
The NOT SIZE ERROR constitutes the lack of the lookahead token END-ADD. The
absence of the token, and the presence of NOT .... reduces them. That is
quite impressive.
(They must have competing rules one that will shift when it finds the
expliciti scope terminator, and one that reduces when it sees this [NOT] ON
SIZE ERROR), and diagnose it).
One of those cocurrent scopes would shift if it saw END-ADD. That would have
to be the inner statement, commencing on Line 26. But it does not. A
competing rule reduces, and must reduce first before the concurrent rule
relating to Line 19, even though the error message is made to be listed in
line number order. And though we at the source code level think of this as
happening at the same point the inner reduction happens first, and allows the
recurse to move up a level and the outer scope (commencing on Line 19) being
viewed as tow competitibe rules one looking to shift a terminator, one
looking to reduce, now reduces at a separate time; next after the inner scope
reduced. That is no small achievement. Because of my lack of familiarity
with the LL tools I can not see any chance of this happening in PCCTS. LR
tools like bison might make it as the stack gets the symbol from the inner
reduction and has not yet consumed the lookahead ([NOT] ON ...), which
precipitates yet another reduction.
When nesting related conditionals, that are common by the syntax pattern that
binds alternate conditional phrases,
I believe our concensus is to lean the grammar towards binding these loose
ends inward. Some are saying accept the two level conditionals as extensions
but flag them, similar to MIcro Focus extensions. (Perhaps some posters are
actually intending to say accept n levels, but that is a separate issue,
IMHO). Other posters seem to lean towards trapping these as errors.
By concensus, I think we are arriving at a point where no one wants to bind
outward.
We have not reached a concensus on nesting unrelated conditionals more
generally. That discussion has begun to move across much more terrain and has
encounterd the S/E E/S WHEN conundrum and the specialized issues of WHEN
OTHER, and optional explicit scope terminators for S & E. And it will
prolably get more complex.
Bob Rayhawk
--
This message was sent through the gnu-cobol mailing list. To remove yourself
from this mailing list, send a message to majordomo@lusars.net with the
words "unsubscribe gnu-cobol" in the message body. For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@lusars.net.