Re: Implementing an Ada compiler and libraries.

[Robert A Duff <bobduff@shell01.TheWorld.com>]

Lucretia <lucretia9@lycos.co.uk> writes:

> True, but how would a compiler that didn't impose limits (are there
> any?) manage to find compilation units with'd?

Here's one way:

I presume the way one invokes the compiler is via a "build" tool of some
sort (something like gnatmake or adabuild).

Keep a data structure that tells which compilation units are in which
source files.  Whenever the build tool is invoked, it first parses all
the files that changed since last time, and updates this data structure.
If any files are new, they need to be parsed.  If any files have been
deleted, all information about them in the data structure should be
deleted.  You can store this data structure on disk, if you like.

At this point, give an error if there are duplicate names (unless the
user has explicitly requested that one should override the other).

Now you have all the information you need to run the rest of the
compiler phases (after parsing) on everything in the right order
(or partially in parallel).

I know this method can be implemented efficiently, because I've done it
several times (not for Ada compilers, but for other language processing
tools (Ada and non-Ada)).

>... At least with GNAT it
> uses package name => filename, so that's easy to implement, but with
> multiple compilation units per file, it's much more tricky. I've
> basically thought the only way to partially do it is to compile the
> source into a parse tree, then traverse it to generate the AST,

Generate the AST from the parse tree?  I normally generate the syntax
tree directly during parsing.

You can save the syntax trees on disk, if you like.  Or in memory.  The
nice thing about saving syntax trees is that they depend only on one
source file.  When you modify one source file, you might need to do
semantic analysis and code gen on many things, but you only need to
parse one thing.

If you store things on disk, you have to be very careful to prevent them
from becoming corrupt.  Otherwise, the user will end up having to start
over from scratch all the time, defeating the purpose.

>... symbol
> tables, dependencies, etc. You then have the problem of finding a unit
> within a file? i.e. how do you know in which file to look?

- Bob