[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: gnubol: How do we parse this language, anyway?
I do not know Wang - but do know Micro Focus. Their documented extension is
to allow ANY nested (unterminated) conditional statement where the Standard
requires an imperative. There is no "difference" between nested arithmetic
within arithmetic than any other. Similarly, there is no restriction on
nested CALL ON OVERFLOW, and STRING/UNSTRING ON OVERFLOW.
HOWEVER, I still don't think there is much of a code base that uses this
extension and you just haven't convinced me of any reason to keep this as an
open issue. No one has demonstrated that there is ANY case (vendor) where
"old" code allowed something (code base) that the new (current) rules do not
allow.
If the code needs to be there (to avoid infinite look-ahead), fine keep
"assuming" conditionals are OK, but Please PLEASE make it an error to put a
nested unterminated conditional statement where an imperative is required.
FYI,
If you are getting into the business of looking at Micro Focus extensions,
they actually document "Next Sentence" as a valid imperative statement (for
nesting) in ANY other statement. Again, I am not recommending this, just
pointing out that "matching" Micro Focus extensions will start you down a
very slippery slope.
Bill Klein
wmklein <at> ix.netcom.com
> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of
> RKRayhawk@aol.com
> Sent: Thursday, December 09, 1999 6:21 AM
> To: gnu-cobol@lusars.net
> Subject: Re: gnubol: How do we parse this language, anyway?
>
>
> 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.
--
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.