Compiling forward references

Does this look like a worst case?

01  a LIKE b.
01  b LIKE c.
01  c LIKE d.
...
01  y LIKE z.
01  z PIC X.

A simple-minded compiler would take 25 forward sequential scans to resolve a
. If the
compiler ran every other scan backwards, definitions would be resolved in tw
o passes, but
that's not a good solution either.

The right solution would put the names a, b, c ... z into a tree or hash tab
le, with a
link to definitions in the source program. Think of it as a dictionary, if t
hat helps.
Then the resolution is not done by multiple sequential passes of the whole s
ource code but
rather by high speed lookups.

Compilers already do that. When they compile MOVE a TO b, do you think they 
find a and b
by sequentially reading through the source? Of course not.

Given that compilers already have a tool for rapidly finding names, resolvin
g meta
references can be done with recursive invocation of that tool. When a needs 
the definition
of b, push the context, search for b, receive b's definition, pop context, r
eplace LIKE
phrase with definition.

If the stack overflows, you've got a circular reference.

I don't understand why such a simple problem is causing heartburn.

"Robert" <no@e.mail> wrote in message
 news:s69cd3pnb0j1b3dpqqht8thtl8osesjji7@
4ax.com...
> Does this look like a worst case?
>
> 01  a LIKE b.
> 01  b LIKE c.
> 01  c LIKE d.
> ...
> 01  y LIKE z.
> 01  z PIC X.
>
> A simple-minded compiler would take 25 forward sequential scans to resolve
> a. If the
> compiler ran every other scan backwards, definitions would be resolved in
> two passes, but
> that's not a good solution either.
>
> The right solution would put the names a, b, c ... z into a tree or hash
> table, with a
> link to definitions in the source program. Think of it as a dictionary, if
> that helps.
> Then the resolution is not done by multiple sequential passes of the whole
> source code but
> rather by high speed lookups.
>
> Compilers already do that. When they compile MOVE a TO b, do you think
> they find a and b
> by sequentially reading through the source? Of course not.
>
> Given that compilers already have a tool for rapidly finding names,
> resolving meta
> references can be done with recursive invocation of that tool. When a
> needs the definition
> of b, push the context, search for b, receive b's definition, pop context,
> replace LIKE
> phrase with definition.
>
> If the stack overflows, you've got a circular reference.
>
> I don't understand why such a simple problem is causing heartburn.

Neither do I. :-)

That means that either, there are people here who would rather have a
problem than a solution (it adds meaning to their lives, perhaps...:-)), or,
the rest of us simply don't understand the problem...

Pete.
--
"I used to write COBOL...now I can do anything."

"Robert" <no@e.mail> wrote in message
 news:s69cd3pnb0j1b3dpqqht8thtl8osesjji7@
4ax.com...
> Does this look like a worst case?

Not to me!

> 01  a LIKE b.
> 01  b LIKE c.
> 01  c LIKE d.
> ...
> 01  y LIKE z.
> 01  z PIC X.

The LIKE attribute is PL/I, COBOL uses the
SAME AS clause and does so similarly. <g>

> A simple-minded compiler would take 25 forward sequential scans to resolve
a. If the
> compiler ran every other scan backwards, definitions would be resolved in
two passes, but
> that's not a good solution either.
>
> The right solution would put the names a, b, c ... z into a tree or hash
table, with a
> link to definitions in the source program. Think of it as a dictionary, if
that helps.
> Then the resolution is not done by multiple sequential passes of the whole
source code but
> rather by high speed lookups.
>
> Compilers already do that. When they compile MOVE a TO b, do you think
they find a and b
> by sequentially reading through the source? Of course not.
>
> Given that compilers already have a tool for rapidly finding names,
resolving meta
> references can be done with recursive invocation of that tool. When a
needs the definition
> of b, push the context, search for b, receive b's definition, pop context,
replace LIKE
> phrase with definition.
>
> If the stack overflows, you've got a circular reference.
>
> I don't understand why such a simple problem is causing heartburn.

Indirect forward references require two scans of the
data division; one to build a table of definitions and
one to process the text. Both scans have a number of
similarities; thus, substantial duplication. Furthermore,
the first scan must operate reasonably well in the
presence of syntax errors because syntax processing
is done in the second scan. [The second scan handles
substitutions and the syntax must be correct after the
substitution.]

Indirect backward references require only one scan
without any duplication and all saved definitions will
have been checked for syntax errors before substitution.

That, I think is a reasonable start toward discussing
the problem. But the problem, as I see it, does not
include how to accomplish the scans, look-ups, or
substitutions.

Does that help?