Re: gnubol: How do we parse this language, anyway?

[RKRayhawk@aol.com]

In a message dated 12/9/99 3:43:52 AM EST, wmklein@ix.netcom.com writes:

<< don't think the surprise is nearly as noteworthy (concerning the 2-level
 deep conditionals followed by a period).  What is significant is that BOTH
 the "old" and the "new" IBM compilers give errors for this situation - so I
 still see no need to keep this open as a "possible COMPATIBILITY" extension.
 
 Bill Klein
   wmklein <at> ix.netcom.com 
>>

Well on the arithmetic coditionals there are apparently compilers that are 
allowing two and more levels of nested conditionals  as an extension. Our 
problem is apparently it is not just one of them.  So we have a code base 
issue. If we allow it as an extension; some users might be surprised but 
their existing code, previously dredged of such conditionals, would still 
work the same. If we error it out; some users would have code that stopped 
working (probably not much but some). 

I do not know what the overall pattern is in the various compilers for nested 
conditionals where the various layers are different families (such as READ / 
ADD). If the 'extended' compilers are not allowing the unterminated 
condtionals to dangle there, then we have tools which are not 
self-consistent, but maybe less of a code base issue.

The spin I see here is that we may need to deal with convergence more than a 
vendor has 
to. And even as an open source understaffed project we don't actually have a 
path of least effort. You have to detect all of it and stay on your feet in 
the parser, choose as you may to reject or accept. ((So AFAIK, keeping it 
open does not actually create more work.))

The interesting thing about most programs, universally, is that they rarely 
check counters to see if they are overflowing. As tragic as it is, I can 
definitely find COBOL programmers who do not actually understand just exactly 
what a SIZE ERROR is. This powerful device is all too rarely applied to 
cardinal calculations, much less count blips like that envisioned in the 
sketch

    READ
       NOT AT END
           ADD 1 TO record-count
               ON SIZE ERROR
                    DISPLAY "PHM really does not care"
* implied scope terminator follows.
  .
*

So what you get to is the simple fact that these conditional statements 
actually are 
probably not nested much. In the modern compiler situation explicit scope 
termination
solves any syntax complaints from the compiler. So the basic problem is that 
the programmers will be presenting the compiler with the dangling conditional 
only on occassion. 
Except where their code has legacy examples, or their shop leans more towards 
it than average because of what some 'extended' compiler allowed in that shop 
before.

The really humorous thing about all this is that every time the compiler 
stomps on a dangling
condtional at level two, the coder learns to think of the position as an 
imperative position.  So often when they get a compiler problem with the 
above statement, they retract to 

   READ
       NOT AT END
           ADD 1 TO record-count
*  implied scope terminator follows.
  .
*
((They could use explicit scope delimiters, but since the culture does not 
value the 
error detection anyway; I am saying actually they may be more likely to 
chop.))

So in the revised approach the inner conditional is gone, since niether the 
manager wants it, nor will the stingy compiler allow it.  But we just trained 
the programmer to think that 
  ADD 1 to record-count
is an imperative. And having done that, and insisted that of course it is 
true, and why would anyone get confused: the next day the unconfused 
programmer, extends an old piece of code in another location, that was

    MULTIPLY mega BY mega GIVING giga
        ON SIZE ERROR 
            ADD 1 TO overflow-gizmo
* impl
  .
*

and will now be

    MULTIPLY mega BY mega GIVING giga
        ON SIZE ERROR 
            ADD 1 TO overflow-gizmo
        NOT ON SIZE ERROR
            ADD 1 TO temp-cnt-good-loops-for-debuging  
* impl
  .
*

And they will curse the language that has explicit scope termination and 
implicit scope termination. This is the same error but it will feel 
different, because the intended semantic 
is different. ((No compiler will accept that as indented; some will reject as 
you are keen on, but apparently some will 'extend' and gen a rather senseless 
semantic. The divergence in the code base is the issue to be assessed.))

I am getting to the point that I am afraid to post any more of these things.  
And actually in addition to keeping an eye on the code base, I think keeping 
this thing open may help us while we think through the parser rules. The code 
is going to be there, rare or not. So initial work on the parsers may prefer 
to bind in and accept with warning.

Anyway just so ill know what the 'compatibility' issue is, I think we have 
more than one target. Atleast for the arith within arith.  If there is 
generalized extension in some of those products permitting dangling 
conditionals on the edges of conditionals with positive code gen, then I see 
your comments about the mainframe compilers and the evident confidence of 
your expression to mean there is possibly a larger code base issue than we 
want. That is, it may not be just the arith within arith that are extended on 
the alternative platforms, and the mainframe may be very consistently 
rejecting all classes of dangling conditionals even when it is mixed verb 
families.

To be quite honest when you are mixing conditional families, there is 
actually not much reason to like the standard. A stack of [NOT]  AT END... on 
top of [NOT] ON SIZE ERROR really does not involve any ambiguity. Atleast not 
when you're just two layers deep. So if some vendors are extending they must 
see some practical reason to think that programmers are lazy enough to leave 
off explicit scope terminators occasionally as an expression of common sense, 
however briefly enjoyed. But it doesn't matter.  Only the code base matters.

I think the parser has to be that complex anyway, just top be robust. In all 
the situations, _all_, where we say a compiler hates the code or loves the 
code, in _all_ these situations the compiler is detecting the situation.

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.