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

[Tim Josling <TIMJOSLING@prodigy.net>]

Both Michael and I are intending to parse as your describe - with error messages
according to our now well known predilections :-).

Where I do have a problem is with the nested Evaluate/Search where I have decided
it is too hard. If you try a nested non-imperative form of one of these you will
get an error and I can't recover. This is because I do not know how to recover.

I'm flying back to Australia on Saturday then I'm on holdays until after the Y2K
disaster/non-event. Hopefully I will have an executable by then (no pomises - I
am trying to keep the delivery to promise ratio at a reasonable level) - at which
point people are free to send me a patch if they can work out how to do it.

Tim Josling

RKRayhawk@aol.com wrote:

> 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.