Perfrom Thru
Kannan
say for example consisder this statement:
perform 001-start thru 005-end-exit.
My doubt is whether this statement above would execute the code
present 001-start and 005-end-exit procedures alone, or would execute
any para in between this two paras. Please clarify on this.
Thanks in advenace.
Arnold Trembley
docd...@panix.com
Robert Jones
The manuals for your compiler should explain this for you, for most
compilers, they are either supplied as hardcopy and/or as viewable
files, if you can't find them, most suppliers also have websites where
you can look at the manuals directly or download them for offline
viewing.
A "perform thru" performs all statement in all procedures between the
first and the second according to the logical flow of the statements.
I.e., it starts with the first statement in the first named procedure
and ends at the last statement in the second named procedure. It is
up to you to ensure that you don't GO TO or PERFORM anywhere else and
not come back.
Lueko Willms
schrieb arnold....@worldnet.att.net (Arnold Trembley)
auf /COMP/LANG/COBOL
in 7Nd5c.25024$H44.4...@bgtnsc04-news.ops.worldnet.att.net
ueber Re: Perfrom Thru
AT> All paragraphs between 001-start and 005-end-exit, inclusive, would
AT> be executed, unless a GO TO statement forces a program branch to some
AT> other label. Branching to another label outside the perform thru
AT> range is a very dangerous thing to do.
That's why I never use PERFORM _THRU,_ and apply PERFORM only on
SECTIONs, not Paragraphs, and prefer to use "inline"-PERFORM, and IF
.. ELSE .. END-IF.
After COBOL-85 came into being, there should be no more need to do
otherwise.
And a GO TO should never be used without a corresponding
COME FROM...
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Die Interessen der Nation lassen sich nicht anders formulieren als unter
dem Gesichtspunkt der herrschenden Klasse oder der Klasse, die die
Herrschaft anstrebt." - Leo Trotzki (27. Januar 1932)
JerryMouse
I notice you are corresponding from India.
Ken Grubb
>I notice you are corresponding from India.
PERFORM ... THRU ... must not have been covered in the Outsourcing
documentation.
Ken Grubb
Lower Paxton Twp, PA
Joe Zitzelberger
thamara...@yahoo.co.in (Kannan) wrote:
It will execute all of the code between the label 001-START and
005-END-EXIT.
However, it is a dangerous construct with plenty of hazards associated
with its use.
If you want to perform all the paragraphs in a range, my suggestion is
that you explicitly code a perform for each paragraph you want executed,
e.g:
PERFORM 001-START
PERFORM 002-DO-SOMETHING
PERFORM 003-DO-OTHER-THING
PERFORM 004-DO-LAST-THING
PERFORM 005-END-EXIT
instead of:
PERFORM 001-START THRU 005-END-EXIT
And please don't let the xenophobes bother you -- many people think
highly of India.
Regards,
Joe
berl...@sympatico.ca
>Please do your own homework.
Some are looking at skilled others who did:
http://sfgate.com/cgi-bin/article.cgi?f=/c/a/2004/03/13/MNG905K1BC1.DTL
Washington -- The government is taking the first steps toward a
targeted military draft of Americans with special skills in computers
and foreign languages.
====================================================
What an happy ending, old bernouilli!
Except if they outsource the lot, of course!
Clever, nay?
Pierra
intended. - Dick
Lueko Willms wrote:
><snp>
>
> That's why I never use PERFORM _THRU,_ and apply PERFORM only on
> SECTIONs, not Paragraphs, and prefer to use "inline"-PERFORM, and IF
> .. ELSE .. END-IF.
>
I disagree (IMHO) in that the PERFORM_THRU provides a very clear
definition of what you want to do. Having said that, a PERFORM
1000-START THROUGH 5000-EXIT is one of the confusing and improper things
to do. Should be PERFORM 1000-START THRU 1000-EXIT ONLY! The only
labels (and, if necessary GO TO's ) in the paragraph should be things
like 1000-CONTINUE or 1000-GROUP-BYPASS.
Remember, CLARITY is the MAJOR benefit for many coding techniques. You
want to insure that anyone can read, understand, and modify your code
when necessary.
Also, of prime importance, NEVER change styles in a program you are
modifying, unless you are COMPLETELY rewriting the program. Mixing and
mixing PERFORM_THRU and PERFORM's in the same program can give you more
headaches than you ever want.
Howard Brazee
On 15-Mar-2004, Joe Zitzelberger <joe_zitz...@nospam.com> wrote:
> If you want to perform all the paragraphs in a range, my suggestion is
> that you explicitly code a perform for each paragraph you want executed,
> e.g:
>
> PERFORM 001-START
> PERFORM 002-DO-SOMETHING
> PERFORM 003-DO-OTHER-THING
> PERFORM 004-DO-LAST-THING
> PERFORM 005-END-EXIT
>
> instead of:
>
> PERFORM 001-START THRU 005-END-EXIT
Note: The old style of coding that did PERFORM 001-START thru 0005-END-EXIT
typically had code in it that said GO TO 005-END-EXIT.
This error-prone code could not be replaced directly by your series of performs.
docd...@panix.com
Pierra <pie...@sprynet.com> wrote:
>Comments embedded below, CAPS for clarity and emphasis only, no shouting
>intended. - Dick
>
>Lueko Willms wrote:
>
>><snp>
>
>>
>> That's why I never use PERFORM _THRU,_ and apply PERFORM only on
>> SECTIONs, not Paragraphs, and prefer to use "inline"-PERFORM, and IF
>> .. ELSE .. END-IF.
>>
>I disagree (IMHO) in that the PERFORM_THRU provides a very clear
>definition of what you want to do. Having said that, a PERFORM
>1000-START THROUGH 5000-EXIT is one of the confusing and improper things
>to do. Should be PERFORM 1000-START THRU 1000-EXIT ONLY! The only
>labels (and, if necessary GO TO's ) in the paragraph should be things
>like 1000-CONTINUE or 1000-GROUP-BYPASS.
Well, here we are, back in the Thru/noTHRU debate. As has been stated
before... all decent, sane, attractive and appropriately-scented coders
write only PERFORM PARAGRAPH-NAME THRU PARAGRAPH-NAME-EXIT, allowing for a
GO TO directing execution to the paragraph name immediately preceding or
immediately following the instruction.
>
>Remember, CLARITY is the MAJOR benefit for many coding techniques. You
>want to insure that anyone can read, understand, and modify your code
>when necessary.
Clarity is, I believe, in the mind of the beholder... and don't worry, no
matter what you code the odds are that someone later will blame your style
for their difficulties.
>
>Also, of prime importance, NEVER change styles in a program you are
>modifying, unless you are COMPLETELY rewriting the program. Mixing and
>mixing PERFORM_THRU and PERFORM's in the same program can give you more
>headaches than you ever want.
Yes... and no. Consistency is good, true, but a 'foolish consistency is
the petty hobgoblin of little minds' (Emerson) ; consider the example of a
program written in ANSI '74 style but now being compiled under, say,
Enterprise COBOL for z/OS and OS/390... one can, with suitable care, use
scope delimiters and inline PERFORMS to great advantage.
DD
Joe Zitzelberger
"Howard Brazee" <how...@brazee.net> wrote:
I thought the original question was about a new perform construct. As
such, it could be easily written to use the alternative suggested style.
My position on the frivolous use of the GO TO statement is well
documented, there is no need to rehash that one again.
Howard Brazee
On 16-Mar-2004, Joe Zitzelberger <joe_zitz...@nospam.com> wrote:
> I thought the original question was about a new perform construct. As
> such, it could be easily written to use the alternative suggested style.
>
> My position on the frivolous use of the GO TO statement is well
> documented, there is no need to rehash that one again.
Except that the only reason to use PERFORM THRU is because one is in an old shop
that uses PERFORM THRU. Otherwise, the coder should move up to the 1970's when
the late comers finally moved to structured programming.
If I see PERFORM THRU, then I expect to see GO TO as well. I might luck out
and it's only GO TO XXX-EXIT. But I might not.
I don't know if I have ever seen a program that had PERFORM THRU without GO TO.
Such a style does not seem likely to me.
Richard
> I disagree (IMHO) in that the PERFORM_THRU provides a very clear
> definition of what you want to do. Having said that, a PERFORM
> 1000-START THROUGH 5000-EXIT is one of the confusing and improper things
> to do. Should be PERFORM 1000-START THRU 1000-EXIT ONLY!
That is just one of the problems that occurs with PERFORM TRHU. It
may be that the 1000-Exit was meant but was coded incorrectly. The
program may still appear to work (mostly) if 5000-Exit is later in the
program than 1000-Start, the code between 1000-Exit and 5000-Exit
being executed inadvertantly. Depending on what this code is it may
not be noticed that it is being executed, the damage being only minor
- mostly.
> The only
> labels (and, if necessary GO TO's ) in the paragraph should be things
> like 1000-CONTINUE or 1000-GROUP-BYPASS.
The _only_ rational point of having labels between 1000-Start and the
end of 1000-Exit is to allow GO TOs. It is trivially easy to avoid
using GO TOs. Therefore it is trivially easy to eliminate the
spurious labels and just have a PERFORM without THRU.
> Remember, CLARITY is the MAJOR benefit for many coding techniques. You
> want to insure that anyone can read, understand, and modify your code
> when necessary.
Eliminating GO TOs, labels and THRU is a major component of improving
clarity and readability.
> Also, of prime importance, NEVER change styles in a program you are
> modifying, unless you are COMPLETELY rewriting the program. Mixing and
> mixing PERFORM_THRU and PERFORM's in the same program can give you more
> headaches than you ever want.
Absolutely.
Chuck Stevens
news:217e491a.04031...@posting.google.com...
> The _only_ rational point of having labels between 1000-Start and the
> end of 1000-Exit is to allow GO TOs. It is trivially easy to avoid
> using GO TOs. Therefore it is trivially easy to eliminate the
> spurious labels and just have a PERFORM without THRU.
Not necessarily; I know of one other "rational" point for such.
There is (at least) one implementation in which it may be necessary to
insert unreferenced labels in the program to avoid exceeding any
architectural limits that might be encountered for extremely large (in terms
of generated object code, as distinct from source lines) paragraphs.
In such instances, if the existing paragraph is directly PERFORMed, the
program will break if it becomes necessary to insert a new paragraph.
PERFORM <section-name> as well as PERFORM ... THRU will continue to work
without problems.
If a paragraph has to be added to avoid such a limit and the existing
paragraph is PERFORMed without THRU, the easiest correction is to change
PERFORM to PERFORM ... THRU, in which instance I'd suggest adding an
unambiguous <original-paragraph-name>-EXIT paragraph as well, and use that
as the terminus.
-Chuck Stevens
Richard
> > The _only_ rational point of having labels between 1000-Start and the
> > end of 1000-Exit is to allow GO TOs. It is trivially easy to avoid
> > using GO TOs. Therefore it is trivially easy to eliminate the
> > spurious labels and just have a PERFORM without THRU.
> Not necessarily; I know of one other "rational" point for such.
> There is (at least) one implementation in which it may be necessary to
> insert unreferenced labels in the program to avoid exceeding any
> architectural limits that might be encountered for extremely large (in terms
> of generated object code, as distinct from source lines) paragraphs.
Was that on DOS perhaps ?
> In such instances, if the existing paragraph is directly PERFORMed, the
> program will break if it becomes necessary to insert a new paragraph.
What exactly do you mean by 'insert a new paragraph' in the context of
'an existing paragraph' ? I assume that you mean a pargraph label.
> PERFORM <section-name> as well as PERFORM ... THRU will continue to work
> without problems.
And so, no doubt, would using sensible sized pargraphs in a more
modular way, each of which is performed without thru or sections.
> If a paragraph has to be added to avoid such a limit and the existing
> paragraph is PERFORMed without THRU, the easiest correction is to change
> PERFORM to PERFORM ... THRU, in which instance I'd suggest adding an
> unambiguous <original-paragraph-name>-EXIT paragraph as well, and use that
> as the terminus.
And I would suggest not doing that, but instead breaking the code down
into more easily grasped functional parts that are performed
separately. But then who am I to preach about this, I have written a
single paragraph that contained a single EVALUATE that ran to over
1500 lines. ;-)
(it was a Windows callback)
Lueko Willms
schrieb charles...@unisys.com (Chuck Stevens)
bei /COMP/LANG/COBOL
in c37t1c$1moq$1...@si05.rsvl.unisys.com
ueber Re: Perfrom Thru
CS> There is (at least) one implementation in which it may be necessary
CS> to insert unreferenced labels in the program to avoid exceeding any
CS> architectural limits that might be encountered for extremely large
CS> (in terms of generated object code, as distinct from source lines)
CS> paragraphs.
Which compiler did that? I see that you work at the company where I
did all my COBOL work...
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Ohne Pressefreiheit, Vereins- und Versammlungsrecht ist keine
Arbeiterbewegung möglich" - Friedrich Engels (Februar 1865)
Howard Brazee
On 16-Mar-2004, "Chuck Stevens" <charles...@unisys.com> wrote:
> There is (at least) one implementation in which it may be necessary to
> insert unreferenced labels in the program to avoid exceeding any
> architectural limits that might be encountered for extremely large (in terms
> of generated object code, as distinct from source lines) paragraphs.
>
> In such instances, if the existing paragraph is directly PERFORMed, the
> program will break if it becomes necessary to insert a new paragraph.
> PERFORM <section-name> as well as PERFORM ... THRU will continue to work
> without problems.
It's easy enough to replace hunks of such code with PERFORMs of new paragraphs.
Chuck Stevens
news:217e491a.04031...@posting.google.com...
> > Not necessarily; I know of one other "rational" point for such.
>
> > There is (at least) one implementation in which it may be necessary to
> > insert unreferenced labels in the program to avoid exceeding any
> > architectural limits that might be encountered for extremely large (in
terms
> > of generated object code, as distinct from source lines) paragraphs.
>
> Was that on DOS perhaps ?
No.
>
> > In such instances, if the existing paragraph is directly PERFORMed, the
> > program will break if it becomes necessary to insert a new paragraph.
>
> What exactly do you mean by 'insert a new paragraph' in the context of
> 'an existing paragraph' ? I assume that you mean a pargraph label.
Yes, in the *middle* of the source text for the existing paragraph, turning
it into two paragraphs.
> > PERFORM <section-name> as well as PERFORM ... THRU will continue to
work
> > without problems.
>
> And so, no doubt, would using sensible sized pargraphs in a more
> modular way, each of which is performed without thru or sections.
The problem comes when what seems like a reasonably-sized paragraph at the
source level generates huge quantities of code. I have seen program
listings that included representations of the generated object code that
occupied scores of pages for a single STRING, UNSTRING and INSPECT
statement. Moreover, I've seen the object code requirements for a test of
an 88-level item more than double when the item to which the 88-level refers
is increased in size by a single character, with no change to the procedural
source code.
> > If a paragraph has to be added to avoid such a limit and the existing
> > paragraph is PERFORMed without THRU, the easiest correction is to change
> > PERFORM to PERFORM ... THRU, in which instance I'd suggest adding an
> > unambiguous <original-paragraph-name>-EXIT paragraph as well, and use
that
> > as the terminus.
>
> And I would suggest not doing that, but instead breaking the code down
> into more easily grasped functional parts that are performed
> separately.
If you have time, that's fine. If you have a production program that has to
be live in the next ten minutes, you may not have that luxury. The idea
here is making the minimum change that will allow the program to compile and
run reliably.
-Chuck Stevens
Chuck Stevens
The architectural limit for an object code segment on this system is 8192
words, or 49,152 bytes. The COBOL74 compiler segments Procedure Division
code unconditionally at the SECTION level, and optionally at the paragraph
level, but never, ever can the code generated for a paragraph exceed that
limit.
I once saw a complaint from a user that changing the DATA DIVISION code
caused a Code Segment Limit syntax error in Procedure Division code. Turns
out the user had increased the size of a single data item from three to nine
characters. That data item had some 35 88-level items associated with it,
most of which were multi-valued, and many of which had THRU clauses. This
dramatically increased the object code generated for what at the source
level was a simple IF statement, but at the object code level required a
number of comparisons; the increase was sufficient to cause code segment
overflows in a number of places in the program. Note that this is a syntax
error requiring programmer correction, not a compiler error.
Unisys MCP/AS COBOL85 uses an entirely different algorithm for code
segmentation and does not encounter this issue.
"Lueko Willms" <l.wi...@jpberlin.de> wrote in message
news:9519f...@jpberlin-l.willms.jpberlin.de...
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
[snip]
>The problem comes when what seems like a reasonably-sized paragraph at the
>source level generates huge quantities of code. I have seen program
>listings that included representations of the generated object code that
>occupied scores of pages for a single STRING, UNSTRING and INSPECT
>statement. Moreover, I've seen the object code requirements for a test of
>an 88-level item more than double when the item to which the 88-level refers
>is increased in size by a single character, with no change to the procedural
>source code.
Ahhhhh, for the Oldene Dayse! Mr Stevens, my experience is with IBM
mainframe compilers... but the change there from IKFCBL00 to IGYCRCTL
changed how things compiled. STRING/UNSTRING and INSPECT used to be
*very* expensive... but now are less so, or at least apparently less so.
A statement like
STRING FLD1(3:2), FLD2, FLD3 DELIMITED BY SIZE INTO FLD4
... creates the assembley equivalent of:
L 5,92(0,9) TGTFIXD+92
L 15,152(0,5) V(IGZCSTG )
LA 1,3717(0,4) PGMLIT AT +19493
BALR 14,15
... and notice how all the ... unpleasantness is now hidden in a call to
IGZCSTG. INSPECTs are even more curious...
INSPECT FLDA REPLACING ALL 'AMB' BY 'ZML'
... gives:
L 15,68(0,5) V(IGZCIN1 )
LA 1,3664(0,4) PGMLIT AT +19440
BALR 14,15
... showing a call of subrtn IGZCIN1, while
INSPECT FLDA REPLACING ALL 'A' BY 'Q'
...gives:
L 6,440(0,9) BLF=10
TR 0(160,6),317(4) FLDA
... where TR is, of course, the TRanslate intruction. This seques nicely
into the observation about code requirements increasing when the size of a
data-item which is 88'd is increased; a single-character 88 results in a
CLI where multi-character ones generate at least a CLC.
(I recall reading someplace - the Murach book? - that a CLC is three times
as expensive as a CLI... and this is why All Good Programmers, when given
a choice, keep frequently-addressed 88s to a single character.)
[snip]
>If you have time, that's fine. If you have a production program that has to
>be live in the next ten minutes, you may not have that luxury.
Hmmmmm... a classic example of the 'round too-it' philosophy... 'just
patch the fool thing and get it into Production, we'll Fix It Right when
we get around to it'.
>The idea
>here is making the minimum change that will allow the program to compile and
>run reliably.
As many know, Mr Stevens, a program which makes it through any given run
and gives accurate results may not be 'reliable'... the bug that you
patched over may well be lurking under the surface, waiting for tomorrow's
keyboarding error to bring the region down, hard. The question becomes
one of short-term versus long term: 'How much time does a coder spend
making sure that the program is made long-term reliable?'
(ans: as long as the person who signs the timesheet permits, of course)
DD
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
>Unisys ClearPath MCP/AS COBOL74 (and the now-no-longer-supported COBOL(68)).
Ahh... in my other posting I mentioned IKFCBL00; that was the IBM
mainframe COBOL '74 compiler... and one must be very careful about coding
for the limits of such things; after all, they are only...
... thirty years old.
[snip]
>I once saw a complaint from a user that changing the DATA DIVISION code
>caused a Code Segment Limit syntax error in Procedure Division code. Turns
>out the user had increased the size of a single data item from three to nine
>characters. That data item had some 35 88-level items associated with it,
>most of which were multi-valued, and many of which had THRU clauses. This
>dramatically increased the object code generated for what at the source
>level was a simple IF statement, but at the object code level required a
>number of comparisons; the increase was sufficient to cause code segment
>overflows in a number of places in the program. Note that this is a syntax
>error requiring programmer correction, not a compiler error.
I am not sure I understand the distinction you are making here, Mr
Stevens; a 'syntax error', as I understand it, is an error in relating the
elements of the language so that they way the elements relate are no
longer in accord with the rules for said language. For example:
PERFORM PARA-A THRU PARA-C IN ORDER GIVING RESULT-FIELD
... uses reserved words, true, but their relation is syntactically invalid
for the COBOL language.
In the situation you describe above the compiler began to generate invalid
code based on what appears to be permitted syntax.
>
>Unisys MCP/AS COBOL85 uses an entirely different algorithm for code
>segmentation and does not encounter this issue.
Aye... as mentioned in my other posting this is true of IBM mainframe
compiler IGYCRCTL.
DD
Chuck Stevens
libraries to handle complex logic such as can be produced by STRING,
UNSTRING and INSPECT, in the belief that candidates for optimization are
better detected at the source level. The fact that an external procedure is
called does not necessarily imply that the result is more efficient (though
I grant that that may sometimes be true!).
I believe the *performance* of these verbs is adequate, which is the major
concern of most users. But the code generated is nontrivial for many
variants of these verbs.
As to alphanumeric 88's: An individual test for a 3-byte literal in an
88-level item associated with a 3-byte field seventeen bytes into a record,
as generated by COBOL74, looks like
LT8(17), NMC2 (descriptor for memory space containing field), INDX,
LT48(literal, then spaces),
LT8(3), CREL, ZERO, EQUL ...
For a 3-byte literal and a 7-byte field,
LT8(17), NMC2(ibid), INDX,
LT48(literal, then spaces), LT48(spaces), JOIN,
LT8(7), CREL, EQUL ...
and for say 13 bytes
LT8(17), NMC2(ibid), INDX,
ZERO/ONE/LT8/LT16 (offset of literal with space fill in literal pool),
NMC1, INDX,
LT8(13), CREL, ZERO, EQUL ...
Whether LT, NMC1, INDX is faster than either LT48 or LT48, LT48, JOIN
depends on which of a range of systems you're talking about. But LT48,
LT48, JOIN occupies quite a bit more code space than the other two
alternatives, which is the issue at hand.
-Chuck Stevens
<docd...@panix.com> wrote in message news:c3a4sj$ppi$1...@panix5.panix.com...
Chuck Stevens
<docd...@panix.com> wrote in message news:c3a5mu$s2a$1...@panix5.panix.com...
> In article <c39vmh$2kr$1...@si05.rsvl.unisys.com>,
> Chuck Stevens <charles...@unisys.com> wrote:
> >Unisys ClearPath MCP/AS COBOL74 (and the now-no-longer-supported
COBOL(68)).
>
> Ahh... in my other posting I mentioned IKFCBL00; that was the IBM
> mainframe COBOL '74 compiler... and one must be very careful about coding
> for the limits of such things; after all, they are only...
>
> ... thirty years old.
I don't disagree. But we have many, many happy users of Unisys MCP/AS
COBOL74, and it remains a supported product.
> I am not sure I understand the distinction you are making here, Mr
> Stevens; a 'syntax error', as I understand it, is an error in relating the
> elements of the language so that they way the elements relate are no
> longer in accord with the rules for said language.
The term "syntax error" does not appear in ANSI X3.23-1974. As I see it, as
a practical matter syntax errors are not necessarily limited to syntax
rules, nor are run-time errors necessarily limited to general rules, even in
the current standard. A paragraph for which a given compiler generates
more object code than can be contained in a given object code segment on a
given architecture requires *syntactic* correction -- splitting the
paragraph -- by the programmer, and is thus a *syntax error* in that
implementation.
Reengineering that compiler to use a different code segmentation scheme may
not be appropriate given a large user base and customers dependent on the
current mechanism. Providing an alternative mechanism that the user may
specify still requires at least minimal source alteration to invoke such a
mechanism.
-Chuck Stevens
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
>
><docd...@panix.com> wrote in message news:c3a5mu$s2a$1...@panix5.panix.com...
>> In article <c39vmh$2kr$1...@si05.rsvl.unisys.com>,
>> Chuck Stevens <charles...@unisys.com> wrote:
>> >Unisys ClearPath MCP/AS COBOL74 (and the now-no-longer-supported
>COBOL(68)).
>>
>> Ahh... in my other posting I mentioned IKFCBL00; that was the IBM
>> mainframe COBOL '74 compiler... and one must be very careful about coding
>> for the limits of such things; after all, they are only...
>>
>> ... thirty years old.
>
>I don't disagree. But we have many, many happy users of Unisys MCP/AS
>COBOL74, and it remains a supported product.
>
>> I am not sure I understand the distinction you are making here, Mr
>> Stevens; a 'syntax error', as I understand it, is an error in relating the
>> elements of the language so that they way the elements relate are no
>> longer in accord with the rules for said language.
>
>The term "syntax error" does not appear in ANSI X3.23-1974.
This might be why, Mr Stevens, I did not cite the standard and instead
relied on a definition of 'syntax' supplied by a common reference
(http://www.m-w.com).
>As I see it, as
>a practical matter syntax errors are not necessarily limited to syntax
>rules, nor are run-time errors necessarily limited to general rules, even in
>the current standard. A paragraph for which a given compiler generates
>more object code than can be contained in a given object code segment on a
>given architecture requires *syntactic* correction -- splitting the
>paragraph -- by the programmer, and is thus a *syntax error* in that
>implementation.
The program may require a correction in syntax not because the syntax is
at variance with the Standard, Mr Stevens, but because the compiler's
interpretation of the syntax results in undesireable conditions. Given a
definition of syntax as 'the way in which linguistic elements (as words)
are put together to form constitutents (as phrases or clauses)' then the
error is not 'an error of syntax' or a 'syntax error'.
(Given a definition of syntax as 'The rules governing the formation of
statements in a programming language' (www.dictionary.com, citing the AHD)
it becomes even more obvious; changing the size of the data item is well
within the rules given in the standard... but the compiler chokes.)
>
>Reengineering that compiler to use a different code segmentation scheme may
>not be appropriate given a large user base and customers dependent on the
>current mechanism.
Ahhhhhh... the classic 'You can't fix that bug... our processing depends
on it!'
>Providing an alternative mechanism that the user may
>specify still requires at least minimal source alteration to invoke such a
>mechanism.
The source may need to be altered, Mr Stevens, but not because the syntax
is at variance with the Standard... hence my questioning of labelling the
circumstance as a 'syntax error'. If it is a given that syntax is
dictated by the Standard I would appreciate a demonstration as to how
another conclusion is possible. As I see our two views:
You say: 'The statement will not compile without a change in syntax. The
statement will not compile because there is a syntax error.'
I say: 'The statement will not compile without a change in syntax. The
syntax of the statement is in full accord with the appropriate Standard.
The statement will not compile because the compiler will not accept a
statement which is in full accord with the appropriate Standard.'
DD
JerryMouse
>
> And I would suggest not doing that, but instead breaking the code down
> into more easily grasped functional parts that are performed
> separately. But then who am I to preach about this, I have written a
> single paragraph that contained a single EVALUATE that ran to over
> 1500 lines. ;-)
Suzie kept one little sheep,
It's fleece shown white like snow
Yet everwhere Suzie went,
The sheep did surely go.
I'm currently working on Hamlet without the letter "O."
"Let be, yet maybe anti-be, this is the quandry..."
It isn't easy, but what's art without suffering.
Chuck Stevens
> Ahhhhhh... the classic 'You can't fix that bug... our processing depends
> on it!'
You can't fix a bug if two users are adamant that the compiler work in
different ways *by default*.
It is not necessarily a bug, for example, to make all code segments in a
program save the last some 8K words long and let the "segment breaks"fall
where they may, without any user control over where they might fall, even if
the segment breaks fall in the middle of a "tight loop" in a
performance-critical path in the program.
It is also not necessarily a bug to have the code segmentation scheme bear
some relationship to the way the programmer has structured the program,
using SECTIONs as unconditional boundaries and paragraphs as potential ones,
with the risk that the code for a given paragraph might exceed a hard limit.
It is not a bug for the user to be able to choose either approach, for that
matter.
But both approaches cannot simultaneously be the default behavior.
As to whether such a limit conforms to the applicable standard, there isn't
one in force that applies. Whether ANSI X3.23-1974 does or does not provide
for the possibility that the implementor may encounter or enforce such
limitations is moot, as that particular standard has been out of force for
nigh onto twenty years now.
-Chuck Stevens
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
><docd...@panix.com> wrote in message news:c3acn4$goq$1...@panix5.panix.com...
>
>> Ahhhhhh... the classic 'You can't fix that bug... our processing depends
>> on it!'
>
>You can't fix a bug if two users are adamant that the compiler work in
>different ways *by default*.
One can do - within legal and physical limits - whatever one pleases, Mr
Stevens... whether one can do such things and retain a customer base is
another matter, entire.
I noticed, however, that you did not address my summation of our different
viewpoints... in fact, it seems that you removed it without any evidence
of editing whatsoever. Might you be so kind as to comment on this,
please? I wrote -
--begin quoted text:
The source may need to be altered, Mr Stevens, but not because the syntax
is at variance with the Standard... hence my questioning of labelling the
circumstance as a 'syntax error'. If it is a given that syntax is
dictated by the Standard I would appreciate a demonstration as to how
another conclusion is possible. As I see our two views:
You say: 'The statement will not compile without a change in syntax. The
statement will not compile because there is a syntax error.'
I say: 'The statement will not compile without a change in syntax. The
syntax of the statement is in full accord with the appropriate Standard.
The statement will not compile because the compiler will not accept a
statement which is in full accord with the appropriate Standard.'
--end quoted text
... and I would appreciate your verifying if my interpretation of your
view is correct.
DD
Lueko Willms
schrieb docd...@panix.com
auf /COMP/LANG/COBOL
in c3btne$k5$1...@panix1.panix.com
ueber Re: Perfrom Thru
d> You say: 'The statement will not compile without a change in syntax.
d> The statement will not compile because there is a syntax error.'
d>
d> I say: 'The statement will not compile without a change in syntax.
d> The syntax of the statement is in full accord with the appropriate
d> Standard. The statement will not compile because the compiler will not
d> accept a statement which is in full accord with the appropriate
d> Standard.'
The Standard (let me remind you that this is an old compiler
implementing the 1974 recommendations) does not require that a
contigouus sequence of statements must be allowed to have any
arbitrary length.
If there is any statement on this matter, it would certainly leave
this to the implementor. I don't have the Text of X3.23 ANS COBOL 1974
at hand to verify this, but I found this in the September 1981 draft
of COBOL-85:
--------- schnipp -----------------------------------------
In general, Standard COBOL specifies no upper limit on such things
as the number of statements in a program and the number of operands
permitted in certain statements. It is recognized that these limits
will vary from one implementation of Standard COBOL to another and may
prevent the successful translation of some programs that meet the
requirements of Standard COBOL.
------------------ schnapp --------------------------------
Section I, Chapter 1.7
I have no qualms if the compiler tells the trespassing of such
limits as a "syntax error" if the programmer can avoid such an error
by syntactically changing the code to be translated.
docd...@panix.com
Lueko Willms <l.wi...@jpberlin.de> wrote:
> Am 18.03.04
>schrieb docd...@panix.com
> auf /COMP/LANG/COBOL
> in c3btne$k5$1...@panix1.panix.com
> ueber Re: Perfrom Thru
>
>d> You say: 'The statement will not compile without a change in syntax.
>d> The statement will not compile because there is a syntax error.'
>d>
>d> I say: 'The statement will not compile without a change in syntax.
>d> The syntax of the statement is in full accord with the appropriate
>d> Standard. The statement will not compile because the compiler will not
>d> accept a statement which is in full accord with the appropriate
>d> Standard.'
>
> The Standard (let me remind you that this is an old compiler
>implementing the 1974 recommendations) does not require that a
>contigouus sequence of statements must be allowed to have any
>arbitrary length.
I do not believe, Mr Willms, that the length of the statement Mr Stevens
mentioned changed... just the length of the data-field which was being
evaluated for a condition, as stated in:
<http://groups.google.com/groups?selm=c39vmh%242kr%241%40si05.rsvl.unisys.com&oe=UTF-8&output=gplain>
--begin quoted text:
I once saw a complaint from a user that changing the DATA DIVISION code
caused a Code Segment Limit syntax error in Procedure Division code.
Turns out the user had increased the size of a single data item from three
to nine characters.
--end quoted text
As I understand (and simplify) the example:
01 FLDA PIC X(03).
88 COND1 VALUE 'AAA'.
...
IF COND1 THEN (imperative statement)
... compiled and executed as expected while
01 FLDA PIC X(09).
88 COND1 VALUE 'AAAAAAAAA'.
...
IF COND1 THEN (imperative statement)
... caused the 'Code Segment Limit syntax error in the Procedure
Division'.
Now I would readily agree that changing a data *type* can render a given
syntax invalid; the target/receiving operand for a COMPUTE should not be
other than some type of numeric. What is being said here, however, seems
to be that a change in a field's size, and size alone, renders a
previously-accepted syntax as an error because of the amount of code the
compiler produces as a result of this change... and this seems, to me, to
be a matter of the compiler's workings and not the language's syntax,
hence my questioning and attempts to discuss.
I don't expect any earth-shaking changes to result from this... but I
would hope to see open, honest, reasoned discusion - establishing
definitions, generating logical relations, comparing and interpreting the
resulting conclusions - about what might be seen as a rather fundamental
question of 'what are the criteria used in applying a given label to a
situation?'...
... and, of course, I have seen enough of the world to know that, at
times, my hopes can be cruelly dashed... but hey, it is a change from
posting 'please do your own homework' and requesting rates, or ranges of
rates.
DD
Michael Wojcik
In article <C_ednYa8kt1...@giganews.com>, "JerryMouse" <nos...@bisusa.com> writes:
>
> Suzie kept one little sheep,
> It's fleece shown white like snow
This should be "Its", if this is an ANSI-standard sheep, and not just
a big ball o' fleece.
> Yet everwhere Suzie went,
If you made this "Yet everywhere this Suzie went" you'd maintain the
meter of the original.
> The sheep did surely go.
Still, a noble effort, now fortunately enshrined in Google Groups
for posterity.
> I'm currently working on Hamlet without the letter "O."
>
> "Let be, yet maybe anti-be, this is the quandry..."
>
>
> It isn't easy, but what's art without suffering.
Indeed.
--
Michael Wojcik michael...@microfocus.com
Art is our chief means of breaking bread with the dead ... but the social
and political history of Europe would be exactly the same if Dante and
Shakespeare and Mozart had never lived. -- W. H. Auden
There are many definitions of what art is, but what I am convinced art is not
is self-expression. If I have an experience, it is not important because it
is mine. It is important because it's worth writing about for other people,
worth sharing with other people. That is what gives it validity. (Auden)
Any average educated person can turn out competent verse. -- W. H. Auden
Richard
>
> "Let be, yet maybe anti-be, this is the quandry..."
>
>
> It isn't easy, but what's art without suffering.
But it should be the artist that suffers, not, as in this case, the audience.
Lueko Willms
schrieb docd...@panix.com
bei /COMP/LANG/COBOL
in c3ceqj$i28$1...@panix5.panix.com
ueber Re: Perfrom Thru
d> What is being said here, however,
d> seems to be that a change in a field's size, and size alone, renders a
d> previously-accepted syntax as an error because of the amount of code
d> the compiler produces as a result of this change... and this seems, to
d> me, to be a matter of the compiler's workings and not the language's
d> syntax, hence my questioning and attempts to discuss.
Which makes clear that this is an implementation issue.
I really don't care if the compiler emits a message saying "You have
bypassed my implementation limits" or "I can't cope with that syntax
any more, which I see as an error", if the programmer can find
somewhere clear indications on how to adapt his program to compile to
a correct executable.
It doesn't matter, if the number of sentences in one Paragraph
changed, or some data definition. Fact is that the compiler choked and
could no longer generate executable code.
d> I don't expect any earth-shaking changes to result from this...
Especially in the case of a compiler implementing COBOL-1974, when a
newer compiler implementing COBOL-85 is available. What in all
probability means that the COBOL-74 compiler, if still supported, will
not implement new features, but maybe just some minor error
corrections. Probably not more than making sure that it works
correctly under new versions of the operating system.
I would recommend anyone to move up to COBOL-85.
d> but I would hope to see open, honest, reasoned discusion -
d> establishing definitions, generating logical relations, comparing
d> and interpreting the resulting conclusions - about what might be
d> seen as a rather fundamental question of 'what are the criteria
d> used in applying a given label to a situation?'...
Yeah, the main issue in this case is: implementation issues are up
to the implementor.
That's the way the cookie crumbles.
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Die Arbeit in weißer Haut kann sich nicht dort emanzipieren, wo sie
in schwarzer Haut gebrandmarkt wird." - Karl Marx 12.11.1866
Lueko Willms
schrieb L.Wi...@JPBERLIN.de (Lueko Willms)
auf /COMP/LANG/COBOL
in 959LI...@jpberlin-l.willms.jpberlin.de
ueber Re: Perfrom Thru
LW> I would recommend anyone to move up to COBOL-85.
Well ... I understand that there is an even newer standard, 2002.
My contact with COBOL production work ended 10 years ago.
docd...@panix.com
Lueko Willms <l.wi...@jpberlin.de> wrote:
> Am 18.03.04
> schrieb docd...@panix.com
> bei /COMP/LANG/COBOL
> in c3ceqj$i28$1...@panix5.panix.com
> ueber Re: Perfrom Thru
>
>d> What is being said here, however,
>d> seems to be that a change in a field's size, and size alone, renders a
>d> previously-accepted syntax as an error because of the amount of code
>d> the compiler produces as a result of this change... and this seems, to
>d> me, to be a matter of the compiler's workings and not the language's
>d> syntax, hence my questioning and attempts to discuss.
>
> Which makes clear that this is an implementation issue.
Clarity is in the eye of the beholder, Mr Willms... clearly Mr Stevens has
labelled it a 'syntax problem' and - unless my service has been editing or
dropping his postings here - has not responded to my requests for
clarification. This might be seen as understandable, given that a 'syntax
error' is usually tossed into the coder's lap to resolve.
[snip]
>d> I don't expect any earth-shaking changes to result from this...
>
> Especially in the case of a compiler implementing COBOL-1974, when a
>newer compiler implementing COBOL-85 is available. What in all
>probability means that the COBOL-74 compiler, if still supported, will
>not implement new features, but maybe just some minor error
>corrections.
Given the number of code-possibilities the compiler has been subject to in
the past three decades it might be reasonable to consider it unlikely that
there are too many situations which have *not* been encountered... and
are, most likely, being relied upon. As Mr Stevens pointed out... if two
or more of you are gathered in a particular 'feature's' name then it is
unlikely that said 'feature' will be changed.
DD
Chuck Stevens
<docd...@panix.com> wrote in message news:c3ei3a$sve$1...@panix1.panix.com...
> Clarity is in the eye of the beholder, Mr Willms... clearly Mr Stevens has
> labelled it a 'syntax problem' and - unless my service has been editing or
> dropping his postings here - has not responded to my requests for
> clarification. This might be seen as understandable, given that a 'syntax
> error' is usually tossed into the coder's lap to resolve.
I have not responded to your repeated requests for an extended essay on what
I regard as a syntax error in which contexts for two reasons: 1) I believe
in the context of the various COBOL dialects others have answered
adequately, and 2) I have been embroiled in internecine discussion on the
correct way to generate object code to close files in a MERGE (as generated
by all compilers that have syntactic support for sort/merge), as well as the
proper way to simulate the long-deprecated ICVU operator without using the
almost-as-deprecated ICVD operator as utilized by ALGOL (both ICVD and ICVU
are long since gone from all other language compilers' code generation
schemata).
Given Mr. Klein's eloquent response I felt my time was better utilized
resolving problems that more directly affected our users!
-Chuck Stevens
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
>
><docd...@panix.com> wrote in message news:c3ei3a$sve$1...@panix1.panix.com...
>> Clarity is in the eye of the beholder, Mr Willms... clearly Mr Stevens has
>> labelled it a 'syntax problem' and - unless my service has been editing or
>> dropping his postings here - has not responded to my requests for
>> clarification. This might be seen as understandable, given that a 'syntax
>> error' is usually tossed into the coder's lap to resolve.
>
>I have not responded to your repeated requests for an extended essay on what
>I regard as a syntax error in which contexts for two reasons:
Please excuse the impoliteness of my midsentence interruption, Mr Stevens,
but to the best of my knowledge I have not requested an 'extended essay'
from you or anyone else. I have asked twice - and now ask for the third
and final time - whether my summary of our differences may be summarised
as follows:
From
<http://groups.google.com/groups?q=g:thl2606514595d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=c3acn4%24goq%241%40panix5.panix.com>
...
and
<http://groups.google.com/groups?q=g:thl1318021115d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=c3btne%24k5%241%40panix1.panix.com>
--begin quoted text:
You say: 'The statement will not compile without a change in syntax. The
statement will not compile because there is a syntax error.'
I say: 'The statement will not compile without a change in syntax. The
syntax of the statement is in full accord with the appropriate Standard.
The statement will not compile because the compiler will not accept a
statement which is in full accord with the appropriate Standard.'
--end quoted text
If my interpretation is in error then it might be courteous to supply
clarification. If I am correct then an acknowledgement of accuracy would
be appreciated.
DD
Chuck Stevens
<docd...@panix.com> wrote in message news:c3f8cn$qka$1...@panix5.panix.com...
I wrote:
> >I have not responded to your repeated requests for an extended essay on
what
> >I regard as a syntax error in which contexts for two reasons:
>
> Please excuse the impoliteness of my midsentence interruption, Mr Stevens,
> but to the best of my knowledge I have not requested an 'extended essay'
> from you or anyone else. I have asked twice - and now ask for the third
> and final time - whether my summary of our differences may be summarised
> as follows:
I do not feel I can do justice to the answer without a lengthy response, and
I do not have time to compose one.
> If my interpretation is in error then it might be courteous to supply
> clarification. If I am correct then an acknowledgement of accuracy would
> be appreciated.
Perhaps it would have been clearer had I written "paragraph" or "program"
instead of "statement". I do believe your interpretation of my intent is
indeed incorrect.
There is nothing inherently wrong with a single IF statement that references
an 88-level item that generates vast quantities of code, nor is there
anything inherently wrong with the compiler that does so.
The error is in having a paragraph whose generated code (including such an
IF statement or not) exceeds implementation limits (in this case,
documented -- Form 8600 0296-203 page 5-4, in case you're curious), for
which the appropriate correction is applied at the syntactic level -- either
by supplying additional paragraphs, or by adjusting the (Unisys MCP/AS
extension to ANSI-74 COBOL) value in the CODE SEGMENT-LIMIT clause in the
OBJECT-COMPUTER paragraph from its default value of 1500 words, as the
manual specifies.
-Chuck Stevens
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
>
><docd...@panix.com> wrote in message news:c3f8cn$qka$1...@panix5.panix.com...
>
>I wrote:
>
>> >I have not responded to your repeated requests for an extended essay on what
>> >I regard as a syntax error in which contexts for two reasons:
>>
>> Please excuse the impoliteness of my midsentence interruption, Mr Stevens,
>> but to the best of my knowledge I have not requested an 'extended essay'
>> from you or anyone else. I have asked twice - and now ask for the third
>> and final time - whether my summary of our differences may be summarised
>> as follows:
>
>I do not feel I can do justice to the answer without a lengthy response, and
>I do not have time to compose one.
This may indeed be what you feel, Mr Stevens, but your feelings do not
constitute a single request on my part, let alone the 'repeated requests'
to which you have referred.
>
>> If my interpretation is in error then it might be courteous to supply
>> clarification. If I am correct then an acknowledgement of accuracy would
>> be appreciated.
>
>Perhaps it would have been clearer had I written "paragraph" or "program"
>instead of "statement". I do believe your interpretation of my intent is
>indeed incorrect.
>
>There is nothing inherently wrong with a single IF statement that references
>an 88-level item that generates vast quantities of code, nor is there
>anything inherently wrong with the compiler that does so.
>
>The error is in having a paragraph whose generated code (including such an
>IF statement or not) exceeds implementation limits (in this case,
>documented -- Form 8600 0296-203 page 5-4, in case you're curious), for
>which the appropriate correction is applied at the syntactic level -- either
>by supplying additional paragraphs, or by adjusting the (Unisys MCP/AS
>extension to ANSI-74 COBOL) value in the CODE SEGMENT-LIMIT clause in the
>OBJECT-COMPUTER paragraph from its default value of 1500 words, as the
>manual specifies.
'The error is in having a paragraph whose generated code... exceeds
implementation limits... for which the appropriate correction is...
syntactic.'
I read these words, Mr Stevens, and I read that the implementation limits
('in this case, documented' leaving the possibility that in other cases,
undocumented) are exceeded and 'the correction is applied at the syntactic
level'.
The implementation limits must be compensated for by syntax... the
limitation, then, is not one of the syntax but one of the implementation,
as Mr Willms stated. I have demonstrated, here, how this conclusion was
reached; if the conclusion was reached by an error in definition or logic
then, by all means, be so kind as to demonstrate.
To others reading this... I am a coder and I bristle at being told my code
contains a 'syntax error' when what the code does is cause the compiler to
'generate code which exceeds implementation limits'.
If legitimate language constructs (it seems that nobody has yet found
where it is that syntax is defined!) cause the compiler to puke... fine,
no sweat, tell me the compiler gurks and I need to correct something.
*Don't* tell my syntax is in error; to do so seems, at least to me, quite
similar to the many times I've had miserable, stinkwad, gut-crawling,
corner-office idiots blaming their inabilities on me and then tell me they
were Much Too Busy to be shown that they are wrong... not, of course, that
anyone in this exchange might be demonstrating behaviors which could be
interpreted in that manner.
DD
LX-i
>>I once saw a complaint from a user that changing the DATA DIVISION code
>>caused a Code Segment Limit syntax error in Procedure Division code. Turns
>>out the user had increased the size of a single data item from three to nine
>>characters. That data item had some 35 88-level items associated with it,
>>most of which were multi-valued, and many of which had THRU clauses. This
>>dramatically increased the object code generated for what at the source
>>level was a simple IF statement, but at the object code level required a
>>number of comparisons; the increase was sufficient to cause code segment
>>overflows in a number of places in the program. Note that this is a syntax
>>error requiring programmer correction, not a compiler error.
>
>
> I am not sure I understand the distinction you are making here, Mr
> Stevens; a 'syntax error', as I understand it, is an error in relating the
> elements of the language so that they way the elements relate are no
> longer in accord with the rules for said language. For example:
>
> PERFORM PARA-A THRU PARA-C IN ORDER GIVING RESULT-FIELD
>
> ... uses reserved words, true, but their relation is syntactically invalid
> for the COBOL language.
>
> In the situation you describe above the compiler began to generate invalid
> code based on what appears to be permitted syntax.
I haven't had any experience with the MCP side of Unisys, but the 2200
side also had a code segment limit in the '74 compiler. It's a syntax
error because there's too much syntax. :) However, on the 2200 side,
you would get the error out of the "collector" (linker) because your
I-bank (instruction bank) overlaps your D-bank (data bank).
COBOL 85 gripes if a segment is too big, and provides a keywork of
SEGCODE to tell the compiler to do segmenting as it sees fit. Also, in
COBOL 85, the segments are 262,143 4-character words, so you've got to
have a pretty hefty program to blow that limit to begin with.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ LXi...@Netscape.net ~
~ _____ / \ | ~ http://www.knology.net/~mopsmom/daniel ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ I do not read e-mail at the above address ~
~ Please see website if you wish to contact me privately ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
docd...@panix.com
LX-i <lxi...@netscape.net> wrote:
>docd...@panix.com wrote:
>>>I once saw a complaint from a user that changing the DATA DIVISION code
>>>caused a Code Segment Limit syntax error in Procedure Division code. Turns
>>>out the user had increased the size of a single data item from three to nine
>>>characters. That data item had some 35 88-level items associated with it,
>>>most of which were multi-valued, and many of which had THRU clauses. This
>>>dramatically increased the object code generated for what at the source
>>>level was a simple IF statement, but at the object code level required a
>>>number of comparisons; the increase was sufficient to cause code segment
>>>overflows in a number of places in the program. Note that this is a syntax
>>>error requiring programmer correction, not a compiler error.
>>
>>
>> I am not sure I understand the distinction you are making here, Mr
>> Stevens; a 'syntax error', as I understand it, is an error in relating the
>> elements of the language so that they way the elements relate are no
>> longer in accord with the rules for said language. For example:
>>
>> PERFORM PARA-A THRU PARA-C IN ORDER GIVING RESULT-FIELD
>>
>> ... uses reserved words, true, but their relation is syntactically invalid
>> for the COBOL language.
>>
>> In the situation you describe above the compiler began to generate invalid
>> code based on what appears to be permitted syntax.
>
>I haven't had any experience with the MCP side of Unisys, but the 2200
>side also had a code segment limit in the '74 compiler. It's a syntax
>error because there's too much syntax. :)
I see... and who is it who says there is 'too much syntax'?
DD
LX-i
>>>In the situation you describe above the compiler began to generate invalid
>>>code based on what appears to be permitted syntax.
>>
>>I haven't had any experience with the MCP side of Unisys, but the 2200
>>side also had a code segment limit in the '74 compiler. It's a syntax
>>error because there's too much syntax. :)
>
>
> I see... and who is it who says there is 'too much syntax'?
Probably the manual (the 2200 ACOB (74) manual does, going into detail
about it in the "segmentation module" section).
I've read the rest of the thread at this point, and I can see both
sides. If the compiler documents that you can only generate xK of
instructions or data per paragraph/section/etc, and you write valid
COBOL syntax that exceeds this limit, what type of error would you call
it? (Size, maybe?)
(As an aside, I sure am glad we don't have to manually segment our
programs any more - that was a pain!)
docd...@panix.com
LX-i <lxi...@netscape.net> wrote:
>docd...@panix.com wrote:
>>>>In the situation you describe above the compiler began to generate invalid
>>>>code based on what appears to be permitted syntax.
>>>
>>>I haven't had any experience with the MCP side of Unisys, but the 2200
>>>side also had a code segment limit in the '74 compiler. It's a syntax
>>>error because there's too much syntax. :)
>>
>>
>> I see... and who is it who says there is 'too much syntax'?
>
>Probably the manual (the 2200 ACOB (74) manual does, going into detail
>about it in the "segmentation module" section).
This is, I assume, the implementation manual.
>
>I've read the rest of the thread at this point, and I can see both
>sides. If the compiler documents that you can only generate xK of
>instructions or data per paragraph/section/etc, and you write valid
>COBOL syntax that exceeds this limit, what type of error would you call
>it? (Size, maybe?)
If the code generated is beyond the compiler's capabiliies to handle then
the limitation is one of the compiler, not the code. As an analogy... it
used to be that one could not define a table of more than 32K (... or was
it 64K? I think it was 32K... but my memory is, admittedly, porous) under
the IBM mainframe compiler IKFCBL00. So...
01 BIG-TBL.
05 TBL-ITEM OCCURS 32 PIC X(1000).
... would compile, while
01 BIG-TBL.
05 TBL-ITEM OCCURS 33 PIC X(1000).
... would throw an error. My experience is, I agree, limited... but I do
not recall anyone calling this a 'syntax error', it was always a 'compiler
limit'... same thing with not being able to define an OCCURS at the 01
level. Sure, you had to change your code (or 'perform an application of
syntactic correction', as some might label such an action)... but folks
seemed to know that you had to change your code not because the syntax was
in error but because the compiler just could not deal with such things.
DD
Howard Brazee
On 20-Mar-2004, docd...@panix.com wrote:
> The implementation limits must be compensated for by syntax... the
> limitation, then, is not one of the syntax but one of the implementation,
> as Mr Willms stated. I have demonstrated, here, how this conclusion was
> reached; if the conclusion was reached by an error in definition or logic
> then, by all means, be so kind as to demonstrate.
>
> To others reading this... I am a coder and I bristle at being told my code
> contains a 'syntax error' when what the code does is cause the compiler to
> 'generate code which exceeds implementation limits'.
I agree. But this is just a term. I get irritated similarly when someone
uses terms such as "database" in a different manner that I do. Or "ten items
or less", or "hot water heater", or ... (please let's not start a thread, this
could last forever!)
It does seem as though the compiler company is doing a cop-out, blaming the
programmer for the compiler's limitations.
Chuck Stevens
<docd...@panix.com> wrote in message news:c3mppr$f9q$1...@panix5.panix.com...
> If the code generated is beyond the compiler's capabiliies to handle then
> the limitation is one of the compiler, not the code. As an analogy... it
> used to be that one could not define a table of more than 32K (... or was
> it 64K? I think it was 32K... but my memory is, admittedly, porous) under
> the IBM mainframe compiler IKFCBL00. So...
>
> 01 BIG-TBL.
> 05 TBL-ITEM OCCURS 32 PIC X(1000).
>
> ... would compile, while
>
> 01 BIG-TBL.
> 05 TBL-ITEM OCCURS 33 PIC X(1000).
>
> ... would throw an error. My experience is, I agree, limited... but I do
> not recall anyone calling this a 'syntax error', it was always a 'compiler
> limit'... same thing with not being able to define an OCCURS at the 01
> level. Sure, you had to change your code (or 'perform an application of
> syntactic correction', as some might label such an action)... but folks
> seemed to know that you had to change your code not because the syntax was
> in error but because the compiler just could not deal with such things.
From the viewpoint of the user in the Unisys MCP/AS world -- because it's
reported that way to the user by the operating system -- a "syntax error" is
any error that causes *any* compiler to report to the operating system, and
ultimately to the user, that the compilation terminated as a "SNTX"
termination. This is allowed only for processes established a priori as
compilations by the operating system. That includes limits errors,
violations of ANSI standards, references to undefined variables in languages
other than FORTRAN, redefinition of field attributes in the C-specs of RPG,
errors reported back through various compilers from the DMSII data base
declaration or access-parsing software, and yes, even cases like "A compiler
error has occurred. Please contact your support organization." as issued by
the COBOL74 compiler and a whole passel of similar ones potentially issued
by RPG. So long as the compiler is capable of detecting the error *and
continuing*, the error is reported as a syntax error.
In this context, the only cases that are reported as "compiler errors" in
the strict sense are those in which the compiler has detected a situation
*it* views as impossible, almost always indicative of an undected logic
error encountered previously in the compilation. In such cases, the
compiler continues to attempt to parse the remainder of the program so that
the user can get as much benefit from the compilation as possible.
All of these types of errors will generally result in the compiler
*terminating gracefully* after having examined the entire source file (and
at least going through the motions of generating code even after the
detection of such problems.
If the user specifies through directives that *warnings* should also be
treated as syntax errors, the compiler will oblige; ordinarily things like
"Four bits of filler have been added here so that all alphanumeric,
word-oriented and group items begin on a character boundary." as issued
during the parsing of the Data Division are treated as advisory.
"Syntax errors" are in direct contrast to indexing errors, arithmetic
faults, invalid operands encountered by the object code sequences within the
compiler, and such like, which result in the immediate, fatal and premature
termination of the compilation process. Fault terminations are reported
back to the user as one or another form of "DS" termination, as would be a
manual "DS" of the compilation by the end user or by an operator. As I
understand it, "DS" stands for "Discontinue Service"; the mnemonic dates
back at least to Burroughs B5000 days, and I can't verify its history
further back than that. When such a fault occurs, the compiler stops
*right then*, and may or may not give the user any indication of which
statement or construct it was that caused the compiler to encounter this
*program fault*.
Compilations that encounter no execution-time faults or syntax errors
(whether or not they encounter warnings that haven't been turned into errors
at user request) are deemed to have successfully reached end-of-task
("EOT").
Thus, in the Unisys MCP/AS community, there are syntax errors; there are
irrecoverable program faults encountered during compilation, and there are
successful compilations. Those have been the choices for not much less than
a half-century of Burroughs Large System and Unisys ClearPath systems;
whether the decisions made by Burroughs Corporation in the late 1950's and
very early 1960's are strictly semantically accurate when viewed from the
mindset of a linguist or of users of other equipment using different
conventions must be weighed against what existing users of the equipment
have been led to expect.
Given that my employers expect me to resolve genuine problems encountered by
genuine licensed users of Unisys hardware and software products, as well as
to prepare for a meeting that will take me out of the office all next week,
I think I've devoted enough time and energy to this topic. This response
will have to suffice, whether deemed adequate or not.
-Chuck Stevens
docd...@panix.com
Chuck Stevens <charles...@unisys.com> wrote:
>
><docd...@panix.com> wrote in message news:c3mppr$f9q$1...@panix5.panix.com...
>
>> If the code generated is beyond the compiler's capabiliies to handle then
>> the limitation is one of the compiler, not the code. As an analogy... it
>> used to be that one could not define a table of more than 32K (... or was
>> it 64K? I think it was 32K... but my memory is, admittedly, porous) under
>> the IBM mainframe compiler IKFCBL00. So...
>>
>> 01 BIG-TBL.
>> 05 TBL-ITEM OCCURS 32 PIC X(1000).
>>
>> ... would compile, while
>>
>> 01 BIG-TBL.
>> 05 TBL-ITEM OCCURS 33 PIC X(1000).
>>
>> ... would throw an error. My experience is, I agree, limited... but I do
>> not recall anyone calling this a 'syntax error', it was always a 'compiler
>> limit'... same thing with not being able to define an OCCURS at the 01
>> level. Sure, you had to change your code (or 'perform an application of
>> syntactic correction', as some might label such an action)... but folks
>> seemed to know that you had to change your code not because the syntax was
>> in error but because the compiler just could not deal with such things.
>
>From the viewpoint of the user in the Unisys MCP/AS world -- because it's
>reported that way to the user by the operating system -- a "syntax error" is
>any error that causes *any* compiler to report to the operating system, and
>ultimately to the user, that the compilation terminated as a "SNTX"
>termination.
So... because the compiler says the syntax is in error then... it *must*
be because the syntax is in error, not because the compiler is unable -
documented or not - to generate code.
And why is the syntax said to be 'in error', even if it agrees with the
Standard? The syntax is said to be in error, it seems... because the
compiler says so, not any other sort of language-defining corpus.
>This is allowed only for processes established a priori as
>compilations by the operating system. That includes limits errors,
>violations of ANSI standards, references to undefined variables in languages
>other than FORTRAN, redefinition of field attributes in the C-specs of RPG,
>errors reported back through various compilers from the DMSII data base
>declaration or access-parsing software, and yes, even cases like "A compiler
>error has occurred. Please contact your support organization." as issued by
>the COBOL74 compiler and a whole passel of similar ones potentially issued
>by RPG. So long as the compiler is capable of detecting the error *and
>continuing*, the error is reported as a syntax error.
Thanks for clearing this up... '(s)o long as the compiler is capable of
detecting the error *and continuing*, (emphasis original) the error is
reported as a syntax error.'
Not 'so long as the compiler is capable of determining what the cause of
the error is', as long as it can keep going... syntax is blamed.
Programmers are responsible for the syntax of the statements they write,
last I looked.
[snip]
>Thus, in the Unisys MCP/AS community, there are syntax errors; there are
>irrecoverable program faults encountered during compilation, and there are
>successful compilations. Those have been the choices for not much less than
>a half-century of Burroughs Large System and Unisys ClearPath systems;
>whether the decisions made by Burroughs Corporation in the late 1950's and
>very early 1960's are strictly semantically accurate when viewed from the
>mindset of a linguist or of users of other equipment using different
>conventions must be weighed against what existing users of the equipment
>have been led to expect.
If someone can be sold the expectation that a compiler will tell you
'syntax error' instead of 'I can't deal with the code I generate from
this' then they deserve what they have purchased... and when someone
refers to a Long and Respected History I am usually reminded of Rear
Admiral Grace Murray Hopper - may she sleep with the angels! - saying
something along the lines of "the most damaging phrase in the language is
`We've always done it this way.'"
>
>Given that my employers expect me to resolve genuine problems encountered by
>genuine licensed users of Unisys hardware and software products, as well as
>to prepare for a meeting that will take me out of the office all next week,
>I think I've devoted enough time and energy to this topic. This response
>will have to suffice, whether deemed adequate or not.
How exquisitely generous of you, Mr Stevens, to have deemed the poor words
I've posted worthy of any response at all.
DD
Joe Zitzelberger
If the compiler can detect that some source code has generated object
code that will exceed the segment limits.
And the normal fix is for the programmer to insert some unreferenced
labels in the middle of the offending source code.
But the compiler, which can detect the error, does not assume some
unreferenced labels in the middle of the segments and keep on trucking?
Even the blondest among us would wonder about the manufacturer that
tried to pass this one off on its customers. (regardless of
syntax-error/compiler-error labeling)
In article <c3nav9$ef$1...@si05.rsvl.unisys.com>,
"Chuck Stevens" <charles...@unisys.com> wrote:
Chuck Stevens
news:joe_zitzelberger-EE...@corp.supernews.com...
> Just my not so humble $0.02...
>
> If the compiler can detect that some source code has generated object
> code that will exceed the segment limits.
>
> And the normal fix is for the programmer to insert some unreferenced
> labels in the middle of the offending source code.
>
> But the compiler, which can detect the error, does not assume some
> unreferenced labels in the middle of the segments and keep on trucking?
>
> Even the blondest among us would wonder about the manufacturer that
> tried to pass this one off on its customers. (regardless of
> syntax-error/compiler-error labeling)
Rememer that Unisys MCP/AS object code segments are *never* loaded into
memory until such time as control is passed to them, and the memory space is
eligible to be marked as absent and reused by the memory management scheme
at any point so long as it is not actively being executed. Transfer of
control from one segment to another may be relatively fast and it may not,
dependent on whether the destination code segment happens to be resident in
memory or not. And the user has little control, particularly on a
limited-memory system, as to whether that code segment will be resident at
any given moment.
Thus, the reason the COBOL74 compiler doesn't do the equivalent of inserting
a label is that the implementor is unwilling to assume that the
silently-inserted label (and the object code associated with it that is
required to transfer control from one object code segment -- resident in
memory or not -- to another) does not, or cannot, occur in the middle of a
time-critical routine, thereby degrading performance of that routine to an
unacceptable level.
Either you give the user control over whether (carefully-written
user-optimized or not) code (carefully-written user-optimized or not) is
indeed efficient -- by giving the user control over whether a "silent"
inter-segment transfer is permitted to occur.
As it happens, I have no problem with allowing both schemata in the same
compiler. Unfortunately, providing the user such a choice -- ignore
paragraphs and sections entirely for purposes of code segmentation, or
segment at section and sometimes paragraph boundaries in the Procedure
Division -- at compile time is not an option for the COBOL74 compiler
because such significant new features are not being considered for it. Such
an option is actively being discussed for COBOL85.
A side note: while "segmentation" is a fully-supported and undeprecated
module of ANSI X3.23-1974, it is marked obsolete in ANSI X3.23-1985 and is
absent from ISO/IEC 1989:2002. As I see it, the primary "pecularity" in the
segmentation module is the distinction between the impact of ALTER on
SECTIONs with numbers less than 50 and its impact on SECTIONs with larger
section numbers, and ALTER is also obsolete in ANSI X3.23-1985 and absent
from ISO/IEC 1989:2002 (and has arguably been deprecated even longer than
the segmentation module itself).
The distinction between "fixed" and "overlayable" segments that is discussed
at length in ANSI X3.23-1974 does not actually describe a physical
difference among MCP/AS object code segment types. In general *all* user
code segments are overlayable, and the COBOL74 distinction between "fixed"
and "overlayable" must be made by differences in the object code and in
control information associated with ALTER and GO TO. Some compilers
generate code for ALTER to "step on" the branch instruction associated with
the destinationless GO TO (and to restore the branch on entry for each
overlayable segment); Unisys MCP/AS compilers are not among them.
-Chuck Stevens
Chuck Stevens
<Either you give the user control over whether (carefully-written
user-optimized or not) code (carefully-written user-optimized or not) is
indeed efficient -- by giving the user control over whether a "silent"
inter-segment transfer is permitted to occur. >
More clearly:
Either you give the user control over whether (carefully-written
user-optimized or not) code is indeed efficient -- by giving the user the
ability to prohibit a "silent" inter-segment transfer is permitted to occur
inside that piece of code -- or you don't. Unisys MCP/AS COBOL74, if it
errs in this regard, errs on the side of giving the user greater control
over the efficiency of his program at the expense of the possibility that if
the user fails to exercize that option appropriately the result *can* (under
very limited circumstances) be an uncompilable program.
-Chuck Stevens
Howard Brazee
On 23-Mar-2004, "Chuck Stevens" <charles...@unisys.com> wrote:
> Thus, the reason the COBOL74 compiler doesn't do the equivalent of inserting
> a label is that the implementor is unwilling to assume that the
> silently-inserted label (and the object code associated with it that is
> required to transfer control from one object code segment -- resident in
> memory or not -- to another) does not, or cannot, occur in the middle of a
> time-critical routine, thereby degrading performance of that routine to an
> unacceptable level.
So it chooses to abort or disallow the code instead?
Dumb.
But no dumber than the ANSI 74 practice on IBM mainframes of sticking filler
tables behind tables that are too small to do the job (getting around a similar
compiler limitation).
I wish CoBOL had a USAGE mode that allowed for unlimited number size. Sure we
know it's inefficient - but the compiler could handle it anyway.
Chuck Stevens
"Howard Brazee" <how...@brazee.net> wrote in message
news:c3q0e4$r4p$1...@peabody.colorado.edu...
>
> On 23-Mar-2004, "Chuck Stevens" <charles...@unisys.com> wrote:
>
> > Thus, the reason the COBOL74 compiler doesn't do the equivalent of
inserting
> > a label is that the implementor is unwilling to assume that the
> > silently-inserted label (and the object code associated with it that is
> > required to transfer control from one object code segment -- resident in
> > memory or not -- to another) does not, or cannot, occur in the middle of
a
> > time-critical routine, thereby degrading performance of that routine to
an
> > unacceptable level.
>
> So it chooses to abort or disallow the code instead?
It informs the user, at compile time, that the current object code segment
has exceeded architectural limits. The programmer has the option of adding
paragraphs, changing the default segment size at which the compiler seeks to
start a new code segment, or both. But never, never does the COBOL74
compiler decide that it's OK to stick a code segment break in the middle of
any statement, or even between any two statements.
> Dumb.
You may think so. But it is my experience that users who have historically
used COBOL to drive devices like check reader-sorters at full smoke (or do
other performance- or time-critical tasks) are not at all pleased when the
compiler decides to stick a segment transfer (and the potential for a code
segment overlay) in the middle of what the user deems extremely
critical-path code. They'd rather have their hand slapped so that they know
they need to do something to their program. The ones that have no control
over where the compiler segments code *can't* fix their programs.
> I wish CoBOL had a USAGE mode that allowed for unlimited number size.
Unisys MCP/AS provides 23 digits of precision in arithmetic. ISO/IEC
1989:2002 mandates 32 digits for standard arithmetic. I believe at least
the earliest Burroughs Medium System provided hardware support for
arithmetic on (packed or display) items of up to 100 digits or even more,
though as I recall later ones didn't handle arithmetic on extremely large
items because field experience demonstrated insufficient customer demand for
this feature. MCP/AS COBOL85 allows manipulation of (though I grant not
arithmetic directly on) very, very large COMP (=PACKED-DECIMAL) items (I
just played with numeric MOVEs to a 6000-digit COMP destination).
How many digits have you found that you actually need in practice?
-Chuck Stevens
docd...@panix.com
Howard Brazee <how...@brazee.net> wrote:
[snip]
>But no dumber than the ANSI 74 practice on IBM mainframes of sticking filler
>tables behind tables that are too small to do the job (getting around a similar
>compiler limitation).
Speaking as one who coded just such a thing (you know... one of those
'it's blowing up and we have 15 minutes before the evening cycle' sort of
thing, there's always enough time to do it over but never enough time to
do it right)... one did what one did and Prod kept running.
(Curious, though, to compare an... 'oddity' in a compiler with the tricks
users employed to get around such 'oddities'.)
DD
Joe Zitzelberger
"Chuck Stevens" <charles...@unisys.com> wrote:
Still, if a user is working at the Cobol level, they have already
indicated a lack of concern with how the object code is going to be
generated. That is the compilers job.
If they want to build segments exactly the way they want them, wouldn't
they use an assembler?
William M. Klein
I guess I see the two situations as identical.
With OS/VS COBOL,
If you coded a table greater than 32K, you received a compile-time (I would
call syntax) error. (The error was listed when you compiled ERRMSG - so I
consider those syntax errors). A programmer than could "add" a dummy 01-level
after the table and "treat" it as part of the original table.
With the Unisys '74 compiler (as I understand it),
If the programmer coded a single paragraph that was too large, they would
receive a compile-time message. The programmer could then add a "dummy" (never
referenced) paragraph name.
***
What is the difference between these two errors-followed-by-programmer-change
that you see.
--
Bill Klein
wmklein <at> ix.netcom.com
<docd...@panix.com> wrote in message news:c3qqe1$5lo$1...@panix1.panix.com...
berl...@sympatico.ca
>I see... and who is it who says there is 'too much syntax'?
Sorry to interrupt yer who's who's, old canopy, but it seems glitchy
chips are now imbedded goes knows where.
Proving once again my superior farsighting on this and other matters
so as this sad ass group has lost a visionnary, a wit and a fine story
teller.
Pity, reallly!
GM to Fix 'Leap Year' Software Glitch in Pontiac
Y2K+4] American car manufacturers forget to program cars to compensate
for Leap Year
GM to Fix 'Leap Year' Software Glitch in Pontiac
Mar 22, 12:17 pm ET
DETROIT (Reuters) - What day is it? Don't ask the driver of General
Motors Corp.'s Pontiac Grand Prix.
Due to a software glitch, the computer display in the 2004 model year
Grand Prix shows the wrong day of the week, Pontiac spokesman Jim
Hopson said on Monday. Engineers overlooked the fact that 2004 is a
leap year, with an extra day,
"Somehow or other, the fact that this was a leap year got missed,"
Hopson said. "We are working on a solution."
GM may be able to fix the problem by resetting the software. A more
costly solution could include replacing the display unit, he said.
The redesigned Grand Prix went on sale last March, and all models
since then could potentially be affected by the glitch, Hopson said.
Despite studies showing improved quality and durability, GM has been
hit by a high number of vehicle recalls this year. Last week, GM said
it would recall more than 4 million full-size pickup trucks to replace
tailgate support cables that may corrode and fracture.
docd...@panix.com
William M. Klein <wmk...@nospam.netcom.com> wrote:
>Doc,
> I guess I see the two situations as identical.
>
>With OS/VS COBOL,
> If you coded a table greater than 32K, you received a compile-time (I would
>call syntax) error. (The error was listed when you compiled ERRMSG - so I
>consider those syntax errors).
Mr Klein, does the ERRMSG option allow syntax errors and only syntax
errors to be displayed? When I've gotten such errors my response has been
'Oh, this compiler won't let me do that... like it won't let me put an
OCCURS at an 01-level; I'll have to code something to get around the
compiler limitations.'
Nobody I worked with ever said 'Your syntax is in error'... then again it
might be the limitations of my experience. As I've mentioned before I
thought that syntax was defined in the Standard and versions of syntax
were implemented by compiler-manufacturers; if I'm wrong in this then I'd
appreciate knowing where the rules for syntax exist.
>A programmer than could "add" a dummy 01-level
>after the table and "treat" it as part of the original table.
>
>With the Unisys '74 compiler (as I understand it),
> If the programmer coded a single paragraph that was too large, they would
>receive a compile-time message. The programmer could then add a "dummy" (never
>referenced) paragraph name.
>
> ***
>
>What is the difference between these two errors-followed-by-programmer-change
>that you see.
As I understand it... for the examples of the oversized table or the
01-level OCCURS it is possible to look at the code, pre-compilation, and
see, clearly and unambiguously, where the code is going to make the
compiler choke; you can know what it is you wrote that is not acceptable
to that particular compiler.
In the example Mr Stevens gave which started this curious exchange (the
changing of a data-item's size) there is no way I can see to know what
kind of object code the compiler is going to make without 'playing
compiler' (similar to an exercise my class was given, e'er-so-long ago,
when the instructor said 'Here are some Assembley instructions... generate
the Sys360 machine code').
DD
William M. Klein
> 01-level OCCURS it is possible to look at the code, pre-compilation, and
> see, clearly and unambiguously, where the code is going to make the
> compiler choke; you can know what it is you wrote that is not acceptable
> to that particular compiler.
Well, yes and no (as usual). The compiler can "insert" slack bytes and can do
other "oddities" that mean that JUST "adding" the PICTURE clause symbols
together (paying attention to USAGES) does *not* necessarily tell the programmer
how large the actual data area will be. (If you read all the rules, you might
be able to figure this out - but certainly not "obviously" and adding a data
item in the middle can EASILY impact slack bytes later on.)
Although this may be different in "degree" from figuring out how many bytes
(words?) a Unisys compiler will need for specific object code created for source
code statements - I do see that as only a difference in degree, not kind.
I think (back to where this part of the thread started out) that the "best"
answer to the underlying question of what is "syntax" - or what is a "syntax
error" is
It is EXACTLY what the compiler vendor tells you it is.
Possibly not a "desirable" answer, but I just don't think there is any better
one.
***
FYI - I once tried to tie down the Standards committees on a "similar" issue.
The '85 Standard required that a vendor provide a flagging message for
"extension" to standard COBOL.
IBM (to name the vendor that caused me to ask the quesiton) had some "features"
where the compiler accepted certain code but
A) didn't document it as valid in their documentation
B) did NOT flag it as an extension at compile time (although it was definitely
non-Standard)
but
C) "implied" that they would never remove the compiler support for it
I asked the standards committees if this made the compiler "non-conforming".
The answer came back that the vendor (and ONLY the vendor) could tell if
something was or was not an "extension" that was supported by their compiler.
Just because the compiler actually ACCEPTED the code, did not mean that it was a
"supported" extension that they were required to flag.
So the bottom-line was that "extensions" are exactly what (and no more than) the
compiler vendor SAYS they are.
which brings me back to the definition of syntax (given above).
docd...@panix.com
>> 01-level OCCURS it is possible to look at the code, pre-compilation, and
>> see, clearly and unambiguously, where the code is going to make the
>> compiler choke; you can know what it is you wrote that is not acceptable
>> to that particular compiler.
>
>Well, yes and no (as usual). The compiler can "insert" slack bytes and can do
>other "oddities" that mean that JUST "adding" the PICTURE clause symbols
>together (paying attention to USAGES) does *not* necessarily tell the programmer
>how large the actual data area will be.
Mr Klein, what the compiler 'can do' is not necessarily what the compiler
'does'; in the examples given (the oversized table/01-level OCCURS)
nothing along the lines of what you propose appears to happen.
>(If you read all the rules, you might
>be able to figure this out - but certainly not "obviously" and adding a data
>item in the middle can EASILY impact slack bytes later on.)
I know of no instance, Mr Klein, where a table reached the 32K limit based
on anything other than arithmetic addition of defined data-items; if an
example could be provided it might be most instructive.
(Insofar as anything demonstrating the limits of a decades-old compiler
which is no longer supported can be 'most instructive'... but hey, what is
Pure Research about, anyhow?)
>
>Although this may be different in "degree" from figuring out how many bytes
>(words?) a Unisys compiler will need for specific object code created for source
>code statements - I do see that as only a difference in degree, not kind.
An example might support this interpretation, certainly.
>
>I think (back to where this part of the thread started out) that the "best"
>answer to the underlying question of what is "syntax" - or what is a "syntax
>error" is
>
>It is EXACTLY what the compiler vendor tells you it is.
Hmmmmm... permit me to propose a bit of logic, then:
An error in syntax is compiler-dependent.
Compilers vary by vendor, there is no standard compiler.
Syntax validity varies by compiler.
COBOL does not have a standard syntax.
>
>Possibly not a "desirable" answer, but I just don't think there is any better
>one.
It is a delighful oddity, Mr Klein, to be able to conclude that COBOL does
not have a standard syntax... but based on your assertions it appears to
be a valid and unescapable conclusion.
>
> ***
>
>FYI - I once tried to tie down the Standards committees on a "similar" issue.
>The '85 Standard required that a vendor provide a flagging message for
>"extension" to standard COBOL.
>
>IBM (to name the vendor that caused me to ask the quesiton) had some "features"
>where the compiler accepted certain code but
> A) didn't document it as valid in their documentation
> B) did NOT flag it as an extension at compile time (although it was definitely
>non-Standard)
> but
> C) "implied" that they would never remove the compiler support for it
>
>I asked the standards committees if this made the compiler "non-conforming".
>The answer came back that the vendor (and ONLY the vendor) could tell if
>something was or was not an "extension" that was supported by their compiler.
>Just because the compiler actually ACCEPTED the code, did not mean that it was a
>"supported" extension that they were required to flag.
>
>So the bottom-line was that "extensions" are exactly what (and no more than) the
>compiler vendor SAYS they are.
>
>which brings me back to the definition of syntax (given above).
I'm not quite sure what is going on here, Mr Klein... are you saying that
the Standards Committee cannot say what 'standard' syntax is but that it
can say what 'extended' syntax is? This seems perilously close to 'I
don't know what Art is but I know what I like.'
To my simple coder's mind it is rather binary: either there is a standard
syntax or there is not. If there is a standard syntax then anything which
is at variance with it is a syntax error (whether the compiler-vendor
chooses to allow for this variance as an 'extension' is another matter).
If there is no standard syntax... well, then it might be similar to
Dostoevsky's having Ivan conclude (The Brothers Karamazov) that 'all is
permitted'.
Is the abyss starting to stare back yet?
DD
Howard Brazee
On 23-Mar-2004, "Chuck Stevens" <charles...@unisys.com> wrote:
> How many digits have you found that you actually need in practice?
It's not a pressing need. There are ways around, say, calculating pi to 24,000
places. It is more of an intellectual desire than a practical one.
Howard Brazee
On 23-Mar-2004, "William M. Klein" <wmk...@nospam.netcom.com> wrote:
> What is the difference between these two errors-followed-by-programmer-change
> that you see.
That's why I said " but no dumber than...".
Both were dumb compiler implantation limitations to a language that shouldn't
have them.
Chuck Stevens
> Still, if a user is working at the Cobol level, they have already
> indicated a lack of concern with how the object code is going to be
> generated.
How so? What would you suggest as an alternative?
> That is the compilers job.
I disagree. It's the user's job to know what the compiler does, and it's
the user's job to have some inkling of the architecture of the system on
which his programs are expected to run.
> If they want to build segments exactly the way they want them, wouldn't
> they use an assembler?
I thought everybody knew this. Neither Burroughs, for the B5000 or the
B5/6/7000 series or the A Series, nor Unisys in the ClearPath HMP LX/IX line
and the current ClearPathPlus line, has *ever* had, or seen the need to
provide, an assembler for that system. The *last* assembler I'm aware of
that related to this architecture was the assembler that ran on (I think it
was a) B263, in which an ALGOL cross-compiler producing B5000 object code
was written. That assembler-based ALGOL compiler was used to compile an
ALGOL compiler written in ALGOL running under a B5000 simulation program on
a Philco 2000, and by the time the first B5000 hardware actually existed the
ALGOL compiler written in ALGOL had been used to compile itself using three
generations of ALGOL-based object code. *All* programs in this architecture
(including *all* system software without exception, and that includes all
the compilers) are written in higher-level languages.
If you want to write an assembler, and support it, and market it to the
MCP/AS community, you're welcome to try. The operator set, while large, is
straightforward enough and well-documented. But I think most of our users
find the higher-level languages supported by Unisys adequate to solving
their problems and would be disinclined to depend on an outside supplier for
something as integrated into the system's security as language compilers.
-Chuck Stevens
Chuck Stevens
news:nJd8c.54536$aT1....@newsread1.news.pas.earthlink.net...
> Although this may be different in "degree" from figuring out how many
bytes
> (words?) a Unisys compiler will need for specific object code created for
source
> code statements - I do see that as only a difference in degree, not kind.
If the user requests (or receives by default) a compilation listing from the
MCP/AS COBOL74 compiler, that listing includes by default the hexadecimal
representation of the object code address (segment, word displacement within
segment, and syllable displacement within word) at which each Procedure
Division statement begins. It is not difficult to tell with a mere glance
at the compilation listing that the word portion of that address is
approaching its system-architectural limit of 7FFF.
> It is EXACTLY what the compiler vendor tells you it is.
I agree, and in the case of Unisys MCP/AS systems I'd go one step beyond
that and reiterate that what a syntax error is may actually be a function of
the "operating environment", excluding the compiler. Some of our compilers
(particularly more recent one) actually "trap" arithmetic or logic faults
that occur during compilation, and treat *them* as syntax errors; COBOL74
happens not to include that feature.
> FYI - I once tried to tie down the Standards committees on a "similar"
issue.
> The '85 Standard required that a vendor provide a flagging message for
> "extension" to standard COBOL.
>
> IBM (to name the vendor that caused me to ask the quesiton) had some
"features"
> where the compiler accepted certain code but
> A) didn't document it as valid in their documentation
> B) did NOT flag it as an extension at compile time (although it was
definitely
> non-Standard)
> but
> C) "implied" that they would never remove the compiler support for it
This sounds like an "undocumented feature". In various languages and
various compilers over the years, we've had some of those. The manual
doesn't talk about it, we're not planning to document it, and we really
don't want to support it -- but we're not planning to change the way it
works, and any user who happens to stumble across it and ask us about it can
be told that it should continue to work.
In our COBOL compilers, unless the user jumps through some hoops, the
"flagging" options produce warnings, not syntax errors, by default anyway.
The user must request that these messages be treated as errors, if that is
his desire.
-Chuck Stevens
William M. Klein
Try the following with any IBM COBOL compiler and check your "data map"
01 LARGE-TABLE.
05 EACH-ENTRY OCCURS 10 TIMES.
05 ONE-BYTE PIC X.
05 DOUBLE-FLOAT COMP-2 SYNC.
A programmer might WELL think that LARGE-TABLE will be 90 bytes long (10 x 9).
However, you will find that it is MUCH larger than that. I think you would
agree that you could get to 32K much faster than expected!!!
(COMP-2 isn't all that common, but SYNC with any of a number of other usages
provides "slack bytes")
--
Bill Klein
wmklein <at> ix.netcom.com
<docd...@panix.com> wrote in message news:c3rvv6$ku9$1...@panix5.panix.com...
William M. Klein
01 LARGE-TABLE.
05 EACH-ENTRY OCCURS 10 TIMES.
10 ONE-BYTE PIC X.
10 DOUBLE-FLOAT COMP-2 SYNC.
--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:Bvm8c.55027$aT1....@newsread1.news.pas.earthlink.net...
berl...@sympatico.ca
Even the bests have senior moments.
docd...@panix.com
William M. Klein <wmk...@nospam.netcom.com> wrote:
>Oops change my level-numbers. That should have been
>
> 01 LARGE-TABLE.
> 05 EACH-ENTRY OCCURS 10 TIMES.
> 10 ONE-BYTE PIC X.
> 10 DOUBLE-FLOAT COMP-2 SYNC.
I'll get to compiling this - and its variants - on the morrow, Mr Klein.
Meanwhile I'd ask that you address the following:
An error in syntax is compiler-dependent.
Compilers vary by vendor, there is no standard compiler.
Syntax validity varies by compiler.
COBOL does not have a standard syntax.
... for any flaws you see in definitions or logic.
DD
LX-i
> I thought everybody knew this. Neither Burroughs, for the B5000 or the
> B5/6/7000 series or the A Series, nor Unisys in the ClearPath HMP LX/IX line
> and the current ClearPathPlus line, has *ever* had, or seen the need to
> provide, an assembler for that system.
The 2200/IX has an assembler called MASM - I've written a little of it.
It's a Unisys product.
William M. Klein
"3.2 A conforming compilation group
A conforming compilation group is one that does not violate the explicitly
stated syntactic provisions and specifications of standard COBOL. In order for a
compilation group to conform to standard COBOL, it shall not include any
language elements not specified in this International Standard. A compilation
group that uses elements that are optional, processor-dependent, or
implementor-defined in this International Standard is a conforming compilation."
what this does NOT say is that a compiler may not flag as a "syntax error"
anything ELSE that it wants - as long as it DOES compile those things thare are
defined in the Standard itself. "Limits" (as stated elsewhere) are NOT
specified (for most things) in the Standard. This is true of how big a
working-storage item may be and is (IMHO) equally true of how big (object code)
a paragraph may be.
--
Bill Klein
wmklein <at> ix.netcom.com
<docd...@panix.com> wrote in message news:c3tft6$235$1...@panix1.panix.com...
docd...@panix.com
William M. Klein <wmk...@nospam.netcom.com> wrote:
>The following is what the 2002 Standard says (that I think is relevant),
>
>"3.2 A conforming compilation group
>A conforming compilation group is one that does not violate the explicitly
>stated syntactic provisions and specifications of standard COBOL. In order for a
>compilation group to conform to standard COBOL, it shall not include any
>language elements not specified in this International Standard. A compilation
>group that uses elements that are optional, processor-dependent, or
>implementor-defined in this International Standard is a conforming compilation."
>
>what this does NOT say is that a compiler may not flag as a "syntax error"
>anything ELSE that it wants - as long as it DOES compile those things thare are
>defined in the Standard itself.
Interesting use of a multiple negative there, Mr Klein... but what it
*does* say is a 'conforming compilation group... does not violate the
explicitly stated syntactic provisions and specifications of standard
COBOL.'
That is the nub, Mr Klein... this 'standard COBOL'. Where was 'standard
COBOL syntactic provisions' (as referred to in the 2002 Standard)
specified in 1974?
DD
William M. Klein
they were "closer" there).
FYI,
There *are* (and always have been - as far as I know)
"Syntax Rules" and "General Rules" (as well as "General Formats") in the
ANSI/ISO Standards.
It would seem to me that "Syntax Rules" *and* "General Formats" were IMPLICITLY
considered "syntax provisions". However, they weren't ALL the "syntactic
provisions" in earlier Standards - anymore than they are in the 2002 Standard.
And *none* of this (again) places any restraints on what OTHER "syntactic
provisions" a vendor could add - and still be Standard conforming.
--
Bill Klein
wmklein <at> ix.netcom.com
<docd...@panix.com> wrote in message news:c3ubtu$jch$1...@panix1.panix.com...
docd...@panix.com
William M. Klein <wmk...@nospam.netcom.com> wrote:
>They weren't. They weren't even specified in the '85 Standard (although I think
>they were "closer" there).
I see... so these 'standard syntactic provisions' are aspects of a later
Standard.
>
>FYI,
> There *are* (and always have been - as far as I know)
>
> "Syntax Rules" and "General Rules" (as well as "General Formats") in the
>ANSI/ISO Standards.
Now I am confused, Mr Klein. If the Standard provides Syntax Rules and a
given chunk o' code complies with these Rules then a compiler which flags
syntax errors in this code must be flagging according to non-Standard
syntax... in other words, saying that the code is syntactically incorrect
when according to Standard it is.
This was my original concern.
DD
Carl Benton
>Chuck Stevens wrote:
>> I thought everybody knew this. Neither Burroughs, for the B5000 or the
>> B5/6/7000 series or the A Series, nor Unisys in the ClearPath HMP LX/IX line
>> and the current ClearPathPlus line, has *ever* had, or seen the need to
>> provide, an assembler for that system.
>
>The 2200/IX has an assembler called MASM - I've written a little of it.
> It's a Unisys product.
No its not. Its A Sperry System acquired by Unisys after the merger
Chuck Stevens
instantiations of the ClearPathPlus. Unisys has never supported or provided
an assembler for these products.
I heard once that somebody at a university wrote an assembler for the
Burroughs B6700. But one of the benefits of having higher-level languages
in combination with forced periodic recompilation is that it means the
development of new methodologies (e.g., the introduction of the CREL and
LODC operators to replace sequences using CxxD and ONE, SISO) can be
entirely transparent to the programmer. While all you have to do for a
COBOL, ALGOL, RPG, NEWP, SORT, Pascal, FORTRAN program to account for such a
change is recompile it, you must *revise* the assembler program if it uses
the deprecated sequence.
-Chuck Stevens
"LX-i" <lxi...@netscape.net> wrote in message
news:1064i85...@corp.supernews.com...
Rick Smith
<docd...@panix.com> wrote in message news:c3ujo6$bbt$1...@panix5.panix.com...
There is an analogy, that I don't remember in its entirety, concerning
when a pitch is a strike or a ball. The third umpire, in this analogy,
states that a pitch is 'nothing until I call it'. It also follows, under the
rules for baseball, that when an umpire calls a pitch, it is exactly
what the umpire says it is regardless of any outside claims of, for
example, the visual impairment of the umpire.
When a compiler identifies a source element as having a syntax
error, it is, under the inexact rules for writing compilers, exactly
what the compiler says it is. Thus, a syntax error may be an error
in syntax that violates the rules of standard COBOLor extensions
to standard COBOL; it may be missing source elements, compiler
limitations, etc. This is true regardless of any claims of, for example,
absurdity.
I do not find fault in your logic. Instead I find that the domain for
defining 'syntax error' is the compiler -- not the standard, where your
analysis would appear to place the domain. Or, perhaps I find a
fault of including two domains as if they were one. <g>
In other words, the standard establishes criteria that must be used
to define a set of syntax errors; but the compiler (writer) is not limited
to only that set and, therefore, may extend the definition of syntax
error to include other criteria and do so without violating the standard.
In this case, the domain of the compiler includes the domain of the
standard; but the compiler is not dominated by the standard. If that
makes sense!
William M. Klein
<snip >
> >FYI,
> > There *are* (and always have been - as far as I know)
> >
> > "Syntax Rules" and "General Rules" (as well as "General Formats") in the
> >ANSI/ISO Standards.
>
> Now I am confused, Mr Klein. If the Standard provides Syntax Rules and a
> given chunk o' code complies with these Rules then a compiler which flags
> syntax errors in this code must be flagging according to non-Standard
> syntax... in other words, saying that the code is syntactically incorrect
> when according to Standard it is.
>
> This was my original concern.
>
> DD
Let's see if I can make this clearer.
1) A conforming compiler (2002) is required to flag/indicate if a source program
violates the explicit syntax specifications of the Standard. These
specifications include - but are not limited to "syntax rules" and "general
formats"
2) The '85 (and earlier) Standards did NOT include this requirement, but did
include "Syntax Rules" and "General Formats"
3) No Standard (that I know of - current or past) has LIMITED "syntax
specification" to those included in the Standard (although THOSE are a "minimum"
set of syntax specifications).
4) Every Standard (current and past) has EXPLICITLY stated that IN ADDITION to
those rules in the Standard, each implementation may place "limits" on all the
"ellipsis" type things in the Standard. (e.g. Size of alphanumeric elementary
items; number of procedure division statements supported, number of WHEN clauses
in EVALUATE; number of nestings of IF statements; etc)
5) Although the 2002 comes closer to specifying what "syntactic specifications"
are that must be "flagged/indicated" - this did NOT exist in any earlier
Standard.
***
A) Does this clear things up at all?
B) This thread has gone on longing enough, that I would like to ask, exactly
what IS your real concern? If one vendor calls something a "syntax error" and
another vendor calls the same type of thing a "compiler limitation error" but
they BOTH provide compile-time indications when it is violated, what difference
does this make to you - the programmer?
LX-i
At any rate, it's a Unisys product now... :) And they support it.
Joe Zitzelberger
ONE-BYTE, then DOUBLE-FLOAT aligned on a doubleword boundry, just like
the SYNC statement asked it to.
This example assumes that someone would use "SYNC" without knowing what
it does? Why would they ever do that?
In article <Bvm8c.55027$aT1....@newsread1.news.pas.earthlink.net>,
docd...@panix.com
Rick Smith <rick...@mfi.net> wrote:
>
><docd...@panix.com> wrote in message news:c3ujo6$bbt$1...@panix5.panix.com...
>> In article <v4z8c.9$lt...@newsread1.news.pas.earthlink.net>,
>> William M. Klein <wmk...@nospam.netcom.com> wrote:
>> >They weren't. They weren't even specified in the '85 Standard (although I think
>> >they were "closer" there).
>>
>> I see... so these 'standard syntactic provisions' are aspects of a later
>> Standard.
>>
>> >
>> >FYI,
>> > There *are* (and always have been - as far as I know)
>> >
>> > "Syntax Rules" and "General Rules" (as well as "General Formats") in the
>> >ANSI/ISO Standards.
>>
>> Now I am confused, Mr Klein. If the Standard provides Syntax Rules and a
>> given chunk o' code complies with these Rules then a compiler which flags
>> syntax errors in this code must be flagging according to non-Standard
>> syntax... in other words, saying that the code is syntactically incorrect
>> when according to Standard it is.
>>
>> This was my original concern.
>
>There is an analogy, that I don't remember in its entirety, concerning
>when a pitch is a strike or a ball. The third umpire, in this analogy,
>states that a pitch is 'nothing until I call it'. It also follows, under the
>rules for baseball, that when an umpire calls a pitch, it is exactly
>what the umpire says it is regardless of any outside claims of, for
>example, the visual impairment of the umpire.
And it likewise follows, Mr Smith, that a pantomimist falling in a forest
when there's nobody around to hear does... something. The analogy you
put forward is instructive, perhaps, but it contains the germ of the
discussion which goes on here; in this case the umpires are all charged
with implementing the Cooperstown Rules (or whatever the name of the
Baseball Standard might be).
>
>When a compiler identifies a source element as having a syntax
>error, it is, under the inexact rules for writing compilers, exactly
>what the compiler says it is.
This seems to assume that the compiler defines rules for syntax rather
than implements rules established elsewhere.
>Thus, a syntax error may be an error
>in syntax that violates the rules of standard COBOLor extensions
>to standard COBOL; it may be missing source elements, compiler
>limitations, etc. This is true regardless of any claims of, for example,
>absurdity.
'... violates the rules of standard COBOL' indicates that these rules
exist outside of the compiler's implementation.
>
>I do not find fault in your logic. Instead I find that the domain for
>defining 'syntax error' is the compiler -- not the standard, where your
>analysis would appear to place the domain. Or, perhaps I find a
>fault of including two domains as if they were one. <g>
>
>In other words, the standard establishes criteria that must be used
>to define a set of syntax errors; but the compiler (writer) is not limited
>to only that set and, therefore, may extend the definition of syntax
>error to include other criteria and do so without violating the standard.
>In this case, the domain of the compiler includes the domain of the
>standard; but the compiler is not dominated by the standard. If that
>makes sense!
It seems that you are setting the standard and the implementation to be
co-equal, that such things exist only in practise (a variation of 'ibi non
accusator, non iudex' or 'where there ain't no cop there ain't no
speed-limit'). That being the case then the conclusion appears to be that
the Standard is not a standard but... a suggestion.
DD
docd...@panix.com
><snip >
>> >FYI,
>> > There *are* (and always have been - as far as I know)
>> >
>> > "Syntax Rules" and "General Rules" (as well as "General Formats") in the
>> >ANSI/ISO Standards.
>>
>> Now I am confused, Mr Klein. If the Standard provides Syntax Rules and a
>> given chunk o' code complies with these Rules then a compiler which flags
>> syntax errors in this code must be flagging according to non-Standard
>> syntax... in other words, saying that the code is syntactically incorrect
>> when according to Standard it is.
>>
>> This was my original concern.
>>
>> DD
>
>Let's see if I can make this clearer.
>
>1) A conforming compiler (2002) is required to flag/indicate if a source program
>violates the explicit syntax specifications of the Standard. These
>specifications include - but are not limited to "syntax rules" and "general
>formats"
The above appears to state that "syntax rules" (the function of these
quotations marks is unclear to me) are a part of the Standard.
>
>2) The '85 (and earlier) Standards did NOT include this requirement, but did
>include "Syntax Rules" and "General Formats"
This also appears to state that "Syntax Rules" (the function of these
quotation marks *and* capital letters is unclear to me) are a part of the
Standard.
>
>3) No Standard (that I know of - current or past) has LIMITED "syntax
>specification" to those included in the Standard (although THOSE are a "minimum"
>set of syntax specifications).
This appears to address what are commonly called 'extensions to the
language' (the quotation marks here indicate a commonly-used phrase) which
are not, I believe, a matter of concern in this discussion if I am correct
in assuming that the matter at hand is 'what constitutes a syntax error'.
>
>4) Every Standard (current and past) has EXPLICITLY stated that IN ADDITION to
>those rules in the Standard, each implementation may place "limits" on all the
>"ellipsis" type things in the Standard. (e.g. Size of alphanumeric elementary
>items; number of procedure division statements supported, number of WHEN clauses
>in EVALUATE; number of nestings of IF statements; etc)
'(t)hose rules' in the Standard include, I believe, rules for what
constitutes valid/Standard COBOL syntax. A statement which conforms to
those rules is, by definition, syntactically correct.
>
>5) Although the 2002 comes closer to specifying what "syntactic specifications"
>are that must be "flagged/indicated" - this did NOT exist in any earlier
>Standard.
This brings things full-circle to how "syntactic specifications" differ
from "syntax rules" differ from "Syntax Rules" (all terms cited with
quotation marks and capitalisation as per original).
>
> ***
>
>A) Does this clear things up at all?
See response to 5) above.
>
>B) This thread has gone on longing enough, that I would like to ask, exactly
>what IS your real concern?
The Pursuit of Knowledge, Mr Klein; I am interested in learning how folks
can say 'Your code is in accord with the "syntactic
specifications"/"Syntax Rules"/"syntax rules" found in the Standard but
our compiler flags you for having written a syntax error' and expect to be
taken seriously.
>If one vendor calls something a "syntax error" and
>another vendor calls the same type of thing a "compiler limitation error" but
>they BOTH provide compile-time indications when it is violated, what difference
>does this make to you - the programmer?
Responsibility, Mr Klein. In both cases it will be the programmer's
responsibility to change the code, sure (after all... it's *always* the
programmer's fault, no?)... but in the case of a 'compiler limitation
error' it is clear that the necessity for the change is the compiler's
limitation.
It might be seen as a situation where a word processor would, in addition
to flagging a sentence as 'too long and in the passive voice', refuses to
allow you to save or print a document containing that sentence without
modifying it. Instead of stating that the software cannot deal with long,
passive voice sentences it tells the author that 'grammar is in error'.
DD
William M. Klein
<docd...@panix.com> wrote in message news:c4190l$qh8$1...@panix5.panix.com...
> In article <wRH8c.755$lt2...@newsread1.news.pas.earthlink.net>,
> William M. Klein <wmk...@nospam.netcom.com> wrote:
> ><docd...@panix.com> wrote in message news:c3ujo6$bbt$1...@panix5.panix.com...
> ><snip >
> >5) Although the 2002 comes closer to specifying what "syntactic
specifications"
> >are that must be "flagged/indicated" - this did NOT exist in any earlier
> >Standard.
>
> This brings things full-circle to how "syntactic specifications" differ
> from "syntax rules" differ from "Syntax Rules" (all terms cited with
> quotation marks and capitalisation as per original).
>
I don't know why this seems to be confusing.
The quotes around "Syntax Rules" and "General Formats" is because these are
actual "labels" within the current and past Standards. HOWEVER, and (in the
2002 Standard) it is clear that both of these are PART of the "syntactic
specification". HOWEVER, they are *NOT* all of the "syntactic specification".
Furthermore, the explicit rules of the current and past standards have said that
an implementation MAY include "limits" on the ellipsis "stuff".
Having EXTENSION is a very different thing that not being syntactically correct.
The '85 and 2002 Standard do require a conforming compiler to provide a flaging
mechanism for extensions (but as stated elsewhere when an extension is a part of
the compiler is up to the vendor).
Maybe this set of re-wording will help:
A program is "syntactically" correct when:
A) It conforms to the "syntactic specificaitons" of the Standard (these include
but are NOT limited to items labeled "Syntax Rules" and "General Rules" in the
Standard)
B) for implementor extensions, it conforms to the "syntactic specifications"
that the vendor provides for those extensions
C) for both types of items above, the code does not violate the "limits"
documented by the vendor
It really DOES end up (where some of us started) that the vendor defines what is
and is not "syntac specification" for their compiler. This MUST include the
"Syntax Rules" and "General Formats" of the Standard but it may also include
LOTS of other stuff for both extension and Standard features.
For the 2002 Standard (but not before) *if* you get a "clean compile" when using
the (optionally selectable but must be available) "syntax flagging" - then you
have valid syntax / if not then you don't.
William M. Klein
" A) It conforms to the "syntactic specifications" of the Standard (these
include but are NOT limited to items labeled "Syntax Rules" and "General Rules"
in the Standard)"
should have been
" A) It conforms to the "syntactic specifications" of the Standard (these
include but are NOT limited to items labeled "Syntax Rules" and "General
Formats" in the Standard)"
MOSTLY (but not completely) "General Rules" are NOT considered part of the
"syntactic specification" while "General Formats" ALWAYS are.
--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:n7Y8c.2179$lt2...@newsread1.news.pas.earthlink.net...
docd...@panix.com
William M. Klein <wmk...@nospam.netcom.com> wrote:
[snip]
>Maybe this set of re-wording will help:
>
>A program is "syntactically" correct when:
>
>A) It conforms to the "syntactic specificaitons" of the Standard (these include
>but are NOT limited to items labeled "Syntax Rules" and "General Rules" in the
>Standard)
>B) for implementor extensions, it conforms to the "syntactic specifications"
>that the vendor provides for those extensions
>C) for both types of items above, the code does not violate the "limits"
>documented by the vendor
It appears, Mr Klein, that C trumps A and B, and what you are saying is
that correct syntax is defined by the vendor and that a syntax error is
vendor-defined.
>
>It really DOES end up (where some of us started) that the vendor defines what is
>and is not "syntac specification" for their compiler. This MUST include the
>"Syntax Rules" and "General Formats" of the Standard but it may also include
>LOTS of other stuff for both extension and Standard features.
It appears here, Mr Klein, that a vendor's implementation '...MUST include
the "Syntax Rules" and "general Formats" of the Standard'. If that is the
case then a compiler which returns a syntax error for code which complies
with the Standard's Syntax Rules is wrong.
>
>For the 2002 Standard (but not before) *if* you get a "clean compile" when using
>the (optionally selectable but must be available) "syntax flagging" - then you
>have valid syntax / if not then you don't.
What you seem to be saying here, Mr Klein, is that prior to 2002 valid
syntax was strictly implementor-defined and that there was no standard.
Am I reading this right? It appears to contain contradictions.
DD
William M. Klein
<docd...@panix.com> wrote in message news:c41rar$t8i$1...@panix5.panix.com...
> In article <n7Y8c.2179$lt2...@newsread1.news.pas.earthlink.net>,
> William M. Klein <wmk...@nospam.netcom.com> wrote:
>
<snip>
> >
is
> >and is not "syntac specification" for their compiler. This MUST include the
> >"Syntax Rules" and "General Formats" of the Standard but it may also include
> >LOTS of other stuff for both extension and Standard features.
>
> It appears here, Mr Klein, that a vendor's implementation '...MUST include
> the "Syntax Rules" and "general Formats" of the Standard'. If that is the
> case then a compiler which returns a syntax error for code which complies
> with the Standard's Syntax Rules is wrong.
>
Your first sentence is correct. Your second is incorrect. It is true that if a
program VIOLATES the "Syntax Rules" and "General Formats" of the Standard, then
it must get a compiler error WHEN the compiler is running in "Standard
conforming mode". (For example, IBM documents that when you compile with
NODYNAM, you are explicitly NOT in ANSI/ISO conforming mode - but that when you
compile with DYNAM, you are).
HOWEVER, that says nothing about source code that does not violate the "Syntax
Rules" and "General Formats" of the Standard (i.e. is it syntactacly correct or
incorrect). A vendor may (and still be standard conforming) add ADDITONAL
"syntactic specification" - especially when it comes to "limits" and still be
Standard Conforming. Only the vendor may determine what additional rules must
be followed for a program to be syntactically correct.
Again, consider the "EVALUATE WHEN" situation.
The "Syntax Rules" and "General Format" tell you how to code an EVALUATE with a
(potentially infinite) number of WHEN phrases. However, the Standard also says
that a vendor MAY place "limits" on items with ellipses (such as WHEN phrases)
in the Standard. Therefore, if a vendor says that you may only have 15 WHEN
phrases and your source code has 16, you have NOT violated any of the specific
"Syntax Rules" or "General Formats" of the Standard, but your program DOES have
a "syntax error" in a conforming compiler.
On the other hand, if you code a "parial expression" EVALUATE WHEN and are using
an '85 Standard compiler (not a 2002 conforming compiler) such as
Evaluate SomeThing
When > "A" ...
then the compiler vendor must do one of two things
A) "flag" this as an extension
or
B) Issue some type of compiler "syntax" error (actually, that is only required
in the 2002 Standard where this is VALID syntax, but hopefully you get my point)
Are we getting closer to you understanding this?
docd...@panix.com
William M. Klein <wmk...@nospam.netcom.com> wrote:
>
><docd...@panix.com> wrote in message news:c41rar$t8i$1...@panix5.panix.com...
>> In article <n7Y8c.2179$lt2...@newsread1.news.pas.earthlink.net>,
>> William M. Klein <wmk...@nospam.netcom.com> wrote:
>>
><snip>
>> >
>> >It really DOES end up (where some of us started) that the vendor defines what is
>> >and is not "syntac specification" for their compiler. This MUST include the
>> >"Syntax Rules" and "General Formats" of the Standard but it may also include
>> >LOTS of other stuff for both extension and Standard features.
>>
>> It appears here, Mr Klein, that a vendor's implementation '...MUST include
>> the "Syntax Rules" and "general Formats" of the Standard'. If that is the
>> case then a compiler which returns a syntax error for code which complies
>> with the Standard's Syntax Rules is wrong.
>>
>
>Your first sentence is correct. Your second is incorrect.
All right, then let me try again:
It appears here, Mr Klein, that a vendor's implementation '...MUST include
the "Syntax Rules" and "general Formats" of the Standard'. If that is
the case then a compiler which returns a syntax error for code which
complies with the Standard's Syntax Rules is right.
Better? It doesn't feel that way to me... but I am still learning.
DD
Rick Smith
<docd...@panix.com> wrote in message news:c417tk$pil$1...@panix5.panix.com...
Not suggestion. Understand that a programming language
standard is a specification for a programming language; not a
specification for a compiler -- thus two domains. The standard
specifies valid syntax for the language. The implementor decides,
for example, how much valid syntax its compiler can accept.
A language compiler cannot exist independently of a language
specification; but the language specification does not define
the specification for the compiler -- it imposes requirements
for the specification of the compiler.
Consider the definition -- syntax error: a combination of
language elements that prevents successful compilation.
'[C]ombination of language elements' carries the notion of
syntax and 'prevents successful compilation' carries the
notion of error. If this definition is valid, it implies that valid
syntax (language domain) could cause a syntax error (compiler
domain) by preventing successful compilation (compiler domain).
The apparent absurdity is resolved by recognizing two distinct,
though dependent, domains.
William M. Klein
Just because it is true that
If A Then B
then it is true that
IF not B, then not A
but it is not (necessarily) True that
If not A then not B
Now let's substitute statement
A = source violates the rules of the Standard
B = source must get a syntax error.
substitution
(true statement 1)
If "source violates the rules of the Standard"
Then "source must get a syntax error"
It is also true
If not "source gets a syntax error"
Then not "source violates rules of the Standard"
but NOT true
If not "source violates rules of the Standard"
Then not "source get a syntax error"
****
There is NO "guaranteed true" statement that you can make about code that does
not violate the rules of the Standard -
There is "truth" you may state about
code that DOES violate the rules of the Standard
or
code that does NOT get a syntax error
--
Bill Klein
wmklein <at> ix.netcom.com
<docd...@panix.com> wrote in message news:c41ucf$909$1...@panix5.panix.com...
docd...@panix.com
Rick Smith <rick...@mfi.net> wrote:
>
><docd...@panix.com> wrote in message news:c417tk$pil$1...@panix5.panix.com...
[snip]
>> It seems that you are setting the standard and the implementation to be
>> co-equal, that such things exist only in practise (a variation of 'ibi non
>> accusator, non iudex' or 'where there ain't no cop there ain't no
>> speed-limit'). That being the case then the conclusion appears to be that
>> the Standard is not a standard but... a suggestion.
>
>Not suggestion. Understand that a programming language
>standard is a specification for a programming language; not a
>specification for a compiler -- thus two domains.
Using this terminology it seems that a compiler is an implementation of
the specification of the language... after all, it is code.
>The standard
>specifies valid syntax for the language. The implementor decides,
>for example, how much valid syntax its compiler can accept.
So it follows that a compiler is an implementation of a subset of the
language specs set forth in the standard.
>A language compiler cannot exist independently of a language
>specification; but the language specification does not define
>the specification for the compiler -- it imposes requirements
>for the specification of the compiler.
I am not sure how you are differentiating between 'defining
specifications' and 'imposing requirements'; I have heard the two used
interchangeably ('these requirements are set forth in the spec' and 'the
spec is written so that it requires').
>
>Consider the definition -- syntax error: a combination of
>language elements that prevents successful compilation.
>'[C]ombination of language elements' carries the notion of
>syntax and 'prevents successful compilation' carries the
>notion of error. If this definition is valid, it implies that valid
>syntax (language domain) could cause a syntax error (compiler
>domain) by preventing successful compilation (compiler domain).
>The apparent absurdity is resolved by recognizing two distinct,
>though dependent, domains.
I would not say distinct... but that one is a subset of the other, the
compiler's 'list of acceptable combinations of language elements' contains
a part of the Standard and... some other stuff, the various extensions a
vendor offers. In that case something which is 'invalid syntax' to the
compiler could be valid syntax in the Standard... hence my question of
'where do the rules of valid syntax' live, the Standard or the
implementation?'
DD
docd...@panix.com
William M. Klein <wmk...@nospam.netcom.com> wrote:
>Sorry - still not quite right. This is the old "logic" issue.
Mr Klein, I have given two examples, both of which you say are wrong. In
both cases you agree with the statement:
'It appears here, Mr Klein, that a vendor's implementation '...MUST
include the "Syntax Rules" and "general Formats" of the Standard'.'
Predicated by that statement I have offered two conclusions:
'If that is the case then a compiler which returns a syntax error for code
which complies with the Standard's Syntax Rules is wrong.'
... and ...
'If that is the case then a compiler which returns a syntax error for code
which complies with the Standard's Syntax Rules is right.'
... both of which you say are incorrect. Your demonstration of Formal
Logic was enjoyable, certainly, but the brilliance of it was such that it
appeared not to illuminate but rather to blind. Given the two clear,
simple, unambiguous statements I supplied are both, according to you,
wrong then I find there is one other possibility. To put that possibility
in the context of the first two:
'It appears here, Mr Klein, that a vendor's implementation '...MUST
include the "Syntax Rules" and "general Formats" of the Standard'. If
that is the case then a compiler which returns a syntax error for code
which complies with the Standard's Syntax Rules is neither right nor
wrong.'
... and if that is the case then the conclusion is equally... distasteful.
'Right' is wrong, 'wrong' is wrong... is there something I am missing
here?
DD
Rick Smith
<docd...@panix.com> wrote in message news:c4440d$scs$1...@panix1.panix.com...
> In article <1069f8j...@corp.supernews.com>,
> Rick Smith <rick...@mfi.net> wrote:
> >
> ><docd...@panix.com> wrote in message
news:c417tk$pil$1...@panix5.panix.com...
>
> [snip]
>
> >> It seems that you are setting the standard and the implementation to be
> >> co-equal, that such things exist only in practise (a variation of 'ibi
non
> >> accusator, non iudex' or 'where there ain't no cop there ain't no
> >> speed-limit'). That being the case then the conclusion appears to be
that
> >> the Standard is not a standard but... a suggestion.
> >
> >Not suggestion. Understand that a programming language
> >standard is a specification for a programming language; not a
> >specification for a compiler -- thus two domains.
>
> Using this terminology it seems that a compiler is an implementation of
> the specification of the language... after all, it is code.
The language specification cannot be implemented directly.
Parts of the language specification require the implementor
to complete the specification. For 2002 these items are listed
in Annex B as 'Implementor-defined language element list'.
> >The standard
> >specifies valid syntax for the language. The implementor decides,
> >for example, how much valid syntax its compiler can accept.
>
> So it follows that a compiler is an implementation of a subset of the
> language specs set forth in the standard.
Not quite. Your wording suggests that implementing half the
COBOL verbs would be sufficient ('implementation of a subset ...').
The correct sense is that the language specification is but one
of many requirements.
> >A language compiler cannot exist independently of a language
> >specification; but the language specification does not define
> >the specification for the compiler -- it imposes requirements
> >for the specification of the compiler.
>
> I am not sure how you are differentiating between 'defining
> specifications' and 'imposing requirements'; I have heard the two used
> interchangeably ('these requirements are set forth in the spec' and 'the
> spec is written so that it requires').
That you have heard such merely attests to the usefulness of
these words in their various senses. In the more specialized
sense that applies to systems and software development,
requirements are used to produce specifications. Thus the
requirements for a COmmon Business Oriented Language
are used to establish a specification for that language and
a desire to implement that language means to accept the
language specification as one of the requirements for the
specification of the compiler.
> >Consider the definition -- syntax error: a combination of
> >language elements that prevents successful compilation.
> >'[C]ombination of language elements' carries the notion of
> >syntax and 'prevents successful compilation' carries the
> >notion of error. If this definition is valid, it implies that valid
> >syntax (language domain) could cause a syntax error (compiler
> >domain) by preventing successful compilation (compiler domain).
> >The apparent absurdity is resolved by recognizing two distinct,
> >though dependent, domains.
>
> I would not say distinct... but that one is a subset of the other, the
> compiler's 'list of acceptable combinations of language elements' contains
> a part of the Standard and... some other stuff, the various extensions a
> vendor offers. In that case something which is 'invalid syntax' to the
> compiler could be valid syntax in the Standard... hence my question of
> 'where do the rules of valid syntax' live, the Standard or the
> implementation?'
The implementation, subject to the Standard. An implementor
need not flag every instance of invalid syntax as an error
('W - Period missing. Period assumed.') unless flagging to
the Standard has been requested and that such warnings be
treated as errors. And, when flagging to the Standard, the
valid syntax of implementor extensions becomes syntax
errors, if requested! The decision to call something a syntax
error rests entirely with the implementor, subject to the
Standard and other conditions present at compile time.
William M. Klein
make it) is:
'It is ture that a vendor's implementation '...MUST include the "Syntax Rules"
and "general Formats" of the Standard'. Unfortunately although that is the case
it is also ture that a compiler which returns a syntax error for code which
complies with the Standard's Syntax Rules is both right and conforming - as long
as it also documents as an error what it issues the message against as an error
AND if it also isues a syntax error or extension message for violations of the
Standard "Syntax Rules" and "General Formats".'
Bottom-Line (again):
The Standard "Syntax Rules" and "General Formats" tell you when source code is
INVALID (or an extension)
They (and the Standard) tell you almost NOTHING about source that meets the
rules/formats (the source may be treated as "sytax error free" or not.)
Another quote from the 2002 Standard (that I think appeared in similar formats
in earlier Standards) may (or may not) help you understand how explicitly this
is stated in the Standard:
"3.4 Relationship of a conforming compilation group to a conforming
implementation
The translation of a conforming compilation group by a conforming implementation
is defined only to the extent
specified in standard COBOL. It is possible that a conforming compilation group
will not be translated successfully.
Translation may be unsuccessful due to factors other than lack of conformance of
a compilation group.
NOTE These factors can include the use of optional, processor-dependent, or
implementor-defined language elements and
the limits of an implementation."
--
Bill Klein
wmklein <at> ix.netcom.com
<docd...@panix.com> wrote in message news:c44537$40m$1...@panix1.panix.com...
William M. Klein
should be
"'It is true that"
(who knows what other typos I have made <G>)
--
Bill Klein
wmklein <at> ix.netcom.com
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message
news:dRj9c.3844$lt2....@newsread1.news.pas.earthlink.net...
Richard
> I don't know why this is so hard.
Perhaps it is hard convincing others because you are wrong.
It a compiler reaches a limitation that causes the compilation to
cease then it is not a 'syntax error', whatever the compiler writer
chose to put in the error message. This would be especially true if a
sentence would be compiled correctly if it was in one place in the
source code and yet failed when in another place, which is typical of
reaching a compiler limitation.
> The correct statement (as simple as I can make it) is:
> [..]
It may be correct and true, but is quite irrelevant.
docd...@panix.com
Rick Smith <rick...@mfi.net> wrote:
>
><docd...@panix.com> wrote in message news:c4440d$scs$1...@panix1.panix.com...
>> In article <1069f8j...@corp.supernews.com>,
>> Rick Smith <rick...@mfi.net> wrote:
>> >
>> ><docd...@panix.com> wrote in message
>news:c417tk$pil$1...@panix5.panix.com...
>>
>> [snip]
>>
>> >> It seems that you are setting the standard and the implementation to be
>> >> co-equal, that such things exist only in practise (a variation of 'ibi non
>> >> accusator, non iudex' or 'where there ain't no cop there ain't no
>> >> speed-limit'). That being the case then the conclusion appears to be that
>> >> the Standard is not a standard but... a suggestion.
>> >
>> >Not suggestion. Understand that a programming language
>> >standard is a specification for a programming language; not a
>> >specification for a compiler -- thus two domains.
>>
>> Using this terminology it seems that a compiler is an implementation of
>> the specification of the language... after all, it is code.
>
>The language specification cannot be implemented directly.
Nowhere in my statement is 'directly', 'indirectly' or 'around the barn
door' referred to, Mr Smith.
>Parts of the language specification require the implementor
>to complete the specification. For 2002 these items are listed
>in Annex B as 'Implementor-defined language element list'.
Standards and their implementation by compilers have been around for a few
years prior to this... the one which started this thread was an ANSI '74
compiler.
>
>> >The standard
>> >specifies valid syntax for the language. The implementor decides,
>> >for example, how much valid syntax its compiler can accept.
>>
>> So it follows that a compiler is an implementation of a subset of the
>> language specs set forth in the standard.
>
>Not quite. Your wording suggests that implementing half the
>COBOL verbs would be sufficient ('implementation of a subset ...').
Mr Smith, suggestion is in the mind of the beholder. If 'how much' a
vendor chooses to implement of the standard's language specs is not equal
to all that is in the standard then the implementation is, by definition,
a subset.
>The correct sense is that the language specification is but one
>of many requirements.
'Correct sense' to *whom*, Mr Smith?
>
>> >A language compiler cannot exist independently of a language
>> >specification; but the language specification does not define
>> >the specification for the compiler -- it imposes requirements
>> >for the specification of the compiler.
>>
>> I am not sure how you are differentiating between 'defining
>> specifications' and 'imposing requirements'; I have heard the two used
>> interchangeably ('these requirements are set forth in the spec' and 'the
>> spec is written so that it requires').
>
>That you have heard such merely attests to the usefulness of
>these words in their various senses. In the more specialized
>sense that applies to systems and software development,
>requirements are used to produce specifications. Thus the
>requirements for a COmmon Business Oriented Language
>are used to establish a specification for that language and
>a desire to implement that language means to accept the
>language specification as one of the requirements for the
>specification of the compiler.
Mr Smith, in the paragraph above you state 'the requirements of COBOL are
used to establish a specification for that language', in an earlier
paragraph you state ' but the language specification.. imposes
requirements for the specification of the compiler.'
These appear to be contradictory, based on your assertion that
'requirements are used to produce specifications'.
>
>> >Consider the definition -- syntax error: a combination of
>> >language elements that prevents successful compilation.
>> >'[C]ombination of language elements' carries the notion of
>> >syntax and 'prevents successful compilation' carries the
>> >notion of error. If this definition is valid, it implies that valid
>> >syntax (language domain) could cause a syntax error (compiler
>> >domain) by preventing successful compilation (compiler domain).
>> >The apparent absurdity is resolved by recognizing two distinct,
>> >though dependent, domains.
>>
>> I would not say distinct... but that one is a subset of the other, the
>> compiler's 'list of acceptable combinations of language elements' contains
>> a part of the Standard and... some other stuff, the various extensions a
>> vendor offers. In that case something which is 'invalid syntax' to the
>> compiler could be valid syntax in the Standard... hence my question of
>> 'where do the rules of valid syntax' live, the Standard or the
>> implementation?'
>
>The implementation, subject to the Standard.
If the implementation is subject to the Standard then, by definition, the
implementation is subordinate to the Standard; the Standard, being
superordinate, would seem to have primacy... or so your language might
lead to conclude. What am I missing here?
DD
docd...@panix.com
William M. Klein <wmk...@nospam.netcom.com> wrote:
>I don't know why this is so hard. The correct statement (as simple as I can
>make it) is:
>
> 'It is ture that a vendor's implementation '...MUST include the "Syntax Rules"
>and "general Formats" of the Standard'. Unfortunately although that is the case
>it is also ture that a compiler which returns a syntax error for code which
>complies with the Standard's Syntax Rules is both right and conforming - as long
>as it also documents as an error what it issues the message against as an error
>AND if it also isues a syntax error or extension message for violations of the
>Standard "Syntax Rules" and "General Formats".'
If that is the best you can make it, Mr Klein, then you will not be able
to exceed it. Asking for more than the best is inviting disappointment;
at this point it appears that no more needs be said.
DD
[snip]
docd...@panix.com
Richard <rip...@Azonic.co.nz> wrote:
>"William M. Klein" <wmk...@nospam.netcom.com> wrote
>
>> I don't know why this is so hard.
>
>Perhaps it is hard convincing others because you are wrong.
>
>It a compiler reaches a limitation that causes the compilation to
>cease then it is not a 'syntax error', whatever the compiler writer
>chose to put in the error message. This would be especially true if a
>sentence would be compiled correctly if it was in one place in the
>source code and yet failed when in another place, which is typical of
>reaching a compiler limitation.
Hmmmmmm... it might be, Mr Plinston, that Mr Stevens will show you how
Very Very Wrong this is... if, of course, he can find the time to work it
into his e'er-so-well-filled schedule.
DD
Peter E. C. Dashwood
thought I'd have a little peep into CLC.
It is staggering the amount of brain cells being expended in this
particular thread (by both contributors), but it is really going
nowhere.
Nevertheless, it is entertaining.
As I have a few brain cells to spare, I thought I'd post a few
observations.
Please find my two cents interspersed below. My hope is that you can
both now turn on me and forget your original dispute <G>.
"William M. Klein" <wmk...@nospam.netcom.com> wrote in message news:<ij39c.2174$Dv2....@newsread2.news.pas.earthlink.net>...
> Sorry - still not quite right. This is the old "logic" issue.
>
> Just because it is true that
>
> If A Then B
>
> then it is true that
> IF not B, then not A
>
> but it is not (necessarily) True that
> If not A then not B
>
> Now let's substitute statement
>
> A = source violates the rules of the Standard
> B = source must get a syntax error.
>
That's not fair. You've weighted the conditions away from what Doc is
saying.
It isn't about source violating the rules of the standard, it is about
source violating the SYNTAX rules of the standard.
Doc's objection is that a diagnostic from a compiler should state
whether the problem is a compiler limitation or it is a syntax error,
or it is some other kind of error.
(Actually, I agree. I don't think a compiler should throw a syntax
error because its limits have been blown, given that the actual syntax
was compliant. BUT, I really don't care enough about it to spend hours
of my time arguing it...)
> substitution (I amended this to keep it honest...)
>
> (true statement 1)
> If (AND ONLY IF) "source violates the SYNTAX rules of the Standard"
> Then "source gets a syntax error"
>
> It is also true
>
> If not "source gets a syntax error"
> Then not "source violates the SYNTAX rules of the Standard"
>
> but NOT true
>
> If not "source violates the SYNTAX rules of the Standard"
> Then not "source gets a syntax error"
>
Nope. This one is now TRUE.
> ****
>
> There is NO "guaranteed true" statement that you can make about code that does
> not violate the rules of the Standard -
No, but there IS a "guaranteed TRUE" statement you can make about code
that does not violate the SYNTAX rules of the standard. (It will NOT
throw a syntax error).
All of which goes to show that formal Logic can be used to support
anything...<G>
My position would be:
1. If source code violates the syntax for COBOL as laid down in the
standard corresponding to the compiler being used, then it should flag
a syntax error.
That is the ONLY time a compiler should issue a syntax error.
(There is one possible override to this: Where the vendor has chosen
to depart from the COBOL standard (maybe to implement a vendor
extension) and has CLEARLY DOCUMENTED in the vendor supplied COBOL
manual what the syntax must be, then the syntax standard is as
described by the vendor, rather than as described by the COBOL
standard. A syntax error is still exactly that; an error in the
prescribed syntax.)
2. If source code violates the internal limits of a compiler, then
this should result in a diagnostic that is NOT a syntax error.(If a
syntax error caused the limit violation, then the syntax error should
be flagged, not the limit violation.)
(Once, long ago and far away, I was responsible for maintaining the
internals of a COBOL compiler and those were certainly the rules that
I applied.)
Bottom line:
Doc has a case, and no amount of arguing or "LOGIC" can dimininsh it.
HOWEVER, I think we would all agree that ANY diagnostic is better than
NO diagnostic, so if a compiler gives a syntax error when it is really
an internal limit violation, it really isn't the end of the world. At
least you have been given a clue to WHICH source statement was
problematic.
To sensitive programmers like the Doc <G>, this is offensive. It
implies the programmer was in error when he/she wasn't.
I think that is a valid position.
(Sorry, Bill, it isn't personal...<G>)
Pete.
docd...@panix.com
Peter E. C. Dashwood <dash...@enternet.co.nz> wrote:
[snip]
>Bottom line:
>
>Doc has a case, and no amount of arguing or "LOGIC" can dimininsh it.
Gosh, I'd blush, were I able to remember how... but it just kinda seemed
obvious to me.
DD
Rick Smith
<docd...@panix.com> wrote in message news:c458v0$3mh$1...@panix1.panix.com...
Quite right. The sentence was introductory to the paragragph.
Sometimes splitting paragraphs can lead to confusion.
> >Parts of the language specification require the implementor
> >to complete the specification. For 2002 these items are listed
> >in Annex B as 'Implementor-defined language element list'.
>
> Standards and their implementation by compilers have been around for a few
> years prior to this... the one which started this thread was an ANSI '74
> compiler.
And, for years other thatn 2002, there is, to the best of my
knowledge, a similar list for those standards.
> >> >The standard
> >> >specifies valid syntax for the language. The implementor decides,
> >> >for example, how much valid syntax its compiler can accept.
> >>
> >> So it follows that a compiler is an implementation of a subset of the
> >> language specs set forth in the standard.
> >
> >Not quite. Your wording suggests that implementing half the
> >COBOL verbs would be sufficient ('implementation of a subset ...').
>
> Mr Smith, suggestion is in the mind of the beholder. If 'how much' a
> vendor chooses to implement of the standard's language specs is not equal
> to all that is in the standard then the implementation is, by definition,
> a subset.
Mr Dwarf, 'how much' refers to limitations imposed by the
compiler, a subject being discussed in this thread. Therefore,
it would not follow from the discussion 'that a compiler is an
implementation of a subset of the language specs set forth
in the standard.' which had not been discussed at all.
Since you introduced the subject of 'subset of the language spec',
If I remember correctly, IBM COBOL E was a subset of COBOL-68
and IBM COBOL F was a full implementation of that standard;
but I digress.
> >The correct sense is that the language specification is but one
> >of many requirements.
>
> 'Correct sense' to *whom*, Mr Smith?
To those who agree with my opinion, Mr Dwarf!
> >> >A language compiler cannot exist independently of a language
> >> >specification; but the language specification does not define
> >> >the specification for the compiler -- it imposes requirements
> >> >for the specification of the compiler.
> >>
> >> I am not sure how you are differentiating between 'defining
> >> specifications' and 'imposing requirements'; I have heard the two used
> >> interchangeably ('these requirements are set forth in the spec' and
'the
> >> spec is written so that it requires').
> >
> >That you have heard such merely attests to the usefulness of
> >these words in their various senses. In the more specialized
> >sense that applies to systems and software development,
> >requirements are used to produce specifications. Thus the
> >requirements for a COmmon Business Oriented Language
> >are used to establish a specification for that language and
> >a desire to implement that language means to accept the
> >language specification as one of the requirements for the
> >specification of the compiler.
>
> Mr Smith, in the paragraph above you state 'the requirements of COBOL are
> used to establish a specification for that language', in an earlier
> paragraph you state ' but the language specification.. imposes
> requirements for the specification of the compiler.'
>
> These appear to be contradictory, based on your assertion that
> 'requirements are used to produce specifications'.
They are not contradictory. Both the 'Implementor-defined language
elements list' and 'General rules', for example, impose requirements
that must find expression in the specification for the compiler.
Including a specification from one system as a requirement of
another is merely a means of bridging two separate (distinct?)
systems.
> >> >Consider the definition -- syntax error: a combination of
> >> >language elements that prevents successful compilation.
> >> >'[C]ombination of language elements' carries the notion of
> >> >syntax and 'prevents successful compilation' carries the
> >> >notion of error. If this definition is valid, it implies that valid
> >> >syntax (language domain) could cause a syntax error (compiler
> >> >domain) by preventing successful compilation (compiler domain).
> >> >The apparent absurdity is resolved by recognizing two distinct,
> >> >though dependent, domains.
> >>
> >> I would not say distinct... but that one is a subset of the other, the
> >> compiler's 'list of acceptable combinations of language elements'
contains
> >> a part of the Standard and... some other stuff, the various extensions
a
> >> vendor offers. In that case something which is 'invalid syntax' to the
> >> compiler could be valid syntax in the Standard... hence my question of
> >> 'where do the rules of valid syntax' live, the Standard or the
> >> implementation?'
> >
> >The implementation, subject to the Standard.
>
> If the implementation is subject to the Standard then, by definition, the
> implementation is subordinate to the Standard; the Standard, being
> superordinate, would seem to have primacy... or so your language might
> lead to conclude. What am I missing here?
Where the Standard provides formats and syntax rules, it is
supreme. Where the implementation provides formats and
syntax rules, it must not conflict with the Standard. The implementor
applies whichever rules are required. Your question '... the Standard
or the implemention?' asked for one to the exclusion of the other.
The answer is both in the form I stated. This is because the
rules 'live' in the implementation but must conform to the Standard
or, 'as if' the Standard's rules 'live' in the Standard.
William M. Klein
So you think that if a compiler vendor only supports 15 WHEN phrases for
EVALUATE and a source program with 16 WHEN statement is "compiled" that it
should get a message saying
"This statement has violated the limits of this compiler"
and not call it a syntax message.
I (hopefully) indicated earlier, that I don't really care - as long as it is a
message. The way the Standard itself uses "syntactic specification" it is
(basically) anything that the compiler can detect (which exceeding limits is).
Therefore, these are syntax violations in the Standard's definition of them.
Others may not like it, but it is the way the Standard is written.
--
Bill Klein
wmklein <at> ix.netcom.com
"Peter E. C. Dashwood" <dash...@enternet.co.nz> wrote in message
news:b3638c46.04032...@posting.google.com...