Re: Parsing nested statements: was Re: gnubol: subsets

[RKRayhawk@aol.com]

In a message dated 11/25/99 1:18:17 AM EST, mck@tivoli.mv.com writes:

<< 
 It looks to me like they're saying "you're not allowed to write a
 conditional statement within another statement, but if you do, we're
 going to assume that it's been terminated."  
  >>

They are not. 

They are saying that they will assume that it is not explicitly scope 
terminated, and that they need to assume an implicit scope terminator pronto, 
to leave open the possibility that the encountered ON SIZE ERROR clause glues 
outward not inward. But they don't glue it yet.

If you write what looks like a conditional statement in a conditional 
statement they will try to find its explicit scope terminator. If that is not 
found then the _inner_ arithmetic (or I/O) is 'implicitly' terminated, which 
glues the ON SIZE clause to the _outer_ statement.

That is not right associativity deployed at the encounter point for the ON 
SIZE ERROR clause, because it might well need to be glued to the _inner_ 
arithmetic (I/O) should an appropriate explicit scope terminator be found.

Your comments to the effect that the significant vendor may or may not move 
away from certain genre patterns in the future is valued. Yet the most 
significant decision by the most important individual at the most import 
vendor does not change the code base.  It is the code base. That is what this 
project is about. We are committed to those who possess the code base or we 
are not.

This discussion is very useful in that it highlights the fact that as this 
language has evolved, the compiler writer is faced with two very different 
challenges. The first is parsing the sequence of tokens and symbols in 
phrases and clauses. The second is managing the locus of the clauses in the 
higher level constructs.

I believe the available tools fit the first task well, capturing valid and 
invalid token and symbol sequences. The available tools do not fit well the 
task of hemming the parts together and remaining robust when source code 
presentments do not meet expectations.

I regret that my phrasing seems to depict unreal issues.  It is a fact that I 
wish you success. Subjective though it is, the major problems with the tools, 
IMHO, for all laguages, is the nieve hierarchy issue. Sorry that that seems 
theoretical. Sorry my terms seem dreamy. Sorry that I am verbose. That is an 
occupational hazard of a COBOLer, I suppose. 

We want code, we want code, we want code. Give us code.

We _need_ design.

Sorry.

Big Blue's concept, and others can say if it is off track by the standards 
definitiions, is that their are three statement 'categories' (I believe that 
is their term, but geeks don't know nothin' about no 'categories'). I refer 
to that as statement _type_. For me, theorist or misguided poster wandering 
the net aimlessly, statement type and data element type are fairly easily 
seen as relevant to syntax validation.

Anyway the bad ol' boys there think of imperative statements, conditional 
statements and scope-delimited statements.  They point out that all 
conditional statements can be scope delimited. They maneuver their terrible 
explanantions to leave us with the impression that scope terminated 
statements, though they might could have been conditional, are not 
conditional at all, but are imperative. They make the further clarification, 
already clear to a compiler writers, that blocks of imperative statements are 
imperative statements.  By that stage the English words 'imperative 
statement' have repeatedly morphed.  I did not do that.

All of this is _type_, statement _type_.

The interpretation I am offering seems much less dramatic when you consider 
that a simple arithmetic is naturally an imperative. And when a programmer 
codes a simple arithmetic, that is what they mean.  In the following there 
are two simple imperative ADD statements

  MULTIPLY meg BY mega GIVING giga
    ON SIZE ERROR
         ADD 1 to count-errors
     NOT ON SIZE ERROR
         ADD 1 to success-count
   .


The standard has the word "...next...", if while processing the inner 
arithmetic we have not yet scene its _first_ ON SIZE ERROR clause, how can 
the first one ever be the "...next..." one for the inner arithmetic? 

The issue here is the owners of the code base and their relations with the 
good folk in the labor force. That issue is supremely huge.

The standard also has the word "...such...", which I believe allows the 
interpretation suggested here, but leaves us with _no_ definition of what to 
do when the prior statements already have '"..such...", as in when the NOT is 
removed

MULTIPLY meg BY mega GIVING giga
    ON SIZE ERROR
         ADD 1 to count-errors
     ON SIZE ERROR
         ADD 1 to success-count
   .


All would agree we have an error. Some would attempt then to glue the second 
ON SIZE ERROR to the inner atithmetic, But if you try to justify that by the 
word "...such..." meaning that the outer arithmetic already has such a 
(positive logic) ON SIZE ERROR clause, you will write a compiler that is 
_M_U_C_H_ more complex than what I advocate.

So the homeless ON SIZE ERROR clause can not glue to the inner arithmetic as 
"... next..." and we are not warranted in attaching any conditional clauses 
to it because it is an unterminated arithmetic statement. So it drifts 
through the cracks. My idea is don't let it drift off. Glue it to the outer 
arithmetic, and if the outer arithmetic already has "...such..." then flag it 
as duplicate.

That is no more difficult then being able to wave the flag for these.

   ADD... 
     ON SIZE ERROR 
        DISPLAY "Happy sailor"
     NOT ON SIZE ERROR 
        DISPLAY "Happy sailor 2"
     ON SIZE ERROR 
        DISPLAY "Flag this"
     ON SIZE ERROR 
        DISPLAY "Flag this b"
     NOT ON SIZE ERROR 
        DISPLAY "Flag this c"
     ON SIZE ERROR 
        DISPLAY "Flag this d"
     NOT ON SIZE ERROR 
        DISPLAY "Flag this e"
     NOT ON SIZE ERROR 
        DISPLAY "Flag this and stay on your feet the whole way"
END-ADD.

Deeper in this question is something we are probably not ready for. And that 
is the "...such..." word can create an ambiguity (simple English meaning) for 
us if we get three deep. As in 

ADD 1 to maybe-mine
  ON SIZE ERROR
     ADD 2 to no-its-mine
        ON SIZE ERROR
            ADD 3 to oh-yeah
                NOT ON SIZE ERROR
                   DISPLAY "glue me carefully"
 .

Now in the midst of all that unterminated stuff, at the encounter point of 
the NOT ON SIZE ERROR, which previous ADD does not have "...such..." a NOT ON 
SIZE ERROR clause: is it ADD 2 or ADD 3?

I am convinced that if you start merely from the notion that the inner 
arithmeitcs are not allowed to have conditionals, then you will try to flag 
them in there. Which is not COBOL. If an inner arithmetic is not allowed to 
have a conditional then we the compiler writers are not allowed to assume 
that the conditional encountered is intended as part of the inner arithmetic. 
Look at it from the labor force point of view.

When we do encounter an appropriate END-arith, then we have a scope-delimited 
type of statement within which we are permitted to have oodles of 
conditionals.  This is lookahead not associativity.

Stated differently, since it is illegal to have inner conditional statements, 
we are not warranted in assuming either of the undelimited inner statements 
are meant as conditionals. We must start with the assumption they are simple 
imperatives until lookahead proves otherwise. That assumption is described by 
one vendor as an implicit scope terminator between the (simplistic) 
arithmetic statement and the ON SIZE ERROR clause encountered.

You see you most give the programmer the benefit of the doubt.  "If you can 
not have inner conditional statements, why would the compiler writer assume I 
meant an inner conditional statement, they should assume I meant a simple 
imperative, until they do their lookahead."

Hen you encounter the inner ON SIZE ERROR clauses, you basically can make no 
commitment, you must continue scanning.

In the following example we agree, I think, that there is an error. But for 
different reasons.

ADD 1 to xyz
   ON  SIZE ERROR
      ADD 2 to qrs
        ON SIZE ERROR
            SUBTRACT 3 from lmn
 .

The following code causes different interpretations for us

ADD 1 to xyz
   ON  SIZE ERROR
      ADD 2 to qrs
        NOT ON SIZE ERROR
            SUBTRACT 3 from lmn
 .

I have indented it the way I understand you would understand it. You will try 
to glue the NOT ON SIZE ERROR to the inner ADD 2. In the absence of explicit 
scope terminator it is naturally a conditional, which you then conclude is 
illegal as a conditional statement on a conditional clause.

The exact same code, indented differently, reflecting my interpretation ...

ADD 1 to xyz
   ON  SIZE ERROR
      ADD 2 to qrs
   NOT ON SIZE ERROR
      SUBTRACT 3 from lmn
 .

Since simple arithmetics are imperative, and imperatives are legal on 
conditional clauses, and we assume the coder codes legal statements.  I 
assume that the coder means a simple statement until proven otherwise (by 
lookahead). Not finding anything up ahead within ten thousand costly miles, I 
do infact hold my assumption that the ADD 2 is simple. It is therefore 
imperative, and legit.  The NOT ON SIZE ERROR glues smoothly to the outer 
arithmetic statement. Piece of cake.

This goes back to what I was saying before. If production code is moved to 
the compiler you have in mind it would commence to behave differently.  
Whatever our coding techniques we can not have different semantics.

We can not wish that they would put explicit scope teminators everywhere. 
They haven't. They won't. The only way we know is to lookahead.

I think that the LL (left-hand reducing) tools tend to entice tool users into 
planning their strategies around an early reduction paradigm that 
incidentally leads to early actions. That actually is not a necessary 
concommittant. But it seems to happen.

We need to keep things in abayence until we encounter scope delimiters, or 
some distinguished token (like ELSE or a verb) that affirms that absence of 
the explicit scope terminator. That is not easy.  Generally right 
associativity breaks things. We may not be able to do that, in the case at 
hand various numerous ON SIZE ERROR clauses can be concurrent.

When the containing arithmetic is explicitly scope delimited, the ON SIZE 
ERROR clauses permit the aritmetic statements to possess tail recursive 
topology. When such forms are not explicitly delimited they are permitted to 
only have a bumper to bumper interative surface. We do not know that 
unfortunately when we encounter the thing which is either the front bumper of 
the next dive of the tail recursion. We only know it later due to the 
presence or absence of the teminator token prior to a distinguished token. 
That cannot be handled with mere associativity. Into that bag of intrigue 
toss the lack of ordinality to the alternate conditionals.

It is kind of like saying in addition to being strange we now will say [THEN] 
and ELSE clauses could be reversed in order. Hey, maybe someday. 

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.