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

[RKRayhawk@aol.com]

These are not unchartered waters.  In the numerours interesting samples 
quoted below there are no explicit scope terminators. The coder basically is 
warranted in trusting us to assume that all the inner arithmetics are simple. 
In that situation we will be trying to glue the ON SIZE ERROR conditionals to 
the outer arithmetic, as the "...next..." "...such..." conditional and we 
will be meeting with mixed success.

In the posted list there are no explicit scope terminators, none of the 
clauses glue to any inner arithmetic.

The following may seem perhaps intransigent, but you can not have a next for 
a statement that does not have its first.  You can not glue to the inner 
arithmetic because that is an error, you can not _assume_ an error. You can 
_assume_ correct code. You can assume that the inner arithmetics are simple. 
In the absence of explicit scope terminators the clauses fly back. You can 
not start with the parser tool and insist that the language conform to the 
paradigms (such as associtivity).  We must think COBOL not tool.

It will not be easy to do this. We will need manual counting (we need that 
anyway). And it will be very interesting to make a decision about how to 
handle the implications of the antithesis "...not....such..." when we are 
three levels deep, since that is a double negative and it is not explicated.  
 I am accidentally leaning in the direction glue everything to the top. But I 
am intentionally saying we surely must glue out not in, when there is no 
scope terminator.

This is not minor, as it has semantic differences. On the I/O verbs the 
behavioral differences could constitute major dysfunction.

It is the code base that counts. If the mentioned vendor is doing something 
in this area that is semantically different than other vendors with 
significant market share, than this is definitely not one or the other; it is 
both.  In that event we must be able to do both semantics. That is the 
largest possible coding effort. The vendors are not the issue. The owners of 
the code base are. If the Big Blue's code base is not important this project 
changes, because of how the owners of that code would feel about that.  

If we must have different semantics in these areas, ehn  the code base looks 
very different, the available resources look very different.  This is not 
good guys and bad guys though. This is convergence. It is a heavy duty 
undertaking.


In a message dated 11/25/99 1:01:20 PM EST, TIMJOSLING@prodigy.net writes:

<< It's not a show stopper just more to do. A bit like next-sentence / end-if
 handling.
 
 How would you parse these (if not how the indentation suggests)?
 
 add a to b // just an abvious starting point
     size error
           add c to d
           display ...
 .
 
 add a to b
    size error
          add c to d
             size error // it can only bind in one place I guess
                    add e to f
 .
 
 add a to b
    size error
       add c to d
    not size error // this is what the standard says though it is not right
 associative
       add e to f
 .
 
 add a to b
    size error
           add c to d
                  size error
                       add e to f
                  not size error // we are in uncharted waters here - what 
does
 IBM do?
                        add g to h
 .
 
 Tim Josling
  >>

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