[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gnubol: subsets
I had expressed the view that
<<
ADD ... SIZE ... SUBTRACT ... NOT SIZE ... END-ADD
would commence to behave differently when migrated to a
platforms hosted by such a compiler, as being discussed
>>
In response,In a message dated 11/23/99 10:53:34 PM EST, mck@tivoli.mv.com
writes:
<<
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.
>>
We do disagree, the interior arithmetic statements, if they can be
interpreted as simple, must yield the nearby SIZE clause. This actually
follows from the need to allow the SIZE/NOT SIZE to transpose and permit
simple arithmetics on the conditional clauses. I must cover a lot of ground
to get this in complete detail. But I think this is worth it because the
issue goes beyond the arithmetics.
Conditional Encounters of Three Kinds
I'll try again. This is obtuse at first but real clear once you see it.
We can encounter an arithmetic statement in three kinds of ways
Close Encounter of the First Kind
SUBTRACT c FROM d.
that is an imperative statement.
Close Encounter of the Second Kind
SUBTRACT c FROM d ON SIZE ERROR PERFORM xyz.
that is an imperative statement which became a conditional statement on
account of the presence of the conditional ON ERROR clause.
Close Encounter of the Third Kind
SUBTRACT c FROM d ON SIZE ERROR PERFORM xyz END-SUBTRACT.
that is an imperative statement, the explicit scope terminator fixed it up
for us.
The issue gets mildly topsy-turvy because you can have both alternates of
the conditional clauses. So the following is legitimate.
ADD a TO b
ON SIZE ERROR
PERFORM xyz
NOT ON SIZE ERROR
PERFORM wvu
END-ADD.
Each of the two alternate clauses are okay because the statements they
contain (the PERFORMs) are imperatives.
Consider again the Close Encounter of the First Kind ...
SUBTRACT c FROM d.
is an imperative statement Yet would it be an imperative in the absence of
the implicit scope terminator period?
Is
SUBTRACT c FROM d
an unconditional imperative?
And what to make of code like this:
ADD a TO b
ON SIZE ERROR
SUBTRACT c FROM d
NOT ON SIZE ERROR
PERFORM wvu
END-ADD.
If ON SIZE ERROR clauses were right associative there is no challenge to
this. But that can _not_ be correct, because if these things were right
associative the statement with the two PERFORMs could not compute for us.
Instead what is needed is a set of rules that compels the inner statements
along the conditional branches to reduce owing to lookahead seeing that they
can not continue. That's why the arithmetic rules need to be broken out into
certain distinct subsets (conditional and imperative). In this
ADD/SUBTRACT/PERFORM/END-ADD the distance from the commencement of the
second conditional expression (the NOT token) to the explicit scope
terminator END-ADD could be thousands of lines of code. And still the
SUBTRACT would have no explicit scope terminator so it is a simple
imperative! Because that is the only thing we could expect if the coder is
obeying the rules.
So then there is the other monster, when the interior arithmetic has the
same verb as the outer...
ADD a TO b
ON SIZE ERROR
ADD ccc TO ddd
NOT ON SIZE ERROR
PERFORM wvu
END-ADD.
That innocent looking missile could take us out if we are not careful.
It is a fact that imperative
statements are permitted in the interior. ADD a to b
is an imperative statement because it has no conditional clause. But so is
ADD a to b conditional-clause END-ADD. We must look ahead before we decide.
This example glues the NOT ON SIZE ERROR to the interior ADD. Whereas the
example with SUBTRACT glued the clause differently (that is quite important
it was the different specific explicit scope terminators that made the
difference).
With only one END-ADD on there you may still think you have some wiggle room.
You don't.
This following statement proves my point.
ADD a TO b
ON SIZE ERROR
ADD ccc TO ddd
NOT ON SIZE ERROR
PERFORM wvu
END-ADD
END-ADD.
Just because the interior has an arithmetic verb does not allow you to point
blank conclude that the conditional clause is an error in the interior.
I know that you hate this monster but when I trash the explicit scope
terminators altogether, the monster goes and lives clearly in the outer
arithmetic statement ...
ADD a TO b
ON SIZE ERROR
ADD ccc TO ddd
NOT ON SIZE ERROR
PERFORM wvu
.
That is fine code, works great, newbies might enjoy an warning on that.
When newbies or geniuses leave out a NOT by accident, as in
ADD a TO b
ON SIZE ERROR
ADD ccc TO ddd
ON SIZE ERROR
PERFORM wvu
.
We have an error (duplicate ON SIZE ERROR clauses), but there is no ambiguity
or confusion.
When you look at the possibilities you can not fairly tag the
NOT ON SIZE ERROR as right or wrong, or associated it at all in anyway when
you first encounter it (it is the deep lookahead that determines the matter).
Don't think 'tool'. Think 'COBOL'. The statements have _type_! Just as data
references have _type_. Non business computer science folks think that
IF a = b OR data-name
is ambiguous with
IF a = b OR condition-name
Not at all! We must manifest _type_ in the grammar. Statements also have
_type_. It is monsterous but type determines shift/reduce. It will be hard to
code. But once you see it, then it is nolonger hard to see.
ON SIZE ERROR clauses are not right associative (that is definite), they are
also not left associative. In ...
ADD... SIZE ... SUBTRACT ... SIZE ... END-ADD.
You have two ON SIZE ERROR clauses in the add statement. There are no ON SIZE
ERROR clauses on the subtract. In
ADD... SIZE ... SUBTRACT ... [NOT] SIZE ... END-ADD.
This subtract also has no variety of [NOT] ON SIZE ERROR clause. The ADD has
both a ON SIZE ERROR and a NOT ON SIZE ERROR clause, which is okay. This
surprises junior programmers but not senior programmers. SIZE and NOT SIZE
have no ordinality.
In some of your comments you seem to be talking about ending a conditional
clause. That may not be the best orientation. It is the arithmetic or I/O
statement that needs termination. You are trying to break out of the
difficulty by thinking that the SIZE clause is %right associative, and trying
to end it or not. It is really the arithmetic statements that are still
concurrently alive: we end or do not end the arithmetic statement(s).
An explicit scope terminator will do that, I am not sure the period as an
implicit scope terminator can do it, but I am confident that the ELSE and the
WHEN tokens can accomplish the scope termination implicitly. (It is actually
the precedence of ELSE (and WHEN) that does the trick).
But the real issue here is simply tool usage. Associativity definitely can
not conquer the conditional clauses. I speculate that we will actually need
to make them %left associative if not %nonassoc. That does not solve the
problem though. It is the lookahead mechanism that sees that an interior
arithmetic statement can or cannot encompass the range covered. When the
correct token arrives, the current conditional clause terminates and reduces
to a single symbol. The interior statement can or cannot encompass it based
upon exactly what token follows the clause.
As long as SIZE/NOT SIZE and INVALID/NOT INVALID are not ordinal then no
sequence in a rule, and no associativity is going to conquer it. The
following three cases are the same mistake: namely three ON SIZE ERROR
clauses for the first arithmetic statemen
ADD ... SIZE ... SIZE ... SIZE ... SUBTRACT ... END-ADD
ADD ... SIZE ... SIZE ... SUBTRACT ...SIZE ... END-ADD
ADD ... SIZE ... SUBTRACT ...SIZE ... SIZE ... END-ADD
We can not glue the any of them to to the inner arithmetic statement.
Consider again
ADD ... SIZE ... SUBTRACT ...NOT SIZE ... END-ADD
ADD ... NOT SIZE ... SUBTRACT ... SIZE ... END-ADD
If you don't see it, it is hard to see. Once you see it, it is easy to see. I
think the astronomer Herschel said that, in reference to the final
comprehension that the rings around Saturn, seen poorly in early telescopes,
were not cup-handle shaped appendages but instead a full ring tilted.
These last two examples are both valid, and in each case the outer arithmetic
statement has one each of an ON SIZE ERROR and a NOT ON SIZE ERROR. It
would be nice to warn the user about the transfer of scope across the inner
arithmetic statement.
There is some chance that you think I am quoting posted grammars, where
usually I am just positing code examples.
You can not do the reduction of the inner arithmetic statement that you have
in mind. It is noteworthy that the outer arithmetic statement is likewise not
reduced when it encounters the inner arithmetic verb on its conditional
clause. Effectively they have some concurrency in scope.
As soon as you try to work out the transposition of the non ordinal
conditional clauses this all becomes clear as a necessity. If the inner
arithmetic statement is not explicitly scope terminated, then any conditional
clause there abouts simply does not belong to the interior.
So in these two statements
ADD ... SIZE ... SUBTRACT ...NOT SIZE ... END-ADD
ADD ... NOT SIZE ... SUBTRACT ... SIZE ... END-ADD
all of the conditional clauses belong to the outer arithmetic statement. We
must be able to do that. Consequently
ADD ... SIZE ... SUBTRACT ...SIZE ... END-ADD
is no more difficult to diagnose than
ADD ... SIZE ... SIZE ...SUBTRACT ... END-ADD
It is simple, the outer aritmetic statement lives on, and we must bark when
we see the duplicate.
This does not fit Bachus-Naur grammar forms very well. But we must also get
this correctly understood as distinct from the IF statement (particularly the
ELSE). Note the IF and ELSE in the following
IF
ADD ... SIZE ... SUBTRACT ...SIZE ... END-ADD ...any_thing_but_else
is an error (not because the inner arithmetic statement has a conditional,
but because the outer arithmetic statement has two identical SIZE clauses.
The following
IF
ADD ... SIZE ... SUBTRACT ...NOT SIZE ... END-ADD ...any_thing_but_else
is fine (but as I say, a superior compiler would emit a warning, because
junior programmers might be surprised).
But now hold onto your hat
IF
ADD ... SIZE ... SUBTRACT ...SIZE ... ELSE ...
is the same duplicat SIZE clause and, ... hold tight ...
IF
ADD ... SIZE ... SUBTRACT ...NOT SIZE ... ELSE ...
is just fine, but would give a junior prgrammer misgivings.
The following statement
IF
ADD ... SIZE ... SUBTRACT ...SIZE ... ELSE ...
is fixed with one explicit scope terminator
IF
ADD ... SIZE ... SUBTRACT ...SIZE ... END-SUBTRACT ELSE ...
a senior prgrammer
would endeavor to bullet proof the whole mess with redundancy
IF
ADD ... SIZE ... SUBTRACT ...SIZE ... END-SUBTRACT END-ADD ELSE ...
I have known managers who like this kind of thing and also all manner of
reduplicative parens.
(I know it is painful but the END-ADD is redundant, because the ELSE is
a distinguished delimiter, it burns it delimiting proclivity right back to
the [THEN] no matter what kind of arithmetics are going on).
But notice that this statment
IF
ADD ... SIZE ... SUBTRACT ...NOT SIZE ... ELSE ...
is clearly not the same meaning as
IF
ADD ... SIZE ... SUBTRACT ...NOT SIZE ... END-SUBTRACT ELSE ...
Both are legit, but like I say the first deserves atleast an informational
diagnostic.
I know that this aggravates some. But don't get upset with the messenger.
Have a look at the following with indentation that corresponds to actual
correct interpretation. The inner arithmetic statement has no explicit scope
terminator, so they can not take on the following conditional clause.
PARAGRAPH-ARRRGH.
ADD a to b
ON SIZE ERROR
ADD 1 to summ-up-todays-problems
NOT ON SIZE ERROR
ADD 1 to on-a-clear-day-we-can-see-it
* here is an implicit scope terinator, EOS
.
* It does not have the power to terminate the interior arithmetic statements
'explicitly'. Consequently they are simple arithmetic statements.
So just vary this in the obvious way ..
PARAGRAPH-ARRRGH-1.
ADD a to b
ON SIZE ERROR
ADD 1 to summ-up-todays-problems
NOT ON SIZE ERROR
ADD 1 to on-a-clear-day-we-can-see-it
END-ADD.
PARAGRAPH-ARRRGH-2.
ADD a to b
ON SIZE ERROR
ADD 1 to summ-up-todays-problems
NOT ON SIZE ERROR
ADD 1 to on-a-clear-day-we-can-see-it
END-ADD
END-ADD.
PARAGRAPH-ARRRGH-3.
ADD a to b
ON SIZE ERROR
ADD 1 to summ-up-todays-problems
NOT ON SIZE ERROR
ADD 1 to on-a-clear-day-we-can-see-it
END-ADD
END-ADD
END-ADD.
* yes I made the indentation drift a bit on purpose.
Surely in PARAGRAPH-ARRRGH-3 the NOT ON SIZE ERROR glues to the second add.
But how can you paste it in there if you think it is a mistake? You can not
tell if it is a mistake until much further reduction (beyond the NOT).
The same thing actually already happened in PARAGRAPH-ARRRGH-2 but the
absence of the third END-ADD might confuse someone into thinking there was
yet still room to breath. It ain't so.
The implication goes to the I/O verbs and SEARCH. SEARCH looks so much like
EVALUATE that you would think we had it made. Sorry, END-SEARCH is not
required, and some dummy might well code a search within a search (although
what do we care, ... in that event lets just generate something that pays
them back, :-( ... no, only kidding :-) ... I am back now, you see ... it is
those WHEN clauses of the EVALUATE statements that might enclose the SEARCH
statement which might not be explicitly scope terminated. In such a
situation, ... now get this fans ... the EVALUATE WHEN clause which contains
the SEARCH would have to be the last ordinary WHEN clause of the EVALUATE, or
else any subsequent ordinary WHEN clause will look like it should glue to the
SEARCH statement. Maybe WHEN OTHER could follow an unterminated SEARCH in a
preceding EVALUATE WHEN clause ((if that is true then the combination
WHEN+OTHER is more distinguished then WHEN simple, yikes, but maybe.)).
It boggles the mind a little. It comes back to the same thing, senior
programmers will instruct to put the explicit scope terminators in there (if
not clear put them everywhere), that gets the application folks out of the
lower world. But compiler writers do not live in heaven.
What this means is that the conditional clauses can not be defined as having
the scope terminator tokens within them. These must be abruptors to the
clause. ((Some of your comments refer to terminating the clause in a way that
seemed to imply inclusion of the terminator in the clause, atleast
conceptually, sample grammar postings don't reflect that.))
The clauses need to reduce to a symbol. The next available (most interior)
statement then has a choice to accept the symbol as its continuation based
upon what scope terminator is after the symbol which represents the reduced
conditional clause. I think that means k=2. Which if true blows most of the
right hand reducers off the list. But it also means that the use of back
trackers with k=1, isn't good enough (I do not understand the predicate idea
yet).
But the problem of the alternate conditionals also fairly strongly recommends
unconventional use of the tools. Real code has true monsters like my posited
triple ON SIZE ERROR. We need to handle those, and I think it goes to the
nieve hierarchy issue.
There is a lot going on in these discussions, but if one groks the nieve
hierarchy issue, then one might begin to think that we are not really trying
to get to the top; all we really want to do is get through the current
syntactic construct.
Thanks for your patient interactions, more anon, as appropriate.
Best Wishes
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.