Re: gnubol: IBM flags nested conditionals as error (RC=8) but recovers OK

[RKRayhawk@aol.com]

In a message dated 12/6/99 9:38:33 AM EST, mck@tivoli.mv.com writes:

<< 
 Adopting this policy on certain conditional statements does not
 commit us to match all of IBM's error recovery.  
 
  >>
That is valid. And the policy of binding inward is easy enough that we can be 
somewhat consistent still, allowing a number of distinct categories of 
alternating conditionals to be 'extensions'.  But I fear this is a Pandora's 
box.

((IN all of the following comments when I refer to nested conditionals, I 
mean utterly unterminated nests)).

In the first place doing it at level two leads you right into level n. At 
level three it begins to make less sense.  When contemplating the semantics 
it is _possible_ that this looks a lot different when you nest distinct 
conditionals inside of each other, and begin to consider allowing the run-on 
conditionals depth three and more. When you glue a number of those together, 
one wonders what the semantics is even supposed to be doing. What does that 
kind of code mean?

The thing is we could punt and just say if they code it we gen it. But 
practically what does level three nesting mean? Why do we have an exception 
in an exception in an exception? Ad infinitum?  So you end up with the 
nagging feeling that after we have worked all this out, and find a way to 
break into open field and go for pay dirt, practically, we now probably want 
strange rules to start chopping on draggons when they have three or more or 
maybe four or more unterminated conditional in a row (same family 
conditionals). Because it begins to depict a less reasonable semantic 
circumstance.

We do have in all of this the very unlikable fact that actually a sequence of 
NOT-error-conditionals is much more likely to be meaningful than a sequence 
of error-conditionals.
And though that is entertaininly true of ADD...ADD...ADD..., it is actually 
the thing that makes nesting distinct conditionals relevant to considerable 
depth., Like EVAL...SEARCH...ADD.


My point about the Pandora's box is that I am certain distinct conditionals 
will have to nest ad infinitum, although I do not yet see agreement on that 
in the discussions. And allowing the related conditionals to nest with an 
'extended' bind inward is going to produce things like
    
EVAL...SEARCH...ADD....ADD...ADD...

which involves code that has very difficult semantics.  In the sense that it 
is difficult to see that the coder knows what that means in a way that will 
map to our assumed interpretation.

All of these expressions here are intended to represent open conditionals. 
Keep in mind that this Pandora's box has two openings. so after the ADDs put 
in all the combinations of ON SIZE ERROR and NOT ON SIZE ERROR you want. 
Leave them all open, unterminated. Can you possibly know what that means with 
confidence.

One poster has indicated that the future standard will allow transposition of 
the conditional clauses. This is my 'not ordinal' concept.  In that milieu, 
in the present or later release of our compiler can we possibly be confident 
that we know what the coder means when they are three or more levels deep on 
open related conditionals (unterminated).

My original posting on this (about which I was wrong) was an expression of 
concern that we might have difference of semantics, if the inner conditional 
clause bound back to the inner or outer verb.  A code base that has only bind 
inward, contrasting with error rejection is less of a problem (though it's 
important). But all of that was really just a two level deep situation.

Copying the Micro Focus extension looks like trouble to me. This situation 
may be more difficult for LL tools. Those tools, I am thinking, are in a 
hurry to bind because they are in a hurry to reduce. I am not against PCCTS. 
I am not against LL. But we should not go for the extension because it keeps 
LL afloat in our decision making.

But more important I seriously question the appropriateness of binding inward 
at level three and more. When the region of code has combinations of positive 
and negative alternates, all open, unterminated, then any assumption becomes 
less reasonable as far as the professional obligation that we must map 
semantics to assayed human intentions. Level three bigins to feel less 
comforable, but level four, ... ? 

I do not think that we have a concensus to commit to allowing a swapped 
sequence on the conditional clauses. We do have indications that the future 
will require that, so we atleast _may_ need to make room for it. Binding 
inward as an extension I think makes it much more difficult to set out rules 
that allow either sequence of conditional clauses (even if that were to 
happen in later releases, and not right away).

Binding inward is an escape hatch. It resolves s/r and r/r conflicts. Or 
stated conversely designing to bind inward allows us to code grammar rules 
that continue to hide the s/r and r/r conflicts from us.  I don;t mean to be 
bad, just analytical :-)

But binding inward is a trap. I think at level two, and certainly at level 
three, we are going to have trouble finding the outer statements alternate 
conditional clause. If transposition of clauses are acceptable, I think we 
can never find the outer statements alternate clause.  Instead everything is 
going to have a tendency to bind inward, looking like repetitions way inside, 
or flying out as exretia to rules _enclosing_ the outer conditional rule.

We can not be in a hurry to reduce. We will need pervasive concurrency of 
rule scope. And numerous rules are bifurcate. Internal reductions will tend 
to eat the outer statements second clause or esee it as duplicate to the 
interior.

The levels of difficulty we have here, are 1) probably either LL or LR can 
bind inward if the conditional clauses were merely monotonic 2) we may find 
ourselves in some difficulty with LL because of the _optional_ bifurcate 
topology of the conditional statements, and 3) if we code for or allow for 
transposition of the alternate clauses LL will need heroics to bind 
successfully inward and still find outer rules's alternate clauses at depth 
three and more.

However, please take the entirety of that as IMHO. There is a chance the 
practitioners of LL tools can discipline the actions so that they do not give 
precocious bind signals in the emisions to semantics.  The enemy here is 
actually early reduction. LL tools tend to encourage that, but it is not 
really necessary.  A person can write long rules for example. But we have a 
need to variably embed rules in rules, there's no hope of rules long enough. 
So it seems like LL actions are going to commit at a time when we don't know 
the antecedent. The need to braid is quite real. Because of my ignorance of 
PCCTS I still see it as being in trouble on a three or four layer completely 
terminated fully populated nested arithmetic conditionals structure!  
Especially if we allow transposition! The explanation points marking my need 
for education :-). But that is all just technical stuff.

The semantics are a different matter, I think that deep open conditionals are 
questionable in terms of the faith that we or others could have that our 
semantics are mapping to a coder's cognition. At level two there is not so 
much of a problem. But with various combinations and permutations level three 
and beyond is less credulous.

Much of this is mitigated by the infrequency of occurence of the code. But I 
do not think that we should allow the exception just to keep LL on the table. 
 The lack of a stack in LL does not condemn it, but a tendency towards early 
reduction and precocious action binds of conditional clauses is an issue 
here. I am  not being negative, I hope. I genuinely believe that the advanced 
features of PCCTS hide s/r and r/r conflicts from us. A policy decision to 
accept inward binds I think hides conflicts (I do not assert that k=1 LRs can 
deal with it; I don't know yet). Because the discussions are talking about 
strapping PCCTS to k=1, then inevitably it is taking some default course in 
r/r conflicts. Binding inward on conditionals eases the pain but does not 
treat the cause of the problem. We need concurrent scopes, not merely 
associativity.

No doubt executables of the minimum grammars are just around the corner, 
which speaks volumes about the contribution and personal sacrafice of those 
working on the grammars. We are definitely grateful to each of you for that 
hard work.

Bob Rayhawk

--
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.