Re: What's it's name again?

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

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On Mon, 29 Jul 2002 23:47:38 GMT, Robert A Duff
> <bobduff@shell01.TheWorld.com> wrote:
> 
> >The whole model here depends on the idea that the compiler can look at
> >the specs of all with'ed packages (including private parts), but not
> >their bodies.  Pragma Inline breaks that model, which IMHO makes the
> >whole model suspect.
> 
> I find it too, but simply cannot imagine how one could do it
> otherwise. Do you have any idea? 

I'm not sure which part you think is hard.  You could put procedure
bodies in specs (like in C++) and make inlining easier.  Or you can put
the completion of private types in the package body, making generation
of efficient code harder.  But not impossible -- the compiler has to
assume the worst (e.g. treat the size of a private type as a dynamic
quantity, or else peek into the body.

The issue is that in order to generate efficient code, the compiler
needs to see some part of the "implementation" of something.  In the
case of a type, the compiler would often like to know the size of that
type (if static), so it can allocate variables and record components and
whatnot efficiently.  In the case of a procedure, the most efficient
implementation is sometimes inlined code, so the compiler needs to see
the procedure body.

I'm assuming the language supports some sort of separate interface
vs. implementation.  By "separate" I mean some combination of "stored in
separate source files" and "split clearly syntactically" and "processed
separately by the compiler."  (The Ada RM doesn't say anything about
source files, but it heavily implies some things, and this issue is
important: one would like the CM system to control interface and
implementation separately.)

But we don't want to include this efficiency information in the
interface definition (the "spec", in Ada).

Types and procedures are the main thing, but there are other analogous
features: e.g., you don't want the *value* of a deferred constant to be
part of the spec, but you want the compiler to take advantage of that
value, if it can.

There are several possible solutions.  My objection in the Ada case is
lack of uniformity -- solving two similar problems with completely
different solutions.  That is, the "private type" solution is different
from the "pragma inline" solution.

Here are the solutions that come to mind:

1. Make the private information part of the spec.  This is what Ada does
   for private types -- the compiler can see the full type declaration.
   This is also what C++ uses for the inlined-call case: to inline
   something, you include the "body" in the "spec" of the class.
   (Please correct me if my memory of C++ is hazy.)

2. Put the private info in the body.  But let the compiler "peek" into
   the body in some cases (pragma Inline present, inlining-enabled
   switch turned on, phase of moon is blue, etc).  This is what Ada does
   for the inlined-call case.  I would claim Ada *could* do something
   similar for the private type case.  (Note that in languages where
   "everything's a pointer", you get this kind of (lack of) efficiency.)

   This idea seems nice in that it gives the programmer control over the
   compile-time speed vs. run-time speed trade-off.  (By the way, I
   claim that computers are many years away from being so fast that this
   tradeoff doesn't matter.  Especially since every hardware gain is
   offset by more software bloat.)

3. Define packages as *three* parts: the interface, the
   efficiency-critical parts of the implementation, and the
   implementation.
   The second part is really the "private part" of Ada, but split
   out into a separate syntactic unit (probably in a separate file).
   In the traditional Ada compiler dependency setup, a change to the
   second part would trigger recompilation of all with-ing compilation
   units.

I claim that any of these 3 possibilities is suitable for the
private-type case, and the inline-procedure case, and every other case.
I also claim that it would simplify the language to choose one of the
above, and use it for all such interface-vs-impl kinds of features.

I lean toward 2, but 3 also has merit.  Number 1, as in Ada private
types, has a severe disadvantage: you can't put the full type in a
different file from the private type.  It doesn't get a different
revision number in the CM system.  And if you have multiple versions
(say, for different target hardware), you have to duplicate the visible
part.

- Bob