[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



You are absolute correct that the current Standard absolutely positively
requires that the NOT ON SIZE ERROR *must* match the most recent arithmetic
verb.  I believe that if you asked J4 (or WG4), they would indicate that what
you have code is a NON CONFORMING implementation and not an extension.

Take a modification of your example and tell me what you do with:

If A = B
  add a to b
     size error
          add c to d
      not size error
          display ...
        End-Add
Else
   Display "other"
End-IF

In this case the source code IS conforming (as an IF can have a conditional
statement) and the END-IF *must* terminate the 2nd ADD - and the NOT SIZE
absolutely, posively MUST match the 2nd (not 1st) ADD.

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 02, 1999 5:14 PM
> To: gnu-cobol@lusars.net
> Subject: Re: gnubol: How do we parse this language, anyway?
>
>
> In a message dated 11/30/99 9:14:07 PM EST, TIMJOSLING@prodigy.net writes:
>
> << In the following case
>
>  add a to b
>        size error
>              add c to d
>                     not size error
>                           display ...
>  .
>
>  which is either an extension or an error (take your pick) -
>
>  I was treating it as
>
>  add a to b
>        size error
>              add c to d
>         not size error
>              display ...
>  .
>
>  Which is incorrect according to all the compilers and my current
> opinion. So
> I
>  had to make changes.
>
>  I have made the changes, and I flag it as an extension.  >>
>
> We are on the wrong path. It is neither an extension nor an error.
> The thing
> that many are missing is that the standard says that the inner
> arithmetic can
> not be an unterminated conditional. THE STANDARD SIMPLY DOES NOT
> SAY THAT THE
> OUTER ARITMETIC's SECOND CONDITIONAL IS PROSCRIBED FROM OCCURING AFTER THE
> INNER SIMPLE ARITHMETIC. Those are two very different ideas.
>
> The standard refers to the preceding arithmetic that is to have the clause
> bound to it, if that preceding clause has not yet occured. The clausing is
> _definitely_ alllowed to occur sequentailly after the inner simple
> unterminated arithmetic!.
>
> Reducing the internal simple arithmetic is simple, tracing the
> clause back to
> its antecedent is not simple, and diagnosing it smoothly when all
> antecedents
> have that clause is also not simple.  But the displayed case is not an
> extension.
>
> The fact that the
>         not size error
> came after  the
>         add c to d
> is not an error. We can not give the coder static about it (unless all
> antecedent positios are full in effect).
>
> Best WIshes,
> Bob Rayhawk
> RKRayhawk@aol.com
>
> --
> 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.