Re: gnubol: Re: ref touch points

[RKRayhawk@aol.com]

In a message dated 12/3/99 11:51:19 PM EST, mck@tivoli.mv.com writes
responses to an original post of mine :

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

This issue may look different under LR and LL. 

(Indeed a separate decision criteria for choosing LR/LL is that the OFIN 
clauses look like a right recurse as one might casually layout rules. But the 
OFIN consideration is only one among many considerations.)

The notion _might_ be that LL actually would need to check from the top down, 
each level down either checks upward again or somehow shortens some of its 
work by getting a list of what has been checked 'up above' so far; which list 
might be only one branch of its concerns if the current item has multiple 
definitions.

The notion _might_ be that LR can cut things short once it finds a break in 
the chain.

It seems like checking up or checking down will involve intermediate 
positions that have a number of alternatives still viable, each one 
_possibly_ holding several segments. It is almost as if we had a requirement 
that we parse the symbol table as a rule set.

(The LR parser algorithms faces some stack resource challenges when 
attempting right recurse. Everyone is so confident that resources are not an 
issue anymore, I am not sure anyone cares. An OFIN check could occur on code 
that is farily deeply stacked already.
Comments here assume right recurse for OFIN with LR parser. That would be an 
unusual rule in an LR grammar.)

Even in the context of errors we may want to continue compiling as much of an 
extended OFIN sequence as we can. The idea being to give the user as much 
feedback as possible on each compile.
In a sequence like
   a OF b OF c OF d OF e OF f
if 'b OF c' is wrong and 'd OF e' is wrong, it would be useful to flag each. 
Yet also it might be legitimate to consider this a place where we would not 
try to validate further on after the first break. The motivation would be 
that the rest may actually have no semantic content; these are rare portions 
of the code base; it may be easier to code 'early break OFIN'; and 'early 
break OFIN' design presumption leaves us free to continue keeping both LR and 
LL on the table for now.

LL parse and even left side recurse of OFIN in a LR grammar seems problematic 
to me. It seems like the actions would tend to be committed too early.

In the case of nested statements in a block left recurse in LR and early 
commits in LL would basically just emit the statements (presumably whole) one 
by one to semantics. But we can not emit 
  a OF b
followed by 
  b OF c
to semantics, unless (again) we are just not doing the job in syntax and are 
just passing the buck. 

Another alternative might be to impose a limit on OFIN clauses and consider 
some kind of explication in rules that avoids recurse (again leaving LR and 
LL on the table, by avoiding a tilt to left or right recurse). This approach 
will allow any depth of datanames 01-49+FD etc., but in the references in the 
procedure division, the complexity of OFIN sequences will be  limited. The 
parts  of the OFIN would be allowed to refer to any level. The number of 
clauses would be limitted. Pick a number that does not seem like an excessive 
rule propagator (5 ? 10?). Five would certainly be adequate to  cover a huge 
number of programs.

I have no idea if the standard allows room for that kind of partial 
implementation.

Incidentally this has implications for the design of the symbol table (even 
if we were to punt and let semantics do it). We actually need to know if the 
OFIN resolution engine will girate top-down or bottom-up. Initially we might 
assume bidirectional linkage for the 01-49+FD relations. But if the symbol 
table design is trimmed to unidirectional linkage, then that decision has to 
be synchronized with the OFIN resolution engine style of walking the tree.

So an annotation here is that the dataname nodes in SYMT have atleast linkage 
to synonyms and to one or both 01-49+FD relatives (above and/or below).

Anyway, in sum, Michael McKernan had been kind enough to opin
<<
That means we have to do bottom-up lookup
>>

I believe both bottom-up and top-down are valid. We need to decide if we will 
continue after a break.  It may be useful to keep this in suspended animation 
until we find any absolute determiners of LR/LL. Once we do commit LR/LL, we 
will need to see how l/r-side recurse looks in that tool for this particular 
construct. 

IMHO the OFIN consideration should not way heavy in the LR/LL tool 
commitment, because of rare occurence of extreme depth in references 
occurences.


Bob Rayhawk

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