Re: Compiling forward references


"Robert" <no@xxxxxx> wrote in message
news:s69cd3pnb0j1b3dpqqht8thtl8osesjji7@xxxxxxxxxx
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?



.

Relevant Pages

  • Re: Qeustion in Compiling
    ... >>that you have a syntax problem on line 31. ... You start by finding and fixing all the syntax errors you find on line ... I have used compilers that used numerical error codes as diagnostics. ...
    (comp.lang.c)
  • Re: VC++ Net 2002 - 2003 upgrade
    ... > template-based code which I haven't been able to make work correctly ... make the rest of the compilers accept it. ... This is where Comeau shines. ... your users find silly syntax errors in your ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Compiler and an interpreter
    ... although I do prefer STL now. ... STL errors are far more common than syntax errors. ... > these errors for common compilers - haven't tried it. ... > the day an uninformative error message still does most of its job as it ...
    (comp.programming)