Re: gnubol: refmod again

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

This, of course, is the root of our disagreement.  I am certainly not
going to say that I'm against good diagnostics; that's a motherhood
issue, but I will not resort to letting the grammar grow
exponentially solely to improve the specificity of the syntax
diagnostics.  The wayward refmod will not escape.  It is simply an
unexpected element if the rule cannot accept it.

>>>>> "Bob" == RKRayhawk  <RKRayhawk@aol.com>
>>>>> wrote the following on Tue, 30 Nov 1999 02:29:43 EST

  Bob> In a message dated 11/27/99 10:33:53 AM EST, mck@tivoli.mv.com
  Bob> writes: << The refmod part itself is optional, so what remains
  Bob> to be done is to replace identifier references within the
  Bob> grammar to refmod references wherever refmod is permitted. >>

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

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

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

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

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

  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.