Re: Continued discussion of Ada compile

[stt@inmet.inmet.com]

Re: Compilation speed, generics, etc.

There is nothing wrong with using generics "heavily" so long
as you realize that in most cases, they will be treated
roughly like an "include" or a macro expansion upon
instantiation.  Therefore, in calculating the number of
lines compiled, you should multiply the number of instantiations
of any generic by the number of lines of code in the generic
spec and body.

As far as recompiling the world, your problem seems to be
that the "specs" to your "core" are not sufficiently stable,
or that your "core" includes generic bodies mixed in with
non-generic code.
It is important to remember that, for most compilers,
instantiating a generic is analagous to "inlining" a
subprogram call.  Both create a dependence from the point of
instantiation/call on the *body* of the defining unit.
Generic instantiations can be particularly troublesome
since they are often themselves in a spec, and therefore
anything which depends on this spec, indirectly depends 
on the *body* of the generic.

There are various remedies.  Eventually, it is hoped that
most compilers will break this dependence on generic bodies,
by compiling the bodies of instantiations as implicitly separate 
compilation (sub)units.  However, until that is widespread,
you would do well to keep your generic bodies stable, or
only instantiate them in other bodies.  If you have
an instantiation in a "core" spec, you can instead
put a regular package spec there, and then implement
that package spec using an instantiation with a simple
layering (i.e., trivial subprogram bodies which just "pass the buck"
to the subprograms provided by a generic instantiation).

Similarly, avoid the use of pragma-Inline until the system
is debugged and stable.  Pragma Inline generally slows down
compiles, saves only a modest amount of run-time (in the "big"
picture), and creates recompilation nightmares.

Finally, once you have worked around the dangers of
generics and inlines, KEEP YOUR SPECS STABLE.  This
may mean providing extra "reserved" interfaces, escape
hatches, etc., to handle last-minute changes without
having to recompile "core" specs.
Once things are relatively debugged and stable, you should
eliminate the work-arounds.  Therefore, all work-arounds should
be visibly marked in the source.

Although the Rational is a great environment, it
definitely lulls people into forgetting about the
requirements of Ada compilers for "real" targets, where
due to optimization requirements, it is necessary to
expand generics inline, and it is not generally practical
to maintain enough of a program library database to support
incremental recompilation.

I hope this helps...

S. Tucker Taft      stt@inmet.inmet.com; uunet!inmet!stt
Intermetrics, Inc.
733 Concord Avenue
Cambridge, MA  02138