Home > Archive > Cobol > May 2005 > Where are spaces required in COBOL source code?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Where are spaces required in COBOL source code?
|
|
| epc8@juno.com 2005-05-27, 3:55 am |
| While playing around with the COBOL12 compiler (discussed elsewhere
recently in this newsgroup), I ran into a few peculiarities. This is a
DOS compiler that looks like a subset of 74 standard COBOL but has some
extensions and some omissions. Its display is unusual since it uses a
graphics mode to display text. Anyway I noticed two strange things. The
compiler does not accept blank lines in source code and it requires a
variable name to be separated by at least one space from the
parentheses enclosing a subscript (or an expression denoting reference
modification). An old CP/M era compiler also had this requirement for
subscripts (of course there was no reference modification).
1. Was this ever part of a COBOL standard?
2. I sometimes find it puzzling that spaces seem to be required around
certain things in COBOL when I don't expect them to be. For example
after commas (in CALL), around the colon in reference modification (at
least in the compilers I've tested) and around operators in a COMPUTE
expression.
Please note that the first language I learned was FORTRAN using
fixed-form (punched card) format. There spaces are only meaningful
inside string literals.
Is there a general rule about this for COBOL and has it changed with
different versions of the standard?
(Sorry if this is a FAQ.)
| |
| Chuck Stevens 2005-05-27, 3:55 pm |
|
<epc8@juno.com> wrote in message
news:1117154259.996313.163080@z14g2000cwz.googlegroups.com...
> The
> compiler ... requires a
> variable name to be separated by at least one space from the
> parentheses enclosing a subscript (or an expression denoting reference
> modification). ...
> 1. Was this ever part of a COBOL standard?
The concept of "separator" as a syntactic element seems to have been
introduced in the '74 standard, and in that standard, a space is allowed but
not required before a left parenthesis. Before the introduction of the term
"separator", it's a bit tough to tell for sure.
I see some indication that a space was required by COBOL-60 and by the '68
standard between the data-name and the leading left paren. I also see some
evidence that the '68 standard prohibited a space between the leading left
paren and the first subscript, and between the last subscript and the
trailing paren.
The basic rules for '85 COBOL dictating where spaces are required are:
after separator periods, commas and semicolons; before an opening quotation
mark that isn't immediately preceded by a left paren; after a closing
quotation mark that isn't immediately followed by a close paren; and before
an opening pseudo-text delimiter.
-Chuck Stevens
> 2. I sometimes find it puzzling that spaces seem to be required around
> certain things in COBOL when I don't expect them to be.
It might be helpful to find out what the expectations are for COBOL by
examining the COBOL standard!
> For example
> after commas (in CALL),
A "separator comma" may appear anywhere a "separator space" may appear, but
a "separator comma" consists of a comma *followed by a space*. If you put a
comma there, expect to put a space after it. But so long as you have at
least one space between the arguments, the compiler should accept it.
> around the colon in reference modification (at
> least in the compilers I've tested)
I don't see any standard requirement that a ("separator") colon be either
preceded or followed by a space in reference modification, and our
implementation certainly doesn't require it. I'd suggest filing a trouble
report.
> and around operators in a COMPUTE
> expression.
Arithmetic operators (+, -, *, /, **) aren't listed among the "separators".
Syntactic elements of the language are separated by "separators".
Note that in COBOL
COMPUTE A = B-C.
means something entirely different from
COMPUTE A = B - C.
which is one of the underlying reasons *failing* to use separator spaces is
generally considered
in COBOL difference between "A-B" and "A - B" in COBOL, which is probably
one of the underlying reasons *failing* to use separator spaces is
considered Bad Form in COBOL. your compiler is complaining!
> Please note that the first language I learned was FORTRAN using
> fixed-form (punched card) format. There spaces are only meaningful
> inside string literals.
I don't know how to tell you this, but the rules for COBOL are not the rules
for ForTran, and the general expectation that the COBOL compiler will
accept ForTran source is not likely to be well-received by any COBOL
compiler!
> Is there a general rule about this for COBOL and has it changed with
> different versions of the standard?
The general stylistic rule for COBOL is that COBOL is based on English, in
which letters are combined into words that are separated by spaces and
punctuation marks. The punctuation rules are similar to those for English
as well, including the frequent requirement that certain punctuation marks
be followed by at least one space. Some specifics may have changed (the
relaxation of what may have been a rule that a left parenthesis of a pair
that encloses a subscript *must* be separated from the data name that's
being subscripted by a space), but a separator space where it is allowed is
rarely a Bad Idea in COBOL.
-Chuck Stevens
| |
| Howard Brazee 2005-05-27, 8:55 pm |
|
On 27-May-2005, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
> I see some indication that a space was required by COBOL-60 and by the '68
> standard between the data-name and the leading left paren. I also see some
> evidence that the '68 standard prohibited a space between the leading left
> paren and the first subscript, and between the last subscript and the
> trailing paren.
That seems to be what I remember. But it's sometimes hard to remember what was
a CoBOL rule, and what was a standards rule or a habit.
| |
| Chuck Stevens 2005-05-27, 8:55 pm |
| Let's try that again. Things got messed up in the editing, and perhaps I
was too abrupt.
<epc8@juno.com> wrote in message
news:1117154259.996313.163080@z14g2000cwz.googlegroups.com...
> The compiler ... requires a
> variable name to be separated by at least one space from the
> parentheses enclosing a subscript (or an expression denoting reference
> modification). ...
> 1. Was this ever part of a COBOL standard?
The basic concept stems from the historical fact that the rules for COBOL
are such that it is intended to be legible as English imperative sentences.
Spaces, in written English, are commonly used to separate words and
punctuation.
In the rules of the COBOL language, the concept of "separator" as a
syntactic element seems to have been
introduced in the '74 standard, and in that standard, a space is allowed but
not required before a left parenthesis. Before the introduction of the term
"separator", it's a bit tough to tell for sure.
I see some indication that a space was required by COBOL-60 and by the '68
standard between the data-name and the leading left paren. I also see some
evidence that the '68 standard prohibited a space between the leading left
paren and the first subscript, and between the last subscript and the
trailing paren.
The basic rules for '85 COBOL dictating where spaces are required are:
after separator periods, commas and semicolons; before an opening quotation
mark that isn't immediately preceded by a left paren; after a closing
quotation mark that isn't immediately followed by a close paren; and before
an opening pseudo-text delimiter; and between COBOL words and nonseparators
or any combination thereof.
> 2. I sometimes find it puzzling that spaces seem to be required around
> certain things in COBOL when I don't expect them to be.
COBOL wasn't designed to be about expressing formulae, it was intended to
allow the programmer to write in a language that a non-programmer stood a
chance of being able to read and comprehend, and critique as a
representation of business practices.
> For example
> after commas (in CALL),
Commas aren't required between arguments in a CALL in the first place, but
*separators* are. A "separator comma" may appear anywhere a "separator
space" may appear, but a "separator comma" consists of a comma *followed by
a space*. If you put a comma there, expect to put a space after it. But so
long as you have at least one space between the arguments, the compiler
should accept it.
> around the colon in reference modification (at
> least in the compilers I've tested)
I don't see any standard requirement that a ("separator") colon be either
preceded or followed by a space in reference modification, and our
implementation certainly doesn't require it. Have you checked your vendor's
documentation? Maybe a trouble report to the vendor is in order?
> and around operators in a COMPUTE
> expression.
English words are separated from each other by spaces, and spaces generally
figure into English punctuation. This is reflected in the fact that
arithmetic operators (+, -, *, /, **) aren't listed among the "separators"
in COBOL rules. In COBOL, syntactic elements of the language are separated
by "separators", which include spaces.
Note that in COBOL
COMPUTE A = B - C.
means something entirely different from
COMPUTE A = B-C.
which is one reason your COBOL compiler is likely to complain when you fail
to separate your syntactic elements with separators! Since you *have* to
separate the parts of "B-C" in this case to make sure the compiler
understands that it's two operators and an operand, it's considered a Good
Idea to separate the components of "B+C", "B/C", "B*C" and "B**C" as well,
even if your compiler allows you to "compact" them.
Getting as much as possible accomplished on a single line of source code
used to be considered the hallmark of Expert Coding. This has passed out of
favor -- even in languages where it is common like FORTRAN and ALGOL --
because it's rarely very readable and often difficult to maintain.
> Please note that the first language I learned was FORTRAN using
> fixed-form (punched card) format. There spaces are only meaningful
> inside string literals.
Getting as much as possible accomplished on a single line of source code
used to be considered the hallmark of Expert Coding. This has passed out of
favor -- even in languages where it is common like FORTRAN and ALGOL --
because it's rarely very readable and often difficult to maintain. It's
not just FORTRAN.
Fixed-form format is no excuse; standard COBOL was fixed-form format until
the introduction of the 2002 standard!
As far as punctuation goes, the rules for the Common Business Oriented
Language are not the rules for the Formula Translator. The idea that
Fortran's set of rules ought to suit the needs of a language built for an
entirely different purpose is not likely to be anything other than an
unfulfilled expectation.
> Is there a general rule about this for COBOL and has it changed with
> different versions of the standard?
The general stylistic rule for COBOL is that COBOL is based on English, in
which letters are combined into words that are separated by spaces and
punctuation marks. The punctuation rules are similar to those for English
as well, including the frequent requirement that certain punctuation marks
be followed by at least one space. Some specifics may have changed over
time, but a separator space where it is allowed is
rarely a Bad Idea in COBOL.
What is considered readable code in COBOL generally bears a very close
relationship to the rules of English punctuation. In that language,
typically, at least one space follows a comma or period or semicolon, a
parenthetical expression is separated from its preceding text by a space,
and the contents of a parenthetical expression most often are adjacent to
their enclosing parentheses. Such is the convention with COBOL.
-Chuck Stevens
| |
| Chuck Stevens 2005-05-27, 8:55 pm |
| I'm hoping to get a copy of the '68 standard Real Soon Now so that I can
verify such matters.
But a copy of a Burroughs pre-ANSI-68 manual using suspiciously
"standardese" language supports this -- "The subscript, or a set of
subscripts, that identifies the table element is enclosed in parenthesis
immediately following the terminal space of the table element data-name."
IBM DOS COBOL-68 reference manual from '73 has virtually identical
wording -- it more correctly uses the plural "parentheses" and revises the
end of the phrase slightly. In the same paragraph an IBM extension is
marked as an extension; this particular wording isn't marked that way. The
fact that this wording is shared by two different vendors and the fact that
it isn't marked as an extension in IBM's manual pretty much convince me that
this wording is really, really close to what ANSI X3.23-1968 specifies.
-Chuck Stevens
"Howard Brazee" <howard@brazee.net> wrote in message
news:d77ogp$h80$1@peabody.colorado.edu...
>
> On 27-May-2005, "Chuck Stevens" <charles.stevens@unisys.com> wrote:
>
'68[color=darkred]
some[color=darkred]
left[color=darkred]
>
> That seems to be what I remember. But it's sometimes hard to remember
what was
> a CoBOL rule, and what was a standards rule or a habit.
| |
| epc8@juno.com 2005-05-27, 8:55 pm |
|
Chuck Stevens wrote:
> Let's try that again. Things got messed up in the editing, and perhaps I
> was too abrupt.
>
> <epc8@juno.com> wrote in message
> news:1117154259.996313.163080@z14g2000cwz.googlegroups.com...
>
>
[snip]
>
> Getting as much as possible accomplished on a single line of source code
> used to be considered the hallmark of Expert Coding. This has passed out of
> favor -- even in languages where it is common like FORTRAN and ALGOL --
> because it's rarely very readable and often difficult to maintain. It's
> not just FORTRAN.
>
I was just explaining my background, not my preferences :-). When I
phrased the second part of the question I was thinking of the language
from the point of view of someone writing a parser for the language.
Somehow the questions I posed seemed more interesting at the time I
wrote them :-(.
Re: spaces required around colons in reference modification expression.
I am unable to reproduce this problem. Sorry.
[snip]
> The general stylistic rule for COBOL is that COBOL is based on English, in
> which letters are combined into words that are separated by spaces and
> punctuation marks. The punctuation rules are similar to those for English
> as well, including the frequent requirement that certain punctuation marks
> be followed by at least one space. Some specifics may have changed over
> time, but a separator space where it is allowed is
> rarely a Bad Idea in COBOL.
>
> What is considered readable code in COBOL generally bears a very close
> relationship to the rules of English punctuation. In that language,
> typically, at least one space follows a comma or period or semicolon, a
> parenthetical expression is separated from its preceding text by a space,
> and the contents of a parenthetical expression most often are adjacent to
> their enclosing parentheses. Such is the convention with COBOL.
>
> -Chuck Stevens
Thanks for a very considered, concise and literate description!
| |
| epc8@juno.com 2005-05-27, 8:55 pm |
| Chuck Stevens wrote:
> <epc8@juno.com> wrote in message
> news:1117154259.996313.163080@z14g2000cwz.googlegroups.com...
>
> Getting as much as possible accomplished on a single line of source code
> used to be considered the hallmark of Expert Coding. This has passed out of
> favor -- even in languages where it is common like FORTRAN and ALGOL --
> because it's rarely very readable and often difficult to maintain. It's
> not just FORTRAN.
>
Maybe Dijkstra was correct. I'm guilty on at least 3 counts. (FORTRAN,
APL, and BASIC.) Perhaps I've found the programmer's "Twinkie defense"
.... "But your honor, I once programmed in BASIC."
http://www.cs.virginia.edu/~evans/c...ngs/ewd498.html
Alas, he has something very nasty to say about COBOL.
| |
| Jeff York 2005-05-27, 8:55 pm |
| epc8@juno.com wrote:
>Chuck Stevens wrote:
>
>Maybe Dijkstra was correct. ...
Well.. Even a blind squirrel finds the occasional nut.. :-)
--
Jeff. Ironbridge, Shrops, U.K.
jeff@xjackfieldx.org (remove the x..x round jackfield for return address)
and don't bother with ralf4, it's a spamtrap and I never go there.. :)
.... "There are few hours in life more agreeable
than the hour dedicated to the ceremony
known as afternoon tea.."
Henry James, (1843 - 1916).
| |
| Chuck Stevens 2005-05-27, 8:55 pm |
|
<epc8@juno.com> wrote in message
news:1117229277.861081.54040@o13g2000cwo.googlegroups.com...
> http://www.cs.virginia.edu/~evans/c...ngs/ewd498.html
>
> Alas, he has something very nasty to say about COBOL.
Alas, *had*. He died August 6, 2002.
His antipathy to COBOL is well known; less well known is his similar
antipathy to FORTRAN and APL. I gather he *really* liked ALGOL (as did
Niklaus Wirth), which is the language (in one dialect or another) in which
just about all the software on the Unisys MCP systems is written (a notable
exception being COBOL85, written in Pascal, arguably a direct descendant of
ALGOL).
But note that his comments about COBOL seem to have originated in 1968; the
*first* ANSI standard for COBOL was approved in August of that year, and I
doubt very many fully-compliant implementations were available much before
the end of that year. And COBOL of that era lacked a number of features
that have since been added, including nested programs and delimited scope
statements to address the very concerns he raised.
Also, it is important to recognize that COBOL was never intended to be a
Language Beloved of the Academe like ALGOL, Pascal, PL/1, APL, ADA and on
and on and on; it was intended to be a programming language for
*businesses*, close enough to English that even an accountant could read it.
At the time Dijkstra made these comments, COBOL didn't have stuff like
delimited-scope statements, but it has evolved quite a bit since then.
The only language I know of that seems to have come close to Dijkstra's
preferences was SDL, the system software language for the Burroughs B1700
system and its successors, and its user-available UPL subset.
It lacked the GO TO construct that Dijkstra railed against. It even lacked
"limited" stepping statements like WHILE and FOR. It had only DO and DO
FOREVER, coupled with UNDO; it got around the "go to" problem by providing
"named" DO blocks and named UNDO statements, a surprising violation of
principle.
Dijkstra was a Burroughs research fellow a year or so after the introduction
of the B1700 systems; I suspect his ideas were fundamental to the language,
but I don't think he was actually involved in its development (I might be
wrong).
Dijkstra's (and Wirth's) beloved ALGOL, as well as ALGOL's direct descendant
Pascal, both include GO TO statements.
-Chuck Stevens
|
|
|
|
|