Hi, it's me.
My general thoughts are: - This type of syntax is supported in a host of other programming languages. (see below for examples) - Is it really confusing? For me its more confusing doing all the things that I've done up to this point because COBOL (prior to the 2002 standard) did not allow me to do what I really wanted. - I also think the elimination of procedure division SECTIONS and the "performing" of multiple paragraphs (PERFORM...THRU) by using these new features can be quite a benefit, rather than an issue. Now will some people use/misuse these constructs within the context of sections and PERFORM THRU. Certainly. But any programming language syntax can be misused. That doesn't mean they should be eliminated (well, except for the ALTER statement, perhaps!). - In the end, to me these new language features *enhance* structured programming. https://www.rosettacode.org/wiki/Loops/Break break: C and its followers (C++, Java, C#), Delphi, JavaScript, Ruby, Python leave: PL/I and REXX last: Perl exit: Ada EXIT PERFORM: COBOL https://www.rosettacode.org/wiki/Loops/Continue continue: C and its followers (C++, Java, C#), Delphi, JavaScript, Python iterate: PL/I and REXX next: Perl, Ruby [not supported]: Ada EXIT PERFORM CYCLE: COBOL I can't find a Rosetta Code page for early exit/return from a procedure/function, but I believe the following are true: return: C and its followers (C++, Java, C#), Delphi, JavaScript, Ruby, Python, PL/I, Rexx, Perl EXIT PARAGRAPH / EXIT SECTION: COBOL Should COBOL have added new keywords instead of co-opting/enhancing EXIT? I don't think so. Really, EXIT as COBOL defines it should never have existed. If they wanted a word to represent the end of a procedure they should have used the work END! (And they did in the 85 standard support END PROGRAM, so why not END PARAGRAPH (too wordy, but...) and END SECTION. Oh well!) One of my favorite examples of the use of EXIT PERFORM is the "elimination" of "priming reads". It's bugged me for 20 years (my COBOL lifetime). To me, the following is ideal PERFORM UNTIL EXIT *> Not currently part of the COBOL standard!!! :-( READ MY-FILE INTO MY-RECORD AT END EXIT PERFORM NOT AT END PERFORM PROCESS-MY-RECORD END-READ END-PERFORM Here you have a read/process loop until such time as the read "fails", whereupon you exit/terminate the loop. Unfortunately "PERFORM UNTIL EXIT" is not part of the COBOL standard (though it is supported as an extension by some implementations), so you have to come up with a dummy field that will "never be true" (in which case the compiler can optimize away the check), or your code can "check it twice" (once after the read and once at the top of the loop), which is redundant. Those are my thoughts for now. I have plenty more if anyone is interested. :-) Frank ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Bill Woodger <[email protected]> Sent: Tuesday, July 12, 2016 1:00 PM To: [email protected] Subject: Considering Enterprise COBOL 5.2 "exit" enhancements Recently, Frank Swarbrick and I have been discussing this down at the COBOL Cafe (how cool does that sound when you say it out loud?). The nub of the topic is the new Formats of the EXIT statement which have been introduced to Enterprise COBOL with V5.2. These are EXIT PERFORM, EXIT PERFORM CYCLE, EXIT PARAGRAPH and EXIT SECTION. These were introduced to the COBOL Standard in 2002, now superseded by COBOL 2014. On discovering these a few years ago, my first question was "why even more overloading of EXIT?". EXIT, the original and without qualification, is a NOP. All the other Formats of EXIT "do things". Answer from someone in the know was "so we don't break existing code by picking a new word". To me that is a slack reason, as we were always told "never use a single word for a name, because one day they may want to use it for the compiler". If the unthinking had been bitten, I don't really care. OK, some big companies may... can't fight City Hall. That aside, what do these new Formats of EXIT do? In reverse order: EXIT SECTION, if executed, branches to an implied CONTINUE (also a NOP) after the code generated for the last source statement (which generates code) in the SECTION. You don't have to be PERFORMing the SECTION at the time of execution. EXIT PARAGRAPH, if executed, branches to an implied CONTINUE after the code generated for the last source statement (which generates code) in the paragraph. You don't have to be PERFORMing the paragraph at the time of execution. EXIT PERFORM CYCLE, branches to a the point (could be another implied CONTINUE, but, seriously, since it is a NOP, there is no code (not even an Assembler NOP) in an inline PERFORM which starts the next iteration. EXIT PERFORM, branches to after the inline PERFORM (got tired of even pasting). My concerns are: they are secret GO TOs - NEXT SENTENCE is bad enough, do we need more?; they are not intuitive - EXIT PERFORM and its cousin clearly operate within a PERFORM (although not so clear that it is only within an inline PERFORM), EXIT PARAGRAPH and EXIT SECTION don't care whether or not a PERFORM is active, they're just going to GO TO where they want, which isn't always clear (no label); because they seem a bit "structured" someone can use them for "spaghetti" and still claim to be writing "structured code, I never use GO TO". An example: PERFORM A THRU C A. ... IF some-condition EXIT PARAGRAPH END-IF ... B. ... C. EXIT *> old-style, NOP Where does the EXIT PARAGRAPH "go to"? A point immediately before B. Is that the desired and intended result? What happens if you want to insert another paragraph between A and B (I wasn't very foresightful with my naming)? An EXIT SECTION seems less problematic, but bear in mind that nothing stops you having EXIT PARAGRAPH in a SECTION (perhaps Frank can confirm if it works even without a paragraph name in the SECTION?). And whether the SECTION is fallen-into, or GO TO'd, or PERFORMed, EXIT SECTION does the same thing, perhaps not what people imagine. Same with EXIT PARAGRAPH, if you just pretend I mentioned it back there. On the one hand the above is "good", as it finally indicates that PERFORM ... THRU ... is for the birds. At least with the PERFORM of a single paragraph, there is no confusion about where EXIT PARAGRAPH "go tos". On the other hand, all existing GO TOs in a program could be eliminated by adding using EXIT PARAGRAPH, if the GO TO is going "downwards" and not going more than one paragraph away. The program is still as "bad" as before, but now has nice shiny instructions to be equally bad with. I don't use GO TOs, unless the client insists, and unless they are needed for extreme performance (with severe reduction in program-legibility), which fortunately is not often needed. I don't have a problem with people using GO TOs in sensible ways, which very many experienced programmers do. I do have a problem with the introduction of an ill-defined secret GO TO disguised as a "structured" thing which I fear will be abused (as in used incorrectly) if for no other reason than a lack of knowledge of what it does, let alone the "one more hack and the program'll be working" school of classroom-/self-taught programming. I think we can wait for Frank to contribute a piece and then... Discuss... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
