[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnubol: subsets
In a message dated 11/21/99 12:11:38 PM EST, mck@tivoli.mv.com writes:
<< We do not have a floor and
ceiling standard. No compiler has ever been denied certification
for permissive interpretation. >>
Surely the standard is the correct basis of design. But a large issue, also
present, is the code base. What would potential users of the tool expect.
Your orientation to least astonishment is certainly appropriate. On a few
things we may have further interaction if you like, as we get to a workable
parser. Several brief notes if you can stand the continued distraction.
First, I have studied further the two tentative ADD rules you posted and do
now understand better the part ...
( size_err END_ADD
| { END_ADD }
)
Which should allow for most of the 'third and fourth' rules I speculated
about.
A very brief note about your comment
<<Also consider this variant
ADD ... SIZE ... SUBTRACT ... SIZE ... PERIOD
which appears to be as invalid as the first, but trashes the law of
least astonishment, since the PERIOD has traditionally, legitimately,
terminated anything that's going on.
>>
I think you know this, but just to pitch in as much as I can, the period is
an implicit scope terminator. In the example there are _no_ explicit scope
terminators. So the arithmetic statements are not of the 'imperative' type.
I think you realize that and are commenting further on how convoluted the
landscape is as a result of standards committee politics.
You stated (now with an explicit scope terminator)
<< ...
In the original sample
ADD ... SIZE ... SUBTRACT ... SIZE ... END-ADD
the END-ADD cannot possibly bind to the SUBTRACT so it's an error or
it belongs to the ADD. The standard says it's an error, but
accepting it and assigning it (what appears to be) its intended
semantics is not a problem ....
>>
Yes but what is the error? The END-ADD is not an error as I would use a
compiler, instead the second SIZE clause is an error! Because it should
associate with the first arithmetic statement, and in the code posited the
ADD has two ON SIZE ERROR clause. I realize that you realize this
understanding, but particularly I am saying that this is not a piece of
source code fit for affirmative code generation.
What I wish to offer you is that to a significant number of people there is
nothing selective about this. In other words I am not just trying to get my
view in here. It is the code base we are after. This situation does not
seem selective at all to quite a few people. The response to any of these
things in professional environs, in which I know you have lots of experience,
is frequently just utterly ruthless and unfeeling. " Put the explicit scope
terminators in there! " As in, in the source code.
It is not selective, as the COBOL programmer uses these rules in application
work. Briefly, again the situation where you have a NOT on one of these
clauses, as in ...
ADD ... SIZE ... SUBTRACT ... NOT SIZE ... END-ADD
or
ADD ... NOT SIZE ... SUBTRACT ... SIZE ... END-ADD
We must seek to assist the tool user in these circumstances. The user may
very well mean two very different things in each of these cases. The
programmer is the source of the ambiguity here. If we meet this challenge,
then all the rest (for example ADD/SUBTRACT, MULTIPLY/ADD) falls into place.
In a message dated 11/21/99 12:11:38 PM EST, mck@tivoli.mv.com writes:
<< If you think adding a
huge amount of complexity to the processor to accommodate this rather
artificial restriction is a good use of our limited resources, I can
only say that I respectfully disagree.
>>
How should we define 'huge'? The surprising thing about COBOL is that it is
different in kind. It is a fact that it is difficult to specify it with
available tools. I personally believe it _is_ a huge task. And I mean that
with the most sincere and supportive sentiments. It is huge. The standards
compliance is the only realistic orientation for evolving our specs, but
there is competition which determines the worth of efforts here.
I think that a success criteria is to get large numbers of people to use this
tool. The presence of competing compilers that trap errors, sets a parallel
standard that should be considered. My position is different than yours.
Real COBOL programmers could mean two very different things in the code form
...
ADD ... SIZE ... SUBTRACT ... SIZE ... END-ADD
(The meaning is they mean a mistake, or they mean something they are not
allowed to say that way).
just as they could mean two different things in
ADD ... SIZE ... SUBTRACT ... NOT SIZE ... END-ADD
as well as two meanings in
ADD ... NOT SIZE ... SUBTRACT ... SIZE ... END-ADD
I don't think that these points actually add to the size, ... :-) ... of the
problem of specifying the parser(s), because you already need to be able to
talk to the tool user about things like
ADD ... SIZE ...
SIZE ...
END-ADD
ADD ... SIZE ...
SIZE ...
SIZE ...
END-ADD
and
ADD ... SIZE ...
SIZE ...
NOT SIZE ...
NOT SIZE ...
SIZE ...
END-ADD
All of the cases we are dealing with as supposed 'astonishment' monsters are
just special cases of the general rule that the SIZE ERROR and NOT SIZE ERROR
are _not_ ordinal, and should not be repeated. We can not just roll over, we
have to diagnose each one, and get successfully to the END-ADD, or the next
verb if present, because we could be in one very deep nested structure, and
we need to keep compiling.
I am convinced that the real problem is the assumption of correct number of
occurence and correct ordering, that comes incidentally with the use of tools
that are provided with positive logic examples.
It is regrettable but to trap
ADD ... SIZE ... SUBTRACT ... SIZE ... END-ADD
we must either set down an error production that associates the second size
clause with the inner arithmetic statement and then flags that statement as
erroneously conditional, or we must flag the clause as duplicate in the
outter arithmetic statement.
We can not approve the source for code generation in this case
ADD ... SIZE ... SUBTRACT ... SIZE ... END-ADD
and we can not approve the source for code generation in this case
ADD ... SIZE ... SUBTRACT ... NOT SIZE ... END-ADD
and we can not approve the source for code generation in this case
ADD ... NOT SIZE ... SUBTRACT ... SIZE ... END-ADD
and that is all the same rule as rejecting
ADD ...
NOT SIZE ...
SUBTRACT ...
SIZE ...
NOT SIZE ...
NOT SIZE ...
SIZE ...
* NOTE outter arithmetic statement explicit scope termination
END-ADD
So it is huge in that optimistic rules for the outter arithmetic statement
will just fall over. But your actual comments seem to imply that you would
associate the second ON SIZE clause with the inner arithmetic statment when
it is not explicitly scope terminated. Please do not do that. That would not
be an astonishment, but many would consider it a compiler error. Statements
like
ADD ... SIZE ... SUBTRACT ... NOT SIZE ... END-ADD
would commence to behave differently when migrated to a platforms hosted by
such a compiler.
To be quite honest a better idea from senior programmers would be to just get
the aritmetic out of the conditional clause, as in, do a PERFORM. But the
code is there in the real world. A more serious version of this is the NOT
AT END/ AT END and the NOT INVALID KEY / INVALID KEY. Where field practice
is that the code base has far fewer such case, but the alternate
interpretation is much more devastating.
As a general interpretation, I believe you feel that these clause should be
left associative. An orientation that simply does not belong with COBOL. In
that regard, COBOL is not huge so much as it is simply different.
The rules you have been kind enough to post already are quite good. I
believe that we will need supra-tool mechanisms to compensate for the fact
that with proper rules such as yours, the outter aritmetic/I-O verbs will
frequently get multiple occurences of clauses such as discussed. By
supra-tool mechanisms I mean that sub rules need to count occurences of
clauses (and in some cases record an artifact that can be understood as order
of occurence), in some data structure that the higher level rule can review.
Best Wishes
and yes it is huge (but I didn't do that)
Bob Rayhawk
RKRayhawk@aol.com
--
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.