Re: WinNT ADA compilers comparison

["Robert I. Eachus" <rieachus@earthlink.net>]

n_brunot@my-deja.com wrote:

> In comparison to others compilers (not only Alsys ADA83) Gnat produces
> incredibly huge executables when you make intensive use of generics
> (using a lot of generics is a quite normal and desirable thing in ADA
> according to us)
 
> We of course use generics (and generics of generics ....) which is may
> be one of the most important and powerful ADA features, allowing you
> not spending your time writing more or less the same code, and keep
> strong compiler check.

     During the Ada 9X Requirements process, those of us at MITRE who
were
involved with supervision of government contracts had very few
corporate, as opposed to individual comments, on the proposed
requirements.

     The one thing that we all felt strongly about was that there were
"shortcomings" in the Ada language that should not be fixed.  Why? 
Because when a project ran into one of these "major problems" with Ada,
they would complain about the language, we would get called in, and in
most cases a design fix that was very inexpensive AT THAT POINT IN THE
PROJECT would eliminate both the major design problem and the problems
that the contractor was attributing to the language or the compiler.

     One simple example is "slow compilation times."  If your project is
making changes every day that require recompiling a substantial fraction
(or all!) of the source code, then the problem is not that Ada has these
nasty recompilation rules, it is that your design is not using
information hiding correctly, and that the final code will almost
certainly be unmaintainable.

     Another example, and the one that you seem to be tripping over, is
proper use of generics.  There is noting wrong with generics nested in
generics, and generic instantiations that instantiate other generics,
etc.  But you need to know for each generic and each instantiation
whether or not the compiler should do inlining, and where.

     But isn't that an implementation detail you say?  Sure it is, and
it is nice that the Ada language is designed so that changing those
decisions can be done by changing a couple of pragmas in the source
code.  But the decisions that can and should be delayed until later in
the project do not include code size limitations and timing of key
threads.  Those issues need to be thought out during the preliminary
design process and communicated to all members of the team, not just to
the design team.

     If those broad brush decisions are made correctly, and communicated
to the team, you won't have either code bloat or slow execution
surprises.  But no matter how intelligent the compiler is on the issue
of inlining and generics, the compiler doesn't know what the intent of
the design team is.  Pragmas and compiler switches can communicate that
information to the compiler, but if the design team hasn't considered
those issues, how can the compiler be expected to make those decisions
correctly.  (Also there are cases where what you really want to do is to
use generics to express templates, and the body of the generic template
needs to be written as a template.  The generic subprogram, or more
usually, the subprograms in a generic package, will be designed to be
inlined, but most or all of the actual code will be in subprograms that
are non-generic, and not inlined.  The Gnat Text_IO library has some
good examples of this.)

     So if your compiler is making incorrect implementation decisions,
the fault is usually not in the compiler, but in the directions that it
is given.  And even when the compiler is guessing right, you should
still tell the compiler what to do, and document it carefully, if the
decision is a key part of the overall design.  This is why the usual
advice is to use pragmas, often with very restricted scopes, rather than
compile-time switches.  The pragma puts the documentation where it
belongs--and will be seen by maintainers.  This is one reason why
pragmaa Unsuppress is being standardized.  It allows the programmer to
document that a particular exception is an expected part of this piece
of code, and any necessary checks should made here, even if the check is
turned off globally by a pragma or by a compile-time switch.