Re: What's it's name again?

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

Robert A Duff wrote:

> 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.

C++ is awful! All that idiotic rules that inlined function are compiled as 
if all class declarations were appear before the function body. Then header 
files of 1K+ lines long ...

> 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.

I see, but there is also a difference. The body of a subroutine is not a 
part of its declaration, so you can continue compilation of specifications 
no matter how the body looks like. In contrary to this the size of a type 
is a function of its declaration. So there might be no difference when some 
other comilation unit is being compiled, but for a compilation the 
package's specification I think there is a difference.

> 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.)

Something like:

package ... is
   ...
   procedure Foo; -- To be inlined (no extra pragma)
   ...
private
   ...
   procedure Foo is -- Implementation here
   begin
      ...
   end Foo;
   ...

There is a problem that Foo will see no package body, which might contain 
some implementation-dependent things it needs.
 
> 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.)

Sort of pragma Inline for incomplete types and values (deferred constants)? 
Do you think it is technically possible? I has not much thought about it, 
but we must ensure absence of any circular dependencies, which could 
prevent compiler from calculation of the object size.

> 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.

This is attractive, because with tagged types [especially when you need to 
add some public and some private components] the specifications get too 
long. It is also good because then one could require that the compiler 
never ever looks in *.adb. But does not it also suffer the problem of 
not-seeing *.adb?

> 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.

What if to allow something like:

package X
   ...
private is separate;
end X;

Then there should be X-XX.ads containing a completion of X.

-- 
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de