[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNU-COBOL] Yet Another Grammar question



Hi Laura,

Here I am again, responding to a language interpretation question.  I
really don't mind doing that, but I've been out of the COBOL game for
more than five years now, and I was hopeful that there might be
someone on the list who has been keeping up on standards revisions
and clarifications.  I certainly have not.

In this case, I am unable to make the original '85 standard say what I
think it should, so I'll just tell you what I'd do (and have done).
Perhaps someone better versed in the arcana of standard COBOL might
even be able to defend my interpretation, but, for the moment, I'll
simply point out that we are not working from a floor and ceiling
standard, and relaxing the rules a bit is the norm.

First, let's get the sentence question out of the way.  Paragraph
6.4.1.2 says "A sentence consists of one or more statements and is
terminated by the separator period."  The standard may seem to be a
little schizy about the definition of a statement, but it's at least
clear that the period is a part of the sentence syntax.

Defining a statement is a little trickier.  The confusion arises
between the definition you cite here (and perhaps others like it) and
this remarkable excerpt from paragraph 6.4.1.2.

  A statement is a syntactically valid combination of words, literals
  and separators beginning with a COBOL verb.

You may think you know what that means, but any committee member will
tell you with a straight face that the syntactically valid
combination may, of course, contain other COBOL verbs.  And you will
no doubt also be fascinated to learn that "...each possibly separated
from the next by a separator" is also subject to the syntactically
correct rule, hence the only valid separators are those equivalent to
SPACE, ie COMMA SPACE+ and SEMICOLON SPACE+.  Are we having fun yet?
  
OK. Now let's talk about the _syntactic_ requirement for imperative
statement, which seems completely unreasonable to me.  Should we be
required to have a derivation for imperative_add, imperative_call
etc. which differ from their non-imperative counterparts only by
requiring an explicit scope delimiter (in the presence of a
conditional phrase) rather than allowing the scope delimiter to be
implied?  Is there any justification for such a rule?  This just
seems, to me at least, to put an egregious burden on the implementor
and, at the same time, to make life more difficult for the user.
Consider this fragment.

   perform many times
      add 1 to foo
      on size-error
         move zero to foo
   end-perform

Would a reasonable user expect that to work?  Looks sensible to me.  
Is there a problem in parsing it?  I don't think so.  The body of the
conditional phrase of the add terminates when, having parsed a
"simple statement",  the next token is not a verb.  You may notice,
also, that I have chosen to interpret the definition of an implicit
scope terminator (4.4.4) liberally, by assuming that a scope
terminator for something other than the currently open scoped body
legitimately closes the inner scope.  

There may be cases, of course, where an inner scope is closed by an
element which is not valid in the containing context either.  I can't
promise that we will always find ourselves in the right place to best
diagnose an error of that kind, but I think the issue exists
regardless of how one tries to parse such things.

My vote, then, is that you read imperative statement as statement and
raise the issue again should that ever prove troublesome.

Mike



>>>>> "Laura" == Laura Tweedy <ltweedy@bellatlantic.net>
>>>>> wrote the following on Wed, 21 Jul 1999 00:58:53 -0400

  Laura> Here's another one for the COBOL gurus...  Okay, my next
  Laura> grammar question concerns my interpretation of the
  Laura> definition of "imperative statement".

  Laura> First, the standard (page IV-39) says: An imperative
  Laura> statement begins with an imperative verb and specifies an
  Laura> unconditional action to be taken by the object program or is
  Laura> a conditional statement that is delimited by its explicit
  Laura> scope terminator (delimited scope statement).

  Laura> Is this saying that only the conditional statement is
  Laura> delimited by a scope terminator, or is it that both
  Laura> imperatives and conditionals are delimited?

  Laura> Second, the standard on the same page says: An imperative
  Laura> statement may consist of a sequence of imperative
  Laura> statements, each possibly separated from the next by a
  Laura> separator.

  Laura> What, then, is the difference between a statement and a
  Laura> sentence?  Does a sentence in this case require a separator?
  Laura> Is the separator above necessarily a period, or does it also
  Laura> include END-ADD and such?

  Laura> Third, I read the rest of this section to say that if we
  Laura> have nested imperatives, such as:

  Laura> ADD 5 TO FOO ON SIZE ERROR ADD 3 TO BAR

  Laura> But, if the answer to my first question is, no, we don't
  Laura> need a closing delimiter, and since and "imperative
  Laura> statement" can be more than one statement, how would we
  Laura> differentiate between more imperative statements and those
  Laura> that should logically follow the original ADD?

  Laura> For example, how do we interpret:

  Laura> ADD 5 TO FOO ON SIZE ERROR ADD 3 TO BAR ACCEPT BAZ ADD 9 TO
  Laura> OTHER

  Laura> Based on this ambiguity, I'm inclined to believe that some
  Laura> kind of delimiter is required at the end of the "imperative
  Laura> statement".

  Laura> But, since "NOT ON SIZE ERROR" cannot occur within one of
  Laura> the nested ADDs, we can write the following without any
  Laura> ambiguity or explicit delimiters on the "imperative
  Laura> statement":

  Laura> ADD 5 TO FOO ON SIZE ERROR ADD 3 TO BAR ACCEPT BAZ ADD 9 TO
  Laura> OTHER NOT ON SIZE ERROR PERFORM SOME-PAR

  Laura> I am at a loss as to how to interpret the standard in this
  Laura> matter.  Does anyone have an idea as to the correct
  Laura> interpretation?

  Laura> Thanks!  laura -- Laura Tweedy .. ltweedy@bellatlantic.net

  Laura> -- This message was sent through the gnu-cobol mailing list.
  Laura> To remove yourself from this mailing list, send a message to
  Laura> majordomo@acm.cs.umr.edu with the words "unsubscribe
  Laura> gnu-cobol" in the message body.  For more information on the
  Laura> GNU COBOL project, send mail to
  Laura> gnu-cobol-owner@acm.cs.umr.edu.




--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to majordomo@acm.cs.umr.edu with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@acm.cs.umr.edu.