Re: limited private types

[ryer@inmet.UUCP]

I agree it would be nice to be able to defer specifying the details
of the private type until the body is compiled.  Also, the reason for
the present restriction is so that the compiler can know the size of
the type.  Implicitly generated heap objects would work ok (forcing all
passage of private types by reference).  HOWEVER:

Ada now provides the pointer-based semantics when the user explicitly codes
an access type.  It ALSO provides the more efficient direct allocation/access
when the user does not code a access type.   The language changes proposed 
would eliminate one option.  It is possible to build an Ada compiler which 
NEVER uses the heap or any sort of pointer to access ordinary objects of 
static sizes, and at least one is very careful of this.  This is important
to those who use Ada for realtime systems.  

Many actual private types in real programs turn out to be integers.  Passing
these by value makes a big difference in the performance of the generated
code.  (Often a procedure parameter is already in a register at the call
site, and some optimizers contrive to make it the appropriate one so the cost
for passing it is zero as compared to a store at the call site followed by
a load in the caller).  Some Ada applications are built for small machines
with restricted memory and modest throughput and have to meet timing constraints
that are very tight (e.g. 100 hertz).  

As we used to say in the Ada language design days, "any good compiler will
resolve this", in this case by only introducing an implicit access type when
the private type's definition is missing from the spec and otherwise generating
the same code as now.  I hope we've learned that compiler writers sometimes
take the easiest path and defer the optimal approach to some future release.
We've gone through years of performance problems with Ada because of compilers
that weren't optimal.  Efficient approaches were proposed for every language
feature when the language was being designed, and features were dropped it
nobody could come up with an efficient implementation.  It turns out that 
compilers aren't as good as the language designers contemplated even now.

There had been no mention of the impact on the generated code in this note
stream and I had to post this flame.  In the 9X cycle, we need to ask
not only whether an efficient implementation is feasible, but whether
it is likely to appear in most compilers within a reasonable time.

I "vote" strongly against the proposal that ALL parameters should be
passed by reference  -- that clearly would make Ada less efficient on
most machines however good the compilers are.

The slow acceptance of Ada has been due to performance problems in the
generated code and speed and reliability problems in the compilers, not
due to a lack of flexibility in dealing with private types or other features.
Lets not add complexity and reduce performance this time around.

Mike Ryer
Intermetrics, Inc.