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

Author

"forward" references (was: COBOL subscript range checking

William M. Klein

2007-08-26, 9:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13d2rm6ho25no66@corp.supernews.com...
>
> "William M. Klein" <wmklein@nospam.netcom.com> wrote in message
> news:oMbAi.152024$sR4.54373@fe08.news.easynews.com...
<snip>
> the
> defined in
>
> This is where I would expect a note (statement of intent)
> to the effect that the rule permits forward references.
> But, I am relying on GR(1),
>
> "If literal-1 or compilation-variable-name-1 is specified,
> the effect of specifying constant-name-1 in other than
> this entry is as if literal-1 or the text represented by
> compilation-variable-name-1 were written where
> constant-name-1 is written."
>
> And, the fact that it can not be applied until after the
> constant-entry occurs in the source unit, as was
> demonstrated in the program posted above.
>

The syntax rule says that they may be used anywhere and the GR tells HOW it is
"used" wherever that might be. The GR never says ANYTHING about *how* the
compiler does what it is required to do. I think the SR and GR work quite well
together to tell what must be supported (use anywhere a literal of that category
can be use) and the GR tell that you do a substitution (but does NOT tell you
how or what the compiler needs to do to do this). Your assumption that a
"single pass" (or a use of only previously defined "stuff") is required is
simply not supported by the rules as they exist.

SR rule is quite clear that a conforming compiler MUST support use of a
constant-name wherever such a literal is supported (including in Special-Names,
earlier in the Data Division, or wherever). I would expect a compiler with
"limited" passes to find a user-defined word where a literal is required (or
allowed) to search forward in the text until it finds the appropriate
"definition". Same requirement for TYPEDEF and SAME AS.

The constant entry SR doesn't need to make "intent" clear; instead it provides a
simple REQUIREMENT for all conforming compilers that they allow constant-names
wherever such literals appear in the format.

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

Karl Kiesel

2007-08-27, 7:58 am

"William M. Klein" <wmklein@nospam.netcom.com> schrieb im Newsbeitrag
news:PLoAi.162805$jE4.61866@fe12.news.easynews.com...
> The syntax rule says that they may be used anywhere and the GR tells HOW
> it is "used" wherever that might be. The GR never says ANYTHING about
> *how* the compiler does what it is required to do. I think the SR and GR
> work quite well
> together to tell what must be supported (use anywhere a literal of that
> category can be use) and the GR tell that you do a substitution (but does
> NOT tell you how or what the compiler needs to do to do this). Your
> assumption that a "single pass" (or a use of only previously defined
> "stuff") is required is simply not supported by the rules as they exist.
>
> SR rule is quite clear that a conforming compiler MUST support use of a
> constant-name wherever such a literal is supported (including in
> Special-Names, earlier in the Data Division, or wherever). I would expect
> a compiler with "limited" passes to find a user-defined word where a
> literal is required (or allowed) to search forward in the text until it
> finds the appropriate "definition". Same requirement for TYPEDEF and SAME
> AS.

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:[color=darkred]
...[color=darkred]
...
01 const CONSTANT "a".
...[color=darkred]
...
01 const CONSTANT "b".
...[color=darkred]
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

Sponsored Links