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

["William M. Klein" <wmklein@ix.netcom.com>]

Question:
 Am I missing something or has consensus been reached that allowing nested
conditionals where the Standard requires imperatives (as "valid") has been
rejected and that the consensus is now that these should cause an error?

If so, is the ongoing discussion JUST asking where to "bind" the erroneous
"open conditionals" - in order to allow continued compilation?  If there is
some other OPEN question, can someone tell me what it is?

If this is the only open question, then I would PREFER that the "bind" be to
the inner statement (consistent with the explicit rules in the draft - and
what Micro Focus does as an extension - and what IBM does with their "error"
condition).  On the other hand, I don't care a WHOLE lot about what we do
with "errors" - other than NOT produce executable code.

Am I still missing something?

Bill Klein
  wmklein <at> ix.netcom.com

> -----Original Message-----
> From: owner-gnu-cobol@wallace.lusars.net
> [mailto:owner-gnu-cobol@wallace.lusars.net]On Behalf Of
> RKRayhawk@aol.com
> Sent: Monday, December 06, 1999 12:14 PM
> To: gnu-cobol@lusars.net
> Subject: Re: gnubol: IBM flags nested conditionals as error (RC=8) but
> recovers OK
>
>
> 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.


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