| Cobol is intended to be self documenting. The text should read as a book. The language is built from sections, than paragraphs, than sentences and finally statements; imperatives and conditionals. Even the level structures in the data division are statements; the ancient representative of a bulleted power-point presentation making statements. Nowadays we have a different understanding what a statement is or should be, and we feel the need for defining "scope". We are keen on mixing contemporary syntax habits with concepts of half a century ago to make a point.
Well, writing sentences does not implicate the use of "statement terminators"; essentially we are humans and while reading a book, we can do without such terminators. Though I have a book (from Laurent Mauvignier) that consists of just one sentence. It is difficult to read, indeed. And some user manuals written in "6th dregree" English: sentences of max 10 words. Delightful and unambiguous.
My opinion is that Cobol does not define statement terminators but did define a sentence terminator, the period, and a generic separator, the comma. The period is in fact what a sentence is all about: a piece of text. My favorite is to talk about Cobol Text, as opposed to Cobol Sources (or source code). If we do not underpin this attitude, and like the term "source Code" more, than Cobol needs much more abbreviations (compare sms habits), can do without figurative constants, would ask for creative writing like camel casing or writing backward, and gets introduced to a firm load of syntactic sugar that can set us apart by using it. That only makes me wonder, if it knows I forgot it, why does it need it at all!
Well, I happen to use a socalled word processor, that has integrated spelling aids. It warns me that I've made a mistake in spelling. Nevertheless I can store that file, and can even send it by email. Readers of such text would classify me as uneducated when I leave these typo's in, some even speak of rudeness. Nonetheless some of them understood the message, some misinterpreted my writings. My point is that interpretation of text comes with a syntax, and some interpreters are smart, and some are not. The smart ones issue a warning, the dumb just compile wrongly.
Wim
Op 25 sep. 2013, om 08:18 heeft Frank Swarbrick het volgende geschreven:
This is one of my obsessions, so I am very happy to discuss and give my opinion.
First, a period is a SCOPE terminator, not a STATEMENT terminator. Let's give an example before I go on.
MAINLINE.
DISPLAY 'BEGIN PROGRAM'.
OPEN INPUT MY-FILE.
READ MY-FILE INTO MY-RECORD
AT END
DISPLAY 'FILE IS EMPTY!'
STOP RUN.
IF MY-RECORD IS EQUAL TO 'THIS IS A TEST'
DISPLAY 'TESTING SOMETHING'
PERFORM DO-A-TEST
ELSE
DISPLAY 'DOING DEFAULT PROCESSING'
PERFORM DO-DEFAULT.
DISPLAY 'ONE RECORD PROCESSED, AND NOW WE'RE DONE'.
STOP RUN.
This example will compile with any compiler from (at least) COBOL 74 on (and perhaps earlier, but I have no experience with the earlier standards).
Note that there MUST NOT be a period after the DISPLAY statement inside the 'AT END' clause, BOTH statements between the IF and ELSE, and the FIRST statement inside the ELSE. This is because any period inside a "conditional clause" terminates the scope of that clause. If we did place those periods we'd get something that would act essentially like this:
PROGRAM-ID. MYPROGRAM.
[...]
PROCEDURE DIVISION.
MAINLINE.
DISPLAY 'BEGIN PROGRAM'.
OPEN INPUT MY-FILE.
READ MY-FILE INTO MY-RECORD
AT END
DISPLAY 'FILE IS EMPTY!'.
STOP RUN.
IF MY-RECORD IS EQUAL TO 'THIS IS A TEST'
DISPLAY 'TESTING SOMETHING'.
PERFORM DO-A-TEST.
ELSE
DISPLAY 'DOING DEFAULT PROCESSING'.
PERFORM DO-DEFAULT.
DISPLAY 'ONE RECORD PROCESSED, AND NOW WE'RE DONE'.
STOP RUN.
If not the for the 'dangling ELSE' that program would actually compile, but it definitely not do what was intended. :-)
But it does demonstrate what I mean when I say that a period is a SCOPE terminator rather than a STATEMENT terminator. As has been noted, a STATEMENT is terminated implicitly when a reserved word VERB is reached (starting a new statement).
So the fact of the matter is that, with COBOL 85 and beyond, the only "scope" that does not have an optional terminator that can be used in place of the period is the PARAGRAPH/SECTION. And that is in fact the only time (when writing new programs!) that I use the period as a scope terminator within the procedure division. In my perfect world we'd have an END <paragraph> and thus eliminate the need for the period-as-scope-terminator anywhere within the procedure division.
PROGRAM-ID. MYPROGRAM.
[...]
PROCEDURE DIVISION.
MAINLINE.
DISPLAY 'BEGIN PROGRAM'
OPEN INPUT MY-FILE
READ MY-FILE INTO MY-RECORD
AT END
DISPLAY 'FILE IS EMPTY!'
STOP RUN
END-READ
IF MY-RECORD IS EQUAL TO 'THIS IS A TEST'
DISPLAY 'TESTING SOMETHING'
PERFORM DO-A-TEST
ELSE
DISPLAY 'DOING DEFAULT PROCESSING'
PERFORM DO-DEFAULT
END-IF
DISPLAY 'ONE RECORD PROCESSED, AND NOW WE'RE DONE'
STOP RUN
END *> this terminates the scope of paragraph MAINLINE
END PROGRAM MYPROGRAM.
Hmm, I guess I do still have periods to terminate the 'non-statement' lines such as the procedure division header, the paragraph name and the END PROGRAM marker. Not sure if it would be worth getting rid of those.
Among others probably, the following are reason to use the period scope terminator as little a possible within the procedure division:
1) When "unconditional logic" is changed to become conditional most of the periods present at the end of those statements MUST BE REMOVED. This is often forgotten, and if your conditional logic does not include an ELSE the program will often even compile with the periods erroneously left in place.
2) Contrary to what the designers of COBOL seemed to believe, people cannot (unambiguously, anyway) "program using complete sentences. I mean, is this really a sentence? "IF MY-RECORD IS EQUAL TO 'THIS IS A TEST' DISPLAY 'TESTING SOMETHING' PERFORM DO-A-TEST ELSE DISPLAY 'DOING DEFAULT PROCESSING' PERFORM DO-DEFAULT." No, it is not. So why pretend that COBOL uses English sentences when in fact it does not.
3) I always forget the periods anyway! Since I don't use them except when necessary that doesn't matter much in the procedure division, but it does in the others. And the funny thing is, the compiler usually recognises when I do forget. Take the following example:
01 MY-GROUP
05 MY-FIELD-1 PIC X.
05 MY-FIELD-2 PIC 9(9) COMP
05 MY-FIELD-3 POINTER.
I'm not going to take the time to compile a program with the above, but if am not mistaken Enterprise COBOL will warn me that I forgot a period BEFORE the first and third 05 level fields. That only makes me wonder, if it knows I forgot it, why does it need it at all! But I think for non-PD sections it is much less straight-forward than it would be to eliminate them in the PD.
And finally, we could start entering COBOL programs into the "obfuscated programs" contents!
PROCEDURE DIVISION. MAINLINE. DISPLAY 'BEGIN PROGRAM' OPEN INPUT MY-FILE READ MY-FILE INTO MY-RECORD AT END DISPLAY 'FILE IS EMPTY!' STOP RUN END-READ IF MY-RECORD IS EQUAL TO 'THIS IS A TEST' DISPLAY 'TESTING SOMETHING' PERFORM DO-A-TEST ELSE DISPLAY 'DOING DEFAULT PROCESSING' PERFORM DO-DEFAULT END-IF DISPLAY 'ONE RECORD PROCESSED, AND NOW WE'RE DONE' STOP RUN END END PROGRAM MYPROGRAM.
Frank
On 9/24/2013 1:43 PM, Patrick wrote:
Hi Mike
Thanks once again for your helpful feedback.
I am not sure if I have any real proposals here for open Cobol
but if we could continue the discussion without a fight breaking
out, something valuable might come out of this.
I am a recent learner and the periods VS END-verb was very
confusing for me.
At 37 I guess I am a "young" coder and I don't mind the END-verb
at all. I would also have been happy with periods too but I am
not happy with implicit statement ends, this reminds me of
_javascript_ with optional semi-colons.
If everything was just periods or END-verbs it would be so much
easier to learn. Furthermore some verbs do not have an END-verb
option such as MOVE.
Does anyone know of anywhere I could read about the discussions
that might have taken place about this?
It seems to me that having 3 different ways to end statements
was a way to keep everyone happy and that thousands would be
furious if their style was omitted.
Again I don't really have a suggestion that would not upset
others but maybe if I understand the problem I can figure out
some little work around or at least give tips to others in a
tutorial-Patrick
On 09/24/2013 01:21 PM, Michael Anderson wrote:
Patrick,
In the past a period was always required to terminate a
statement. It was the onset of the END- verb that made the
period completely optional, except at the end of a division,
or paragraph. There has been discussions between many
cobologists to remove the period completely. However, points
you mention, as well as others, make this impossible. However,
a negative consensus of Cobol (by non-Coboler's) has been that
it is too verbose, too wordy. In my opinion the END- verbs add
to this wordiness, and is perceived negatively by young new
programmers learning the language, a single character is much
more preferable.
There is a difference between reserved words and verbs in
Cobol. For example STRING is a verb, and a reserved word,
but INTO is not a verb, but is a reserved word. I think
you're correct in that it is the next known verb that
terminates a statement without a period.
I would agree that this END-verb verses using a period does
probably add to the complexity of the parser, but this also
adds to the complexity of learning the language. For example;
some programmers use END-verbs all the time, others are not as
consistent. Also the compiler will warn of missing END- verbs,
but they're only useful to me when coding within the context
of upper level verb. So, what is the deal?
Too me, this feature is useful for readability.
I don't use END- verbs all the time, but when I do, I prefer
it to be only within the context of another verb. For example:
If, Evaluate, in-line Perform's and so on..... When NOT in
the context of another verb I always use the period, and never
the END-verb. I'm definitely not trying to push my coding
style on anyone else. However, this makes my code better for
me, more readable for me. Especially when looking at large
junks of code with END- verbs lets me know I'm working within
the context of a higher level verb. Where periods are used in
my code, I know without a doubt, that I am working at the
outer most context of verbiage. As this madness may upset some
traditional programmers, I give much thanks to the compiler
guys for supporting this feature. I also prefer FREE FORMAT
without column constraints, which also increases the
blood-pressure of traditional programmers.
I also prefer to work well with others, so when asked, I have
no problem replacing all my periods with END- verbs, but for
me this does take-away from the readability and adds to the
wordiness.
--
Mike.
On 09/24/2013 10:07 AM, Patrick wrote:
Hi Everyone
It's easy to see how Cobol can be parsed in all of the parts outside of
the PROCEDURE DIVISION, statements end with periods.
I can't see how the compiler could understand what is going on in
PROCEDURE though. Every language I know of has some sort of character to
end a statement. It might be a non printable character but it's there.
PROCEDURE ends in a period and paragraphs end in periods but if we have
a statement like this:
MOVE foo TO moo
I could see how the compiler would implicitly know that it ends one
token after TO but we can also have:
MOVE foo TO moo koo boo
Does the next reserved word that is not a part of the current sentence
signify an end to the current statement and the final period indicate
that there are no further statements coming ?
If this is true, was it always this way. From what I understand it was not.
If this is true did it dramatically increase the complexity of the compiler?
Thanks
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
|