Re: gnubol: WHEN and other conditional phrases

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

>>>>> "Randall" == Randall Bart <Barticus@att.net>
>>>>> wrote the following on Tue, 14 Dec 1999 22:10:46 -0800

  Randall> At 15:19 12/13/99 , RKRayhawk@aol.com wrote:
  >> In a message dated 12/13/99 5:39:10 PM EST,
  >> SiedentopC@Alte-Leipziger.de writes:
  >> 
  >> << ==000016==> IGYPS2112-E The "EVALUATE" verb did not have a
  >> matching scope terminator.  A scope terminator was inserted on
  >> line 24.  The execution results may not be correct.  >>

  Randall> I like this message.  I might leave out " The execution
  Randall> results may not be correct," because that's implied by the
  Randall> level E severity.  I would also like a second message at
  Randall> line 24 saying something like "The EVALUATE verb at line
  Randall> 16 does not have an explicit scope terminator.
  Randall> END-EVALUATE inserted here."  Some might object to giving
  Randall> two diagnostics, but there are valid reasons to put the
  Randall> message in each place.  Rather than argue over which spot
  Randall> is most appropriate, let's just use both.

Both line numbers are cited, making this an excellent diagnostic
message.  I would consider two messages next best, but unnecessary if
it's feasible to be as explicit as IBM is.

  Randall> Also I think we should plagi^H^H^H^H^H imitate IBM's
  Randall> nesting level indicators.

This may be more difficult than it appears.  The source listing is
usually generated early in the compilation (lex time) and trying to
indicate levels at that time is approximate at best.  The alternative
is to update the listing file when sufficient knowledge of the
structure is available.  One would also need to be able to decide
when unconventional formatting of the source make it nonsense.

  >> I would like to note in passing that this particular vendor is
  >> flagging several distinct situations with a single error number:
  >> IGYPS2112.
  >> 
  >> It may be easily possible for us to make distinctions, we will
  >> defnitely need specific code to detect specific implied
  >> terminations. This is noteworthy because the implied termination
  >> of an EVALUATE without a WHEN OTHER probably should not be
  >> recovered, where as it may be reasonable to recover whilst
  >> trapping an implied terminator for an EVALUATE that does have
  >> that alternate clause.

  Randall> I agree and disagree.  I agree that we should have a
  Randall> separate error number for each verb.  What I don't see is
  Randall> why you think EVALUATE without WHEN OTHER is so distinct
  Randall> from EVALUATE with WHEN OTHER.  The former can pair with
  Randall> WHEN, WHEN OTHER, or END-EVALUATE, the latter can pair
  Randall> with END-EVALUATE only.  Either may be implicitly
  Randall> terminated by a conditional phrase of a containing
  Randall> statement (as long as that phrase doesn't pair to the last
  Randall> statement of the statement block).  EVALUATE with WHEN
  Randall> OTHER can also be implicitly terminated by the WHEN of a
  Randall> containing SEARCH or EVALUATE.

Agreed.

  Randall> In all the talk about mixing SEARH with EVALUATE, I think
  Randall> we've missed mixing SEARCH with SEARCH and EVALUATE with
  Randall> EVALUATE.  Examples:

SEARCH
     AT END
         SEARCH ALL
             WHEN
     WHEN

  Randall> Since SEARCH ALL can only take one WHEN, does the second
  Randall> WHEN bind to the outer SEARCH? 

Yes.  In general, with nested constructs, when the syntax of the
current verb is unable to accept the next element, and certainly when
the parse of the current statement can be terminated successfully,
parsing should proceed by attempting to continue the parse of the
enclosing statement with the current token.  This is not a complete
answer, but it is the most sensible principle to adopt.

  Randall> Similarly:

EVALUATE
     WHEN
         EVALUATE
             WHEN
             WHEN OTHER
     WHEN

The principle applies.  The syntax of EVALUATE cannot accept WHEN
after WHEN OTHER so parsing continues at the outer EVALUATE.

  Randall> Switching to a different class of conditional phrases,
  Randall> what about this:

READ RANDOM-FILE
     INVALID KEY
        WRITE SEQUENTIAL-FILE
     NOT INVALID KEY

  Randall> Since WRITE of a sequential file cannot take NOT INVALID
  Randall> KEY, does it bind to the READ?  (Bill, has J4 ever ruled
  Randall> on this one?)

Sure it does.  Is this a great policy or what?

I'm not trying to treat this with less gravity than it warrants, but
I believe the principle is reasonably intuitive for the programmer
and it's the most natural and least error prone mechanism for a
parser.  Essentially, we're parsing as if the terminators are not
required, making diagnosis an incidental requirement.

Best regards,

Mike



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