Re: Parsing nested statements: was Re: gnubol: subsets

[Tim Josling <TIMJOSLING@prodigy.net>]

On rereading the standard I think that you still have to have a valid conditional
statement at before the else or end-if.

Eg

if a>b
   display ...
   add a to b
          size error
                display
                 subtract c from d
                      size error
                          display ...
end-if
.

The subtract is not an imperative statement so the add is not valid. The end-if
does not help, in terms of the standard (6.16.3 p VI-90).

You could make the compiler support this construct as valid. I would do this if
the major compilers do this, but I would have some problems to overcome in
flagging these as non-standard extensions.

Tim Josling

RKRayhawk@aol.com wrote:

> ...
>  IF a > b
>      display ...
>      add a to b
>             on size error
>                     display ...
>  ELSE
>      display ...
>       subtract retro-adjust-factor from running-total
>               on size error
>                    display ...
>  END-IF
>
>  This is an imperative statement I think.
>   >>
>
> In this situation the outer statement is the IF statement, and the arithmetic
> statements are the inner statements.
>
> The outer statement is definitely an imperative statement because it has an
> explicit scope terminator, the interior arithmetic statements are also
> 'imperative'. I believe, the reasons are not so obvious.  Scope termination
> can happen in several ways.
> ...
> The situation is different.
>
> In the IF statement, the [THEN], the ELSE and END-IF shift due to high
> precedence or specification of associativity. The ELSE clause glues to the
> current (inner most) IF. In order to do that it must be able to burn through
> anything in between....
> The IF statement originally posted is an imperative statement, because of its
> explicit scope terminator. The enclosed arithmetic statements are conditional
> statements, these are permited because the ELSE token (or WHEN token) has no
> potential alternate interpretation: so before it shifts the inner arithmetic
> statments reduces (this is triggered by mere lookahead that determines that
> ELSE/WHEN can not glue on the current statement). And in these [THEN] and
> ELSE clasues any such inner conditional arithmetic statement can actually
> have arithmetic statements on its conditional clause as long as those
> arithmetic statements are 'imperative' on account of the absence of their own
> conditional clause or the presence of an explicit scope terminator. The whole
> shooting match still gets reduce when we encounter the ELSE/WHEN or END-IF or
> END-EVALUATE, which token then shifts.



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