From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,29e947df2e56cc40 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-07-31 05:05:53 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!skynet.be!skynet.be!fu-berlin.de!uni-berlin.de!dialin-145-254-035-014.arcor-ip.NET!not-for-mail From: Dmitry A.Kazakov Newsgroups: comp.lang.ada Subject: Re: What's it's name again? Date: Thu, 1 Aug 2002 02:11:50 +0200 Message-ID: References: <8sickuks7ravfjr0hknush4ua0iu5h8t66@4ax.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-035-014.arcor-ip.net (145.254.35.14) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1028117150 35312685 145.254.35.14 (16 [77047]) User-Agent: KNode/0.4 Xref: archiver1.google.com comp.lang.ada:27519 Date: 2002-08-01T02:11:50+02:00 List-Id: Robert A Duff wrote: > Dmitry A. Kazakov writes: > >> On Mon, 29 Jul 2002 23:47:38 GMT, Robert A Duff >> 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