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

[RKRayhawk@aol.com]

In a message dated 12/6/99 1:49:29 PM EST, wmklein@ix.netcom.com writes:

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

I think that is open. We seem to be together on binding inward (I was the 
only one who got out on a bind out concept, and I didn't so much want it as I 
was concerned it represented alternative behavior in the field). I think now 
everyone says bind in. But there is not yet consensus on whether the internal 
as a conditional will be allowed as extension or rejected.
We evidently do have a code base issue here, so it is not just preference.

I am all for keeping it open for a while, though I lean against the extension 
because it opens 
the door to the three and more deep conditionals of like family, which I 
think are not reasonable. I feel that we can keep it open until we begin to 
experiment with the preliminary 
grammars, to discern the deeper issues of heterogeneous conditional nesting. 
I would like to support those who want either alternative while we weigh the 
implications of the code base and size up the challenges in the parsers.

I do not think we have consensus that the inner conditionals should be errors 
in our compiler.

The code base may motivate us to even consider parametric controlled 
alternative behavior, which is a kind of worse than we want option. I draw 
that out because we are dealing with convergence, not merely product 
perfection to some standard.

But really, if we are to code now for or make room for transposing the 
alternate conditionals, I think this extension dies.  Stated differently, for 
products like Micro Focus, and now it appears others, they can not make it to 
transposition from where they are in their 'extended' position.

All IMHO. 

But I am fairly convinced the consensus is not there yet on preferences 
concerning the 
extension/reject decision. I am all for keeping it open. 

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.