Re: gnubol: subsets

[Michael McKernan <mck@tivoli.mv.com>]

>>>>> "Bob" == RKRayhawk  <RKRayhawk@aol.com>
>>>>> wrote the following on Thu, 18 Nov 1999 05:00:26 EST

  Bob> In a message dated 11/17/99 9:22:59 PM EST, mck@tivoli.mv.com
  Bob> in reference to semantics writes:

  Bob> << It updates the symbols for all of these things.
  >>>

  Bob> That is an interesting specific issue.  Could we consider as a
  Bob> first approach that semantics is not permitted to update SYMT?

No, but I may have misled you.  Provide we can get the parser to turn
out properly structured symbol trees for COBOL records, the symbol
table for data division should be structurally complete after the
data division parse.  Semantics does create additional information,
however.  Addresses are recorded in the symbols as a side effect of
storage allocation, for example.

  Bob> This question has two big parts and then some
  Bob> scatterings. Basically if we say that the SYMT must be
  Bob> complete for the data division we definitely put some work in
  Bob> syntax, just to be a sounding board my sound is I do not think
  Bob> that is a bad idea.  But another approach to that is to
  Bob> clarify what we mean by the possibility of multiple
  Bob> intermediates.

I don't know what the possibility of multiple intermediates might
mean, unless we're suggesting that there might be a different
intermediate between semantics and code generation than there is
between syntax and semantics.  I don't see any need for more than one
intermediate form at any one interface.

  Bob> I think the notion that we _could_ be through with the SYMT
  Bob> for the procedure division declared things by the end of
  Bob> syntax may be more defensible. In know that advanced concepts
  Bob> of optimization might lead to an interest in tagging segments
  Bob> of code in certain ways. And I am not saying that SYMT is
  Bob> inaccessible, but as a design concept for starters what are
  Bob> the implications if we say that any update to procedure
  Bob> entries in the SYMT must get done in syntax.

Yes, there are those kinds of annotations, but there are also
additions like an array of perform exit buckets.  The user visible
stuff should be essentially complete, though.

  Bob> Again my general concept is that validation and data typing
  Bob> are outfront.  That certainly grows the work for data div in
  Bob> syntax.

You probably won't get me all the way into your camp on this one,
Bob.  Some things fall out in semantics almost effortlessly.  Using a
little context sensitivity to guide the parse is very appealing
though, and I'd like to use it wherever it seems appropriate.

  Bob> We must allow for the concept that perhaps we will want to see
  Bob> a procedure reference as a statement that types a particular
  Bob> procedure (you know like a SORT INPUT/OUTPUT procedure); which
  Bob> is not declared in the section or paragraph itself.  But
  Bob> initially I don'ts see that.  The most urgent issue of a
  Bob> paragraph is its entry and exit. And that needs generalized
  Bob> solution, and bullet-proofing for performed or performed
  Bob> terminus, and for a little thing called initial state.  My
  Bob> other posts have indicated that I would be in favor of detailed
  Bob> distinctions on procedure types but we need some of that
  Bob> before syntax, and certainly know a lot during syntax.  This
  Bob> must stay open as we work our way all the way through forward
  Bob> reference in the procedure division.

So far, I haven't been able to share your sense of urgency on these
matters, but we should be seeing more specific implementation
proposals shortly and that may give you the opportunity to drive your
points home.  Incidentally, the perform exit problem is probably the
best argument for having semantics be a pass.  The problem, of course
is the necessity to generate the exit code at a point in the program
where there is no local indication that it is required.

  Bob> Best Wishes Bob Rayhawk RKRayhawk@aol.com

  Bob> -- This message was sent through the gnu-cobol mailing list.
  Bob> To remove yourself from this mailing list, send a message to
  Bob> majordomo@lusars.net with the words "unsubscribe gnu-cobol" in
  Bob> the message body.  For more information on the GNU COBOL
  Bob> 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.