Cobol - "forward" references (was: COBOL subscript range checking

Author

"forward" references (was: COBOL subscript range checking

William M. Klein

2007-08-27, 6:58 pm

(Karl raised the issue of whether the current definition is - or is not -
implementable. He didn't seem to disagree with me on what the '02 Standard
says).

I posted, the following question to the J4 distribution list

"
This has been a discussion in the comp.lang.cobol forum and I *think* that I
remember correctly, but was wondering if anyone else either remembers
differently or can point me to better places to look for a "definitive" answer.

The question is about "forward" references for things like CONSTANT Entries,
TYPEDEF/TYPE, and SAME AS.
It is my memory that when this was discussed (during the development of the '02
Standard) it was INTENTIONALLY decided that a conforming program could have
"forward" references, e.g.

- use of a constant-name in Special-Names paragraph - with CONSTANT entry in
data division
- Use of TYPE pointing to a TYPEDEF defined later in the program
- SAME AS referring to record later in the data division

It was thought (???) that the rules DO prohibit "circularity" of references, but
that "forward" references were INTENTIONALLY allowed.

Without submitting an interpretation request (that I MIGHT end up doing), can
others tell me what they think was INTENDED and ALLOWED?"

***

Sp far, I have received 3 replies, i.e

"** Reply 1

"My recollection is the same as Bill's."

*** Reply 2

" I wasn't there for this part of the development, but I can say that how to
deal with "forward references" is an mplementation detail. From a
compiler-design standpoint such issues are pretty much moot if two passes are
made against the source or an encoded version of it. Nested programs as
introduced in '85 complicates the implementation, but doesn't change the point
that it's the implementor's job to resolve the references, and I believe the
rules are clear as to how to resolve them (or determine that they are ambiguous
and take appropriate action).

Moreover, forward references exist in the '74 standard -- SELECT ... RECORD KEY
.... being but one example.

My opinion is that the resolution of references -- be they forward or
backward -- is one of the things the implementor is expected to provide for at
compilation time, and is not something the end user is supposed to be concerned
about so long as the references can be resolved unambiguously. "

*** Reply 3

""Forward" references are allowed and were intentionally allowed. Why is this a
problem (it is a problem for the implementors, not the users)? No
interpretation is needed since it is quite clear."

* * * * * * * * * * * *

I don't think that these will change Rick's mind (on either what was intended or
stated), but I did think that I would share these.

--
Bill Klein
wmklein <at> ix.netcom.com

William M. Klein

2007-08-27, 6:58 pm

Karl,
For what is is worth, Page 29 of the '02 Standard explicitly states that the
manipulation" and not the later "comiilation stage". Therefore (to me) I would
expect only one CONSTANT ENTRY to be "known" by the time you get to the
compilation stage (when this information would be needed).

My original comment about "searching ahead" was assuming (possibly erroneously)
that the entire text manipulation stage had been completed before this all need
to be handled.

--
Bill Klein
wmklein <at> ix.netcom.com
"Karl Kiesel" <Karl.Kiesel@fujitsu-siemens.com> wrote in message
news:faugsm$q0c$1@nntp.fujitsu-siemens.com...[color=darkred]
>
> "William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
> news:PLoAi.162805$jE4.61866@fe12.news.easynews.com...
>
> Bill,
> that is just the problem: which text should be searched? The program text can
> be manipulated using directives, which again may use literals, which again may
> be represented by user-defined words defined as constants which are not
> necessarily known at the time, when the source text manipulation must make the
> decisions!
> Consider for example a combination like this:
> ...
> ...
> 01 const CONSTANT "a".
> ...
> ...
> 01 const CONSTANT "b".
> ...
> in this case, a look ahead might help (if the actual value for var is not "a"
> and not "b"), but in general a compiler must expect and be able to handle
> various combinations and nesting of such directives, which means - as far as i
> can see - a compiler must assume values for the unknown constants and start to
> expand in parallel all possible sources and then check consitency of the
> assumed values for each expansion with the constant definitions eventually
> found in the expanded source; and additionally.
> All thogether, i think the definition of constants in STD2002 is not
> implementable - at least not with adequate usage of resources!
>
> K. Kiesel
> Fujitsu Siemens Computers, München
>

Rick Smith

2007-08-27, 6:58 pm

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:CRDAi.175098$jE4.100287@fe12.news.easynews.com...
> (Karl raised the issue of whether the current definition is - or is not -
> implementable. He didn't seem to disagree with me on what the '02
Standard
> says).
>
> I posted, the following question to the J4 distribution list
>
> "
> This has been a discussion in the comp.lang.cobol forum and I *think* that
I
> remember correctly, but was wondering if anyone else either remembers
> differently or can point me to better places to look for a "definitive"
answer.
>
> The question is about "forward" references for things like CONSTANT
Entries,
> TYPEDEF/TYPE, and SAME AS.
> It is my memory that when this was discussed (during the development of
the '02
> Standard) it was INTENTIONALLY decided that a conforming program could
have
> "forward" references, e.g.
>
> - use of a constant-name in Special-Names paragraph - with CONSTANT entry
in
> data division
> - Use of TYPE pointing to a TYPEDEF defined later in the program
> - SAME AS referring to record later in the data division
>
> It was thought (???) that the rules DO prohibit "circularity" of
references, but
> that "forward" references were INTENTIONALLY allowed.
>
> Without submitting an interpretation request (that I MIGHT end up doing),
can
> others tell me what they think was INTENDED and ALLOWED?"
>
> ***
>
> Sp far, I have received 3 replies, i.e
>
> "** Reply 1
>
> "My recollection is the same as Bill's."
>
> *** Reply 2
>
> " I wasn't there for this part of the development, but I can say that how
to
> deal with "forward references" is an mplementation detail. From a
> compiler-design standpoint such issues are pretty much moot if two passes
are
> made against the source or an encoded version of it. Nested programs as
> introduced in '85 complicates the implementation, but doesn't change the
point
> that it's the implementor's job to resolve the references, and I believe
the
> rules are clear as to how to resolve them (or determine that they are
ambiguous
> and take appropriate action).
>
> Moreover, forward references exist in the '74 standard -- SELECT ...
RECORD KEY
> ... being but one example.
>
> My opinion is that the resolution of references -- be they forward or
> backward -- is one of the things the implementor is expected to provide
for at
> compilation time, and is not something the end user is supposed to be
concerned
> about so long as the references can be resolved unambiguously. "
>
> *** Reply 3
>
> ""Forward" references are allowed and were intentionally allowed. Why is
this a
> problem (it is a problem for the implementors, not the users)? No
> interpretation is needed since it is quite clear."
>
> * * * * * * * * * * * *
>
> I don't think that these will change Rick's mind (on either what was
intended or
> stated), but I did think that I would share these.

These replies seem to be non-responsive to the "real"
question. I agree with what was said by both 2 and 3;
but neither addressed conformance with respect to
substitution ("as if"/"as though" ...) with elements defined
later in source text. This is particularly evident in 2 by
referring to the 74 and 85 standards when the "real"
question doesn't arise until the 2002 standard. 1's reply
contains nothing to show that the "real" question was
being addressed; rather, it does nothing more than agree
with a potentially faulty recollection.

The bottom-line is that there is nothing in these replies
to serve as reason for my changing my mind!

William M. Klein

2007-08-27, 9:57 pm

Certainly, when/if there is a conforming '02 Standard compiler, there is nothing
that says that any programmer will be required to uses forward references.
Furthermore, I think that even if there ever is a conforming compiler, I doubt
that there will ever be any conformance tests.

Therefore, I don't think you (or I) will be impacted by this. As others in J4
agree, the rules are clear (to us) and do require a conforming compiler to
provide this functionality. When a syntax rule says that something can be used
anywhere (with certain restrictions) then those are simply the ONLY valid
restrictions that a conforming compiler can put on it.

You won't be forced to use it, but "implementors" (such as Roger with OC) will
need to provide the feature - or not claim to be conforming.

--
Bill Klein
wmklein <at> ix.netcom.com
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13d6a9qgvelti4b@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:CRDAi.175098$jE4.100287@fe12.news.easynews.com...
> Standard
> I
> answer.
> Entries,
> the '02
> have
> in
> references, but
> can
> to
> are
> point
> the
> ambiguous
> RECORD KEY
> for at
> concerned
> this a
> intended or
>
> These replies seem to be non-responsive to the "real"
> question. I agree with what was said by both 2 and 3;
> but neither addressed conformance with respect to
> substitution ("as if"/"as though" ...) with elements defined
> later in source text. This is particularly evident in 2 by
> referring to the 74 and 85 standards when the "real"
> question doesn't arise until the 2002 standard. 1's reply
> contains nothing to show that the "real" question was
> being addressed; rather, it does nothing more than agree
> with a potentially faulty recollection.
>
> The bottom-line is that there is nothing in these replies
> to serve as reason for my changing my mind!
>
>
>

Sponsored Links