Re: If you were inventing CoBOL...
From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 09/08/04
- Next message: Richard: "Re: If you were inventing CoBOL..."
- Previous message: Richard: "Re: Is a General File Maintenance Routine possible?"
- In reply to: William M. Klein: "Re: If you were inventing CoBOL..."
- Next in thread: Howard Brazee: "Re: If you were inventing CoBOL..."
- Reply: Howard Brazee: "Re: If you were inventing CoBOL..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 7 Sep 2004 16:26:34 -0700
"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:FGq%c.943557$6p.164444@news.easynews.com...
> Chuck,
> I think the point (as I read it) is that "if we knew then - what we know
now"
> *and* we were inventing (from scratch) what became COBOL, would it (or
would it
> not) have been "better" to not allow/define "fall-thru".
I understand the premise, but I'm also not fond of "if pigs had wings ..."
speculations. What I've personally been focusing on is given what we know
now what would we now regard as *wrong* in COBOL. I think "abbreviated
combined relation conditions" is one, and I think deciding how a parameter
is processed *in a called program* at the level of the *call* is another.
Both have intrinsic problems in specification, I believe.
In fact, I just thought of another: Even in its current form COBOL's
support for currency signs is decidedly provincial. As I read the standard,
I can't get COBOL to produce a *floating* version of the most common
designator for the Venezuelan unit of currency. Why should England and the
US have preferential support from PICTURE? I think the floating
currency-sign was implemented for the US currency unit, and lo and behold it
works for the British pound, but beyond that it starts falling apart! I
haven't found a way to float the four-character sequence "Bs. " using the
syntax in 2002 COBOL and the PICTURE clause with all its appendages yet!
Speculation as to what would have happened if Dijkstra had written his
papers twenty years earlier than he did doesn't strike me as helpful -- any
more than "What would COBOL look like if somebody had invented Java in its
present form in 1957?" or "If a machine with a 512-megabyte main memory, a
2.8GHz processor, a 160-gigabyte hard drive, and built-in 100MHz data
communications capability could have been bought over-the-counter at your
local office supply store for $799 in 1968, what would a 'large machine'
have looked like at the time, and who would have actually needed one?"
I think the issues of "structured programming" are *style choice* issues,
and I don't think the *standards* should enforce a particular *style* any
more than I think
That being said,
> IMHO,
> It would have been better if (and this canNOT be changed now)
>
> A) there was *no* "thru procedure-name-2" syntax (Perform, Input/Output
> procedure, etc)
Not sure. I'm of the school that doesn't have a problem with GO TO -- so
long as its use is limited to the <paragraph-name-EXIT> of the paragraph I'm
in. EXIT PARAGRAPH and EXIT SECTION provide good support for structure
here.
> B) no Go To (but there was an "EXIT PERFORMED-PROCEDURE" statement
And the latter I agree with -- when I saw EXIT PERFORM one of the first
things I did was implement it as an extension to our COBOL74 implementation
(there were also compatibility issues based on our lack of the equivalent
EXIT HERE available as an extension to our '68 implementation). COBOL74
doesn't even allow inline PERFORM, but I haven't yet figured out why it was
disallowed in other contexts in the '02 standard. Is there a solid argument
against it, aside from the idea of gradual introduction of the feature?
EXIT PARAGRAPH and EXIT SECTION are big helps here. I'd vote for allowing
all three in all procedural contexts!
> C) and of course, no ALTER
And that I agree with as well ... though I can still see *some* very limited
utility to segment-numbers in an old-fashioned sort of way ...
> D) and (I am a little wishy-washy on this one) there were ONLY paragraphs
or
> ONLY sections, not both
Well, I think if nothing else there are *cosmetic* reasons for both, and
I've already said having both could be useful in "modularizing" programs at
a more atomic level than nested programs, at both the source and object code
levels.
> E) I would have wanted CONTINUE, scope-terminators, and probably (not
certain on
> this one either) no NEXT SENTENCE
I agree with you, and in the case of NEXT SENTENCE, with the 2002 standard
which deprecates its use. If you presume the presence of scope-terminators
in the language NEXT SENTENCE is not of much use at best. The standard
deprecates its use in IF and SEARCH, and those are the only cases in which
it's defined in the standard, so far as I know. The biggest problem with
NEXT SENTENCE is that some users came to think it really meant NEXT
STATEMENT, and to make matters worse some implementors actually did it that
way!
> F) I probably wouldn't want DECLARATIVES either - as they are (sort-of by
> definition) "non-structured"
Well, hm. They're also the closest thing COBOL has to asynchronous
processing, which is on the "desirable" list for the '08 draft ...
> I think that every current type of program could have been created with
these
> restrictions *and* I think (but can't prove it) that such a language would
have
> insured "easier to maintain" programs.
True, they could (well, maybe not the last ...); not clear whether it would
be "easier to maintain" if you were used to a language that had, for
example, GO TO. What would English be like if William the Conqueror had
read the OED from cover to cover or had a laptop to look words up in the
online Webster's?
-Chuck Stevens
- Next message: Richard: "Re: If you were inventing CoBOL..."
- Previous message: Richard: "Re: Is a General File Maintenance Routine possible?"
- In reply to: William M. Klein: "Re: If you were inventing CoBOL..."
- Next in thread: Howard Brazee: "Re: If you were inventing CoBOL..."
- Reply: Howard Brazee: "Re: If you were inventing CoBOL..."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
