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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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-30 11:54:37 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!upp1.onvoy!onvoy.com!news-out.visi.com!hermes.visi.com!uunet!ash.uu.net!world!news From: Robert A Duff Subject: Re: What's it's name again? Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Tue, 30 Jul 2002 18:53:43 GMT References: <8sickuks7ravfjr0hknush4ua0iu5h8t66@4ax.com> NNTP-Posting-Host: shell01.theworld.com Organization: The World Public Access UNIX, Brookline, MA X-Newsreader: Gnus v5.7/Emacs 20.7 Xref: archiver1.google.com comp.lang.ada:27490 Date: 2002-07-30T18:53:43+00:00 List-Id: 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. 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