Re: Implementing an Ada compiler and libraries.

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 10 May 2007 11:06:28 -0700, Lucretia wrote:

> The parser matches a with statement, it then has to check to make sure
> this package has not already been with'd. If it hasn't, check to see
> if the package exists in binary form. If not, the compiler needs to
> start another compilation - this library unit just with'd then with
> the symbol table and go back to the original compilation.

Yes, this is roughly how I did it.
 
> Now this would make either a recursive compiler, or a compiler with
> multiple tasks (if developed in Ada ;D).

I did it recursively. There was a stack of contexts, so I put a stub on
that stack(s) and called the compiler again, quite simple.

> Also, allowing multiple compilation units in the same file can be
> problematic, e.g.
> 
> package one is ...;
> package two is ...;
> procedure three is ...;
> package body one is ...;
> package body two is ...;
> 
> What if the body of one or two require the subprogram three? Is this a
> form of forward declaration? Would interleaving specs and body's cause
> problems? Probably.

The context of either body cannot include the body of three, only the
declaration of. (I don't consider inlining here)

> I now think that I understand why GNAT chooses the model it has done,
> although I don't know whether the compiler handles dependency checking
> or if gnatmake does - it looks like gnatmake does, but underneath it
> could be the compiler.
> 
> Another area I've thought about is the symbol table:
> 
> 1) For a package spec, there is a public (is this the limited view?)
> and a private part, this can be compiled to symbol table.

These are two different contexts. The private one refers to the public one.
If you kept them apart, you could reduce the number of recompilations.

> 2) For the package body, there is another private part which cannot be
> accessed outside of the spec unless exported in the public part of the
> spec, this can be compiled into the spec's symbol table or a separate
> one.

This is a third context which is needed for separate bodies.

> 3) All other compilation units compile down to 1 symbol table.

Wait a minute (:-)), there also exist task and protected types, and, well
generics. Though the pattern is same.

Also, you will probably need special contexts for matching prefix notation
(be it damned (:-)), keyed associations, qualified names, aggregates. I
mean if you wanted to take the advantage of the approach. In my case I
postponed all this stuff until the semantic analysis, but the contexts were
needed anyway.

> For a final build, only the public area of the package spec needs to
> be in the symbol table, in a debug build, the whole lot needs to be
> there.

Well, contexts could serve as source of symbolic information, but the
debugger needs a lot more stuff. I am not sure if the format should be
preserved as-is. Clearly it could be a great advantage, but I cannot say
how realistic is that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de