Re: "forward" references (was: COBOL subscript range checking


"William M. Klein" <wmklein@xxxxxxxxxxxxxxxxx> wrote in message
news:CRDAi.175098$jE4.100287@xxxxxxxxxxxxxxxxxxxxxxxxx
(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!



.

Relevant Pages

  • Re: Considerations for a better Import/Export Format
    ... References is made to XML purely for illustration. ... The character set should be global which nowadays means UTF-8. ... I believe it's easier to use a bottom-up representation. ... The issue, as always, is not so much an issue with the current standard, ...
    (soc.genealogy.computing)
  • Re: Equates, object size and speed
    ... still use references like ... think of nothing like the weird and wonderful SQL or other schemas around. ... dictionaries etc just like you would expect ... programmers to enforce some kind of minimal standard. ...
    (comp.databases.pick)
  • Re: Considerations for a better Import/Export Format
    ... References is made to XML purely for illustration. ... Define a universal import/export format ... I believe it's easier to use a bottom-up representation. ... The issue, as always, is not so much an issue with the current standard, but the fact ...
    (soc.genealogy.computing)
  • Re: Mesolithic/Neolithic Boundary (1) From Whence They Came.
    ... Eric jumped down my throat claiming that prd ... was right and I should accept it without references (mainly because ... ASCII American Standard Code for Information Interchange ...
    (sci.archaeology)
  • Re: CONSTANT ENTRY (was "forward" references (was: COBOL subscript range checking))
    ... level of complexity to COBOL compiler development ... when we get away from these references in the "text manipulation ... I think it is clear that the '02 Standard *does* ... place such a requirement on the implementer - and as far as I can tell ...
    (comp.lang.cobol)