Cobol - Compiling forward references

Author

Compiling forward references

Robert

2007-08-29, 9:55 pm

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.

Pete Dashwood

2007-08-30, 3:55 am

"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."

Rick Smith

2007-08-30, 3:55 am

"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?

Sponsored Links