Re: gnubol: Re: ref touch points

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

>>>>> "Bob" == RKRayhawk  <RKRayhawk@aol.com>
>>>>> wrote the following on Fri, 3 Dec 1999 10:48:21 EST

  Bob> In a message dated 12/3/99 8:19:26 AM EST, mck@tivoli.mv.com
  Bob> writes: <<

  Bob>  procedure_ref
  Bob>     : PROC_NAME { OF_IN PROC_NAME }
  Bob>     ;
  >>>
  Bob> This is a situation in which certain minimum increases in size
  Bob> of the rule set can take some work out of semantics: consider
  Bob> alternatively a pattern like

  Bob>  procedure_ref
  Bob>     : procedure_ref_okay
  Bob>      | procedure_ref_not_okay
  Bob>     ;

	   <lot of variants of error productions>

  Bob> We could get good at this.  To clarify a point that I have
  Bob> tried to make before, but apparently seems too abstract the
  Bob> way I have previously phrased it. If we do not do this with
  Bob> syntax rules we must do it in the actions or in semantics. The
  Bob> work must be done. If we do not allow this linear expansion of
  Bob> the syntax rules we have merely delayed the work activity to a
  Bob> later phase of project gnubol.  Regrettably, if we do it in
  Bob> the actions we will have very complex code and no matter what
  Bob> we extract from the symbol tree to make the determinations it
  Bob> will be too late to effect rule selection, because we will be
  Bob> in the action already. That point is a major design
  Bob> consideration: how much of the damaged reference problem do we
  Bob> want to manage with rules.

This thread started out talking about PERFORM.  Now the problem I
have with your scheme is that is we put this stuff into syntax we're
adding lots of completely new rules, while in semantics validation of
operands is virtually always required no matter how much you do in
syntax.  In a simple out-of-line PERFORM, semantics has to genrate
operators to store a return address and branch to the target
paragraph, and a bit of other housekeeping.  It uses information from
the symbol to do this.  I just don't think it's unreasonable to ask
semantics to make sure that you haven't given it a packed decimal
number instead of a paragraph name before it begins these
operations.  After all, in semantics everything is boiled down to its
essence.  There's no text to bother with, just a symbol.  

  Bob> The basic idea that at any given touch point where the
  Bob> compiler hits references we have a rule that looks like a
  Bob> single symbol to the verb construct rule, but nearly always is
  Bob> a split down below into _okay and _not_okay.  That puts us in
  Bob> business to elaborate any useful alternatives that involve
  Bob> just sequence problems like an index reference of the pattern

  Bob>    dataref (1) (2) (3),

  Bob> where we should have

  Bob>    dataref (1 2 3).

  Bob> This is a major payoff. Many problems that would otherwise
  Bob> flyout as error to some mother rule up above now simply reside
  Bob> quietly down below flipping error_flags to guide emissions to
  Bob> semantics. We do not have to be infinitely clear on exactly
  Bob> how far we will take this to get on the basic path.

C'mon Bob, the mother rule will have no part of them.  They'll be
stranded and culled out.  What more would you want?

  Bob> I would eventually take this very far to keep problems out of
  Bob> semantics.  No one else would agree with this at this time,
  Bob> but if you have the basic _okay/_not_okay split on all
  Bob> reference landing pods you can add precision over time.  If we
  Bob> can distinguish reference modifiable items from those upon
  Bob> which reference modification is illegal we can trap
  Bob> inappropriate reference modifications in the rules and
  Bob> semantics does not have to deal with it. For example I believe
  Bob> it is not reasonable to reference modify a pointer elementary
  Bob> item. By the time that we reach the reference in the procedure
  Bob> division everything we need to know for this is present in the
  Bob> symbol table; the lexer or an intermediate filter can burp it
  Bob> up if we need it.

Well, semantics is all about problems.  Intermediates that are
source-close cannot be ingested by a code generator.  Semantics has
to convert these things to simple operations for the compilation to
proceed, and to do that it has to be more intimately familiar with
the properties of its operands than any other part of the compiler.
It does not seem at all unnatural for it to use that knowledge to do
a certain amount of diagnosis.  It's really semantics that decides
what code gen will eventually see.

  Bob> So the sale is this; split every reference point into
  Bob> _okay/_not_okay subrules, elaborate as time permits. Without
  Bob> being intricate on reference modifiability or subscriptability
  Bob> in the beginning we can easily do no-brainers, like references
  Bob> to collating sequences are certainly not appropriate as
  Bob> procedure names in the PERFORM statements. Eventually we can
  Bob> get around to detail work in the data references. The binary
  Bob> attributes of :

  Bob>     reference modifiable / not reference modifiable

  Bob>     subscriptable / not subscriptable

  Bob>     qualifiable / not qualifiable

  Bob> are definitely discernable as of completion of the data
  Bob> division parse. We can easily write syntax rules that will
  Bob> scoop junk up out of the code and relieve the burden of
  Bob> semantics.

The burden of semantics is uniformly heavy.  A little diagnosis is
hardly noticable.

  Bob> Perhaps it is a reasonable guess that subscripting and
  Bob> reference modification interpretation is best left to
  Bob> semantics (yet actually in some instances that is statically
  Bob> expressed via constants, but why code it twice, the dynamic
  Bob> variation has to be in semantics).

It is only semantics that knows how to translate constant subscripts
into a modified base address for the table, so that no code need be
generated.  

  Bob> However, it is likewise reasonable to suggest that
  Bob> qualification can and perhaps should be accomplished in
  Bob> syntax. Qualification actually involves a tree walk of
  Bob> portions of the symbol table. That can occur as the {OFIN ref}
  Bob> recurse reduces step by step, or at the single action where
  Bob> the reference is reduced, or in the various verb constructs
  Bob> that real in the references.

This is actually one of the places that we agree.  Be careful about
resolution, though.  COBOL is not C.  COBOL requires only that
qualification be sufficient to disambiguate references.  That means
we have to do bottom-up lookup, starting with the data-name and
marching upward in each tree to find the qualifiers.  We must also
examine every instance of the data-name, even after we've found a
match, to insure that the reference is truly unambiguous.

  Bob> The step by step synchronous walk makes the most sense, in
  Bob> effect the grammar parse engine is enabling the walk in
  Bob> exactly the correct fashion. Why waste that opportunity. So
  Bob> anyway, if you do manifest type according to a few
  Bob> distinctions for rule identification of syntax errors, you are
  Bob> incidentally enabling qualification _resolution_ in syntax and
  Bob> providing atleast for the possibility of eliminating that from
  Bob> semantics.

If I understand what you're saying here, I think I have refuted it in
the last paragraph.

  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.