Re: gnubol: Problem 10

[RKRayhawk@aol.com]

In a message dated 12/27/99 12:29:05 PM EST, 
 Bill Klein,wmklein@ix.netcom.com writes 
valuable comments :

<< I'll have to think about it a little bit, but to the best of my knowledge -
 if you have handled ALL Data Divisions before a Procedure Division (and
 handled "name conflicts") then you should be OK.  The one exception that I
 can think of (off-the top of my head) is the Report-Writer SOURCE and SUM
 statements - which can reference data items that are not yet defined (I
 think).
 
 Bill Klein
   wmklein <at> ix.netcom.com
 
 >>

This raises an interesting point.  There are things upstream in the program 
that make forward references.  Although the earlier part of this thread 
focused on the procedure division, and whether or not a reference can be 
distinguished as a reference to data or a reference to a procedure name when 
encountered in the procedure division. I want to go off on a tangent here to 
deal more generally with forward reference (even beyond procedure division 
references to procedure names).

There is a difference between just getting a symbol into a symbol table as 
opposed to fully defining it there.  Some folks use the term 'instantiate' to 
describe  the process of setting up the entry in the symbol table (SYMT) for 
a name. It is not rare that the first encounter with a name can not actually 
complete the entry.

Before a data item that will be used as a file status is defined, for 
example, upstream statements may reference it in FILE STATUS [IS} data_name 
clauses. When those clauses are encountered, the data_element can be 
instantiated in the SYMT. At that point we not only know very little about 
it, we do not even know if it will ever be defined: so this quick 
instantiation action requires followup review at the end of the program.  

It also requires skillful coding of things way down stream that might try to 
use the file status data_name. For example, if the item is never defined, 
then procedure division references to it
can not go unflagged.  And implicit use of the item in I/O verbs must be 
policed as well.

The possibility of early instantiation solves some forward reference 
problems.  If we get aggressive and try to do some of this from the output 
buffer of preprocess we need to be very careful about the scope of data items.

The other side of this coin is that if you do not instantiate early (that is, 
no later than first forward reference (((although this point here is not 
meant to convince that the aggressive preprocess hook is 'necessary'))) ), 
you are compelled to put a parsed construct into some kind of suspended 
animation, and complete your analysis of that early reference, as well as all 
other forward references as a checklist later. So something has to be done 
later, one way or the other.  The usual idea is to complete the overall 
syntax check immediately by means of an assumed valid reference, and schedule 
only the reference for subsequent confirmation.

Thus drfiting out of syntax (parse) are a number of reference confirmation 
lists. In the event these fail the requisite diagnostics will need line 
number information for each instance. That process becomes entirely 
asynchronous with the ongoing parse.

Although there are logical break points where subsets of these lists can be 
consumed. That is important for resource conservation.  At the end of the 
data division, for example, you can review all forward references of the 
first three divisions. Presumably many can be retired, as accepted or as 
rejected. That presents resource free() opportunities.

As we contemplate the awesome task of constructing semantics for this 
compiler we may wish to atleast try to find break points _within_ the 
procedure division where forward reference
resources might be freed. It may be too simplistic to do it at paragraph or 
section boundaries. But a quantitative approach might work.  For example, if 
we are currently dealing with atleast, say 500 (pick a number) current items 
on the forward reference list, and we have resolved, say 10%, then house 
clean a bit and reset.

Also we may want to give some consideration as we proceed to identifying any 
forward reference that may take a long time indeed to resolve. That could be 
a candidate for 
non-RAM store. I thinking nested programs and methods (that is COBOL 20xx).

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.