[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: gnubol: Problem 10
Just a few more "1st 3 division" forward references:
1) OCCURS DEPENDING ON (possible in LOTS of places) (may be forward OR
backward reference)
2) RECORD VARYING IN SIZE DEPENDING ON (*must* be forward reference)
3) Select/Assign to data-name (various interpretations of what this is and
what this means in different implementations)
4) Select file-name Assign to - file-name must have an FD (I don't know if
you consider this forward or backwards)
5) All the data-names in the LINAGE clause
FYI,
Some compilers wait until the end of Working-Storage (and Linkage Section
if appropriate) to issue a message about "referenced data item is not
defined". HOWEVER, the "nicer" compilers issue the message at the point the
reference is made. Obviously, this must require either a LONG "look-ahead"
or a two-pass syntax checker.
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: Monday, December 27, 1999 2:19 PM
> To: gnu-cobol@lusars.net
> Subject: Re: gnubol: Problem 10
>
>
>
> 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.
--
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.