[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnubol: subsets
>>>>> "Bob" == RKRayhawk <RKRayhawk@aol.com>
>>>>> wrote the following on Tue, 23 Nov 1999 14:36:27 EST
Bob> In a message dated 11/21/99 12:11:38 PM EST, mck@tivoli.mv.com
Bob> writes: << We do not have a floor and ceiling standard. No
Bob> compiler has ever been denied certification for permissive
Bob> interpretation. >>
Bob> Surely the standard is the correct basis of design. But a
Bob> large issue, also present, is the code base. What would
Bob> potential users of the tool expect. Your orientation to least
Bob> astonishment is certainly appropriate. On a few things we may
Bob> have further interaction if you like, as we get to a workable
Bob> parser. Several brief notes if you can stand the continued
Bob> distraction.
I will not dispute your assertion that the standard is the correct
basis of design, but it's not divine revelation. The committee
comprises only human beings, who spend a lot of their time talking
about how they can bring the language into the 70's while at the same
time permitting programs from the 50's to continue to run.
What would potential users of the tool expect? I can tell you with a
conviction born of experience, that there is no more frustrating
exercise than to try to convince a user that his program is in
violation of the standard when his previous vendor ran it
successfully. I have worked for three major computer vendors
implementing COBOL, and when questions about restrictions in the
standard arose, the outcome was always the same: IBM will probably
allow it -- we'd better do that too.
I won't belabor this further. I have made my views known and my
referendum failed three votes to one with 48 abstentions. So,
enough said. Let's get on with it.
Bob> First, I have studied further the two tentative ADD rules you
Bob> posted and do now understand better the part ...
Bob> ( size_err END_ADD | { END_ADD } )
Bob> Which should allow for most of the 'third and fourth' rules I
Bob> speculated about.
All of them, I would hope.
Bob> A very brief note about your comment
Bob> <<Also consider this variant
Bob> ADD ... SIZE ... SUBTRACT ... SIZE ... PERIOD
Bob> which appears to be as invalid as the first, but trashes the
Bob> law of least astonishment, since the PERIOD has traditionally,
Bob> legitimately, terminated anything that's going on.
>>>
Bob> I think you know this, but just to pitch in as much as I can,
Bob> the period is an implicit scope terminator. In the example
Bob> there are _no_ explicit scope terminators. So the arithmetic
Bob> statements are not of the 'imperative' type. I think you
Bob> realize that and are commenting further on how convoluted the
Bob> landscape is as a result of standards committee politics.
Actually, I didn't know what the rule was when I wrote that. Now,
having read it, I think it may raise more questions than it answers.
Bob> You stated (now with an explicit scope terminator)
Bob> << ...
Bob> In the original sample
Bob> ADD ... SIZE ... SUBTRACT ... SIZE ... END-ADD
Bob> the END-ADD cannot possibly bind to the SUBTRACT so it's an
Bob> error or it belongs to the ADD. The standard says it's an
Bob> error, but accepting it and assigning it (what appears to be)
Bob> its intended semantics is not a problem ....
>>>
Bob> Yes but what is the error? The END-ADD is not an error as I
Bob> would use a compiler, instead the second SIZE clause is an
Bob> error! Because it should associate with the first arithmetic
Bob> statement, and in the code posited the ADD has two ON SIZE
Bob> ERROR clause. I realize that you realize this understanding,
Bob> but particularly I am saying that this is not a piece of
Bob> source code fit for affirmative code generation.
Your description is more accurate, the unterminated SIZE phrase is
the error, but the error does not exist until the END-ADD is
encountered. I'm not sure why you say the ADD has two SIZE clauses.
The second SIZE phrase may be in error by not being terminated, but
there doesn't seem to be any doubt that it belongs to the subtract.
Bob> What I wish to offer you is that to a significant number of
Bob> people there is nothing selective about this. In other words I
Bob> am not just trying to get my view in here. It is the code
Bob> base we are after. This situation does not seem selective at
Bob> all to quite a few people. The response to any of these things
Bob> in professional environs, in which I know you have lots of
Bob> experience, is frequently just utterly ruthless and unfeeling.
Bob> " Put the explicit scope terminators in there! " As in, in the
Bob> source code.
Local standards are often burdensome, but, if they are well conceived
they can save a lot of grief. That's not our problem, of course.
Our reference manual is the contract. The compiler has to do what
the manual says it will do.
Bob> It is not selective, as the COBOL programmer uses these rules
Bob> in application work. Briefly, again the situation where you
Bob> have a NOT on one of these clauses, as in ...
Bob> ADD ... SIZE ... SUBTRACT ... NOT SIZE ... END-ADD or
Bob> ADD ... NOT SIZE ... SUBTRACT ... SIZE ... END-ADD
Bob> We must seek to assist the tool user in these
Bob> circumstances. The user may very well mean two very different
Bob> things in each of these cases. The programmer is the source
Bob> of the ambiguity here. If we meet this challenge, then all
Bob> the rest (for example ADD/SUBTRACT, MULTIPLY/ADD) falls into
Bob> place.
I guess I don't get it, Bob. If the standard had said nothing about
restricting conditional parts to imperatives only, then these
statements would be clear and unambiguous.
( ADD ... SIZE ... ( SUBTRACT ... NOT SIZE ... ) END-ADD ) or
( ADD ... NOT SIZE ... ( SUBTRACT ... SIZE ... ) END-ADD )
Do you see it differently?
Bob> In a message dated 11/21/99 12:11:38 PM EST, mck@tivoli.mv.com
Bob> writes:
Bob> << If you think adding a huge amount of complexity to the
Bob> processor to accommodate this rather artificial restriction is
Bob> a good use of our limited resources, I can only say that I
Bob> respectfully disagree.
>>>
Bob> How should we define 'huge'? The surprising thing about COBOL
Bob> is that it is different in kind. It is a fact that it is
Bob> difficult to specify it with available tools. I personally
Bob> believe it _is_ a huge task. And I mean that with the most
Bob> sincere and supportive sentiments. It is huge. The standards
Bob> compliance is the only realistic orientation for evolving our
Bob> specs, but there is competition which determines the worth of
Bob> efforts here.
We're adding fifteen major rules to the grammar to satisfy the
conditional termination requirement. This is to provide a fips flag
warning that will, in all probability, never be seen in the lifetime
of the compiler. It's all relative. This just looks like a big
howitzer for a small gnat.
The compiler itself is huge. When we have a parser that we're happy
with, we'll be about twenty percent of the way home.
Bob> I think that a success criteria is to get large numbers of
Bob> people to use this tool. The presence of competing compilers
Bob> that trap errors, sets a parallel standard that should be
Bob> considered. My position is different than yours.
Bob> Real COBOL programmers could mean two very different things in
Bob> the code form ...
Bob> ADD ... SIZE ... SUBTRACT ... SIZE ... END-ADD
Bob> (The meaning is they mean a mistake, or they mean something
Bob> they are not allowed to say that way).
Bob> just as they could mean two different things in
Bob> ADD ... SIZE ... SUBTRACT ... NOT SIZE ... END-ADD
Bob> as well as two meanings in
Bob> ADD ... NOT SIZE ... SUBTRACT ... SIZE ... END-ADD
Bob> I don't think that these points actually add to the size,
Bob> ... :-) ... of the problem of specifying the parser(s),
Bob> because you already need to be able to talk to the tool user
Bob> about things like
Bob> ADD ... SIZE ... SIZE ... END-ADD
Bob> ADD ... SIZE ... SIZE ... SIZE ... END-ADD and
Bob> ADD ... SIZE ... SIZE ... NOT SIZE ... NOT SIZE ...
Bob> SIZE ... END-ADD
Huh? Where did these come from? The grammar fragment that I
submitted earlier permitted no more than one SIZE phrase and no more
than one NOT SIZE phrase. Anything more would be rejected.
Bob> All of the cases we are dealing with as supposed
Bob> 'astonishment' monsters are just special cases of the general
Bob> rule that the SIZE ERROR and NOT SIZE ERROR are _not_ ordinal,
Bob> and should not be repeated. We can not just roll over, we have
Bob> to diagnose each one, and get successfully to the END-ADD, or
Bob> the next verb if present, because we could be in one very deep
Bob> nested structure, and we need to keep compiling.
I know you'd like the diagnosis to be more explicit, but these will
undoubtedly drop out simply as unexpected elements.
Bob> I am convinced that the real problem is the assumption of
Bob> correct number of occurrence and correct ordering, that comes
Bob> incidentally with the use of tools that are provided with
Bob> positive logic examples.
Bob> It is regrettable but to trap
Bob> ADD ... SIZE ... SUBTRACT ... SIZE ... END-ADD we must
Bob> either set down an error production that associates the second
Bob> size clause with the inner arithmetic statement and then flags
Bob> that statement as erroneously conditional, or we must flag the
Bob> clause as duplicate in the outter arithmetic statement.
The grammar says "ADD ... SIZE ..." and "SUBTRACT ... SIZE ...".
There will be no rule that would accept
"ADD ... SIZE ... <something else> SIZE"
so only the first option is reasonable at all.
Bob> We can not approve the source for code generation in this case
Bob> ADD ... SIZE ... SUBTRACT ... SIZE ... END-ADD and we can not
Bob> approve the source for code generation in this case ADD
Bob> ... SIZE ... SUBTRACT ... NOT SIZE ... END-ADD and we can not
Bob> approve the source for code generation in this case ADD
Bob> ... NOT SIZE ... SUBTRACT ... SIZE ... END-ADD and that is all
Bob> the same rule as rejecting ADD ... NOT SIZE ... SUBTRACT ...
Bob> SIZE ... NOT SIZE ... NOT SIZE ... SIZE ... * NOTE outter
Bob> arithmetic statement explicit scope termination END-ADD
Well I could :-) I might even be willing to generate for that last
thing once we culled out the extra stuff.
Bob> So it is huge in that optimistic rules for the outter
Bob> arithmetic statement will just fall over. But your actual
Bob> comments seem to imply that you would associate the second ON
Bob> SIZE clause with the inner arithmetic statment when it is not
Bob> explicitly scope terminated. Please do not do that. That would
Bob> not be an astonishment, but many would consider it a compiler
Bob> error. Statements like
Bob> ADD ... SIZE ... SUBTRACT ... NOT SIZE ... END-ADD
Bob> would commence to behave differently when migrated to a
Bob> platforms hosted by such a compiler.
I doubt it seriously, Bob. The SIZE phrase is defined to be just a
part of the syntax of certain statements. Without a preceding ADD or
whatever it has no meaning at all. It must bind to the preceding verb
if that verb can take a SIZE clause and does not already have one.
Bob> To be quite honest a better idea from senior programmers would
Bob> be to just get the aritmetic out of the conditional clause, as
Bob> in, do a PERFORM. But the code is there in the real world. A
Bob> more serious version of this is the NOT AT END/ AT END and the
Bob> NOT INVALID KEY / INVALID KEY. Where field practice is that
Bob> the code base has far fewer such case, but the alternate
Bob> interpretation is much more devastating.
Bob> As a general interpretation, I believe you feel that these
Bob> clause should be left associative. An orientation that simply
Bob> does not belong with COBOL. In that regard, COBOL is not huge
Bob> so much as it is simply different.
Actually, my take is that SIZE is right associative.
ADD...SIZE...ADD...SIZE...ADD...SIZE
parses thusly
( ADD...SIZE...( ADD...SIZE...( ADD...SIZE ) ) )
I don't know that associativity is especially strange in COBOL. I
think we could find a number of examples of either.
Bob> The rules you have been kind enough to post already are quite
Bob> good. I believe that we will need supra-tool mechanisms to
Bob> compensate for the fact that with proper rules such as yours,
Bob> the outter aritmetic/I-O verbs will frequently get multiple
Bob> occurences of clauses such as discussed. By supra-tool
Bob> mechanisms I mean that sub rules need to count occurences of
Bob> clauses (and in some cases record an artifact that can be
Bob> understood as order of occurence), in some data structure that
Bob> the higher level rule can review.
I sincerely hope not :-) Syntax techniques are okay for
SIZE ... NOT SIZE ... and NOT SIZE ... SIZE ...
but when you look at the set of clauses that may be present in a
declaration, written in any order, then parsing breaks down and you
see what else is in your kit.
--
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.