Re: gnubol: refmod again

[RKRayhawk@aol.com]

In a message dated 11/27/99 10:33:53 AM EST, mck@tivoli.mv.com writes:

<<  The refmod part itself is optional, so what remains to be
 done is to replace identifier references within the grammar to refmod
 references wherever refmod is permitted. >>

There is another way to look at this. Design. List all possible referants. 
That is, everything that can be refered to at all.  List every possible 
phrase that might refer to anything. Assume
the worst.  We must cope with reference modification where it should not be. 
We must cope with references to procedures where data references should be. 
IMHO it would be better to layout what you think a reference modification 
reference looks like, and what a subscript reference looks like,...... and 
then collect them into valid and invalid subsets by context. 

For MOVE a TO b, you might want certain kinds of references, but we must stay 
on our feet if we get surprises, like a section name.  For the things you are 
describing so well with PCCTS, the layout comes close to detemining what kind 
of reference it is. But we should not plug a reference modification into only 
those places that it belongs because that is not what we will find in code.

I would start way up high, like with collating sequences, and name everything 
that can be a referant. Determine syntactic features if possible (only a 
subset like refmod and subscripts are distinct patterns); sketch what you 
would like to know from the SYMT before you attempt to parse it. Design the 
set of attribute that comes from lex to parse in the main parsers.

Subscripting errors, refmod errors and qualification errors are common, we 
can not afford to 
drop out of a verb construct parse just because of these anticipatable 
errors. It is as important to design for error detection as for detection of 
correct references.

The rules you have are elegant. But we will die a thousand deaths if we can 
not see through referential errors. IMHO we can not just plug good patterns 
in where they belong. We basically need to plug all patterns in everywhere, 
perhaps by a method of lists and sublists.

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.