[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Recovery (was Re: gnubol: How do we parse this language, anyway?)
Tim,
Recovery is usually best by skipping to the next verb (begining of
sentence) on a bad error, or to the next period (EOS) if it is a very bad
error.
Please convey my love to Oz. I loved your jungle, reef, the hoping
creatures, and the termite mounds. Enjoy home & the early millennial
parties, VB, and XXXX :-)
Regards,
Jonathan
At 11:35 PM 12/9/99 +1000, you wrote:
>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.
>
>
--------------------------------------------------------------------
J & C Migrations, Pty.
566 Centre Street, Suite 3 http://www.jcmigrations.com
Newton, MA 02458 Fax: +1 (617) 916-5113
USA Tel. +1 (617) 916-5114
--
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.