Re: Nested Conditionals (was RE: gnubol: Braiding #1 #2 #3

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

>>>>> "Bill" == William M Klein <wmklein@ix.netcom.com>
>>>>> wrote the following on Fri, 3 Dec 1999 14:13:19 -0600

  >> -----Original Message----- From:
  >> owner-gnu-cobol@wallace.lusars.net
  >> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of Tim
  >> Josling
  Bill>  <snip>
  >>  2. I agree with your interpretation of the standard. However
  >> given the MF extension, would you object to allowing nested
  >> conditionals provided that any extension is flagged, and that
  >> standard conforming code works as per the standard. Obviously
  >> you have the data and also feel strongly about this :-)
  Bill>   <much VERY useful snippage>

  Bill> Given my choice, this is one place that I really would prefer
  Bill> sticking to the Standard.  From my "old days" working at
  Bill> Micro Focus, I do remember a BUNCH of user-reported problems
  Bill> that they had with their extension (for nested conditionals).
  Bill> (They also had problems with their extension allowing
  Bill> END-PERFORM to be omitted for inline performs.)  I don't
  Bill> remember the details at the moment - and probably shouldn't
  Bill> "reveal" them anyway - but I do remember that they did occur.

  Bill> Personally, I just don't see the "harm" in requiring users to
  Bill> enter that "magical" scope terminator to change their
  Bill> conditional to an imperative - when they want to add nesting.

  Bill> ON THE OTHER HAND, as I am not one of the people who will be
  Bill> (can be with the "holes" in my technical knowledge)
  Bill> "building" the actual parser, if someone convinces me that it
  Bill> is MUCH CLEANER to allow for the nested conditionals, then I
  Bill> will "shut up" (well knowing me, make that "be a little more
  Bill> quiet" <G>)

Bill, I don't know where this extension first arose; I thought it
must have been in an IBM mainframe compiler, which would have induced
me and others to adopt it.  I have a pretty good idea why developers
consider it though.

If the standard had required every conditional part to be terminated,
the implemenation would have been marvelously CLEAN and we would
probably not be having this discussion.  I tried that in the grammar
that I'm playing with, and EVERY (not a lot, not most, EVERY)
ambiguity magically vanished.  Alas, that is not the rule.  Whether
or not we implement the extension, we have the same set of
ambiguities.  So, adopting it costs nothing, and avoids the
possibility that some user, some day will tell you that his program
compiles on your competitor's compiler but won't compile on yours.
Some day may not be too long away if MF has the extension.

The ambiguities themselves are not serious.  They arise in this
way.  

A sentence is defined to be one or more statements terminated by a
period.  (I will not indulge in the curious notion voiced by some
expositors of the standard, that "statement" is a plural noun.)  The
definition of statement includes cases with conditional parts which
have as their final part a sequence of statements.  Now the parser
generator is asked to distinguish such a statement from the grammar
element that follows it, which is, of course, according to the
definition of sentence,  a statement!  You can readily see why it
seems disturbed.

In reality, such ambiguities are essentially harmless because the
actual processing that occurs is that the conditional part will
accept statements until it encounters something that is not a
statement.  That is true, of course, whether or not the conditional
statement is nested.  It turns out to be a freebie.

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.