[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Nested Conditionals (was RE: gnubol: Braiding #1 #2 #3
As the former "owner" of the Micro Focus LRM, please GOD tell me you aren't
trying to "support" everything that they do - because some programmer some
day may ask you why it compiles there and not on your compiler.
Besides adding such "exciting" old technology as TRANSFORM and the ON
statement, this would force you to support every IBM variation (documented
and undocumented) that has ever existed (from "complex ODO's to allowing ">
then" - and I don't mean "than" - as a valid relational operator).
Again, I may not convince you of this, but I seriously doubt that you will
get "significant" user demand for allowing conditional statements where the
Standard requires imperatives - and if you allow it as an extension, I really
do guess that this is going to "break" some of the conforming stuff (I know
it did for Micro Focus).
Bill Klein
wmklein <at> ix.netcom.com
> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of Michael McKernan
> Sent: Friday, December 03, 1999 7:04 PM
> To: gnu-cobol@lusars.net
> Cc: mck@tivoli.mv.com
> Subject: Re: Nested Conditionals (was RE: gnubol: Braiding #1 #2 #3
>
>
> >>>>> "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.
--
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.