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=unavailable autolearn_force=no version=3.4.4 Path: border1.nntp.ams3.giganews.com!border2.nntp.ams3.giganews.com!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!news.mixmin.net!news2.arglkargh.de!nuzba.szn.dk!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada202X: Easy to use "UML private"-like components Date: Mon, 24 Jun 2013 15:05:36 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <69246de0-4b33-4d47-b5be-a45e8c911fb0@googlegroups.com> <9qrbs8l828t3pvgves504a8fm7o1c7tcpj@4ax.com> <91qcs81k6am9l3u3n19lj0b072lc48td69@4ax.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1372104337 10599 69.95.181.76 (24 Jun 2013 20:05:37 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 24 Jun 2013 20:05:37 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Original-Bytes: 4818 Xref: number.nntp.dca.giganews.com comp.lang.ada:182069 Date: 2013-06-24T15:05:36-05:00 List-Id: "Robert A Duff" wrote in message news:wccmwqhkm22.fsf@shell01.TheWorld.com... ... > The compilation model is that when compiling something, the compiler > looks at information coming from the specs of imported things, but not > their bodies. Modula-2 compilers actually work that way, and this > is the reason for the must-be-pointer (or must be the same size as > a pointer, or smaller, as I had (mis?)remembered it). > > It is also the reason for the private part kludge: the compiler sees > the size of the full type for a private type (assuming it is known > at compile time). But this reasoning makes no sense to me, because > that's not how Ada compilers work. Any reasonable implementation > of generics and inlining needs to look at bodies. So full types > should be in bodies, and compilers should look there (at least > in optimizing mode) to find out their size. Baloney. Maybe *most* Ada compilers work this way, but certainly not all: Janus/Ada works exactly like your description of Modula-2 compilers. Generics are implemented with universal code sharing in Janus/Ada for precisely this reason -- our compiler never looks in a body other than to compile it. (We were fanatical about minimizing compilation dependencies, because when a single compilation took 2-4 minutes, building anything significant took hours.) Janus/Ada doesn't do inlining at all, other than of things visible in specifications (expression functions make a significant expansion of what can be inlined -- one of the reasons the idea was invented in the first place, many years ago). If it ever does do inlining of subprograms, it would do it at bind-time, (and mostly automatically). I think Ada's allowing of those extra compilation dependencies caused most compilers to have insanely long build cycles in the early days of Ada, and probably caused a lot of damage to Ada's reputation. As such, this was one of the worst decisions of Ada. (I have to agree it doesn't matter so much anymore, but no one is building Ada compilers from scratch.) > On the other hand, the private part kludge wouldn't be so bad if > the syntax were different: The private part should be a separate > syntactic compilation_unit, with its own with clauses, and should > normally be stored in a separate source file from the visible part. > There's an awful lot of horrible code duplication caused by the > fact that the private part is in the same file as the visible part. > Separating it out into a different file would not prevent the > compiler from looking at it! I still think this is a horrible idea; it certainly would be a complete earthquake for Janus/Ada, which only knows how to process one source file at a time. There would be no way to "look at" such a file when compiling the specification, and thus we'd end up having to create a "specification" file containing no useful information. It would be a total mess (especially as I can't imagine how compilation ordering could be made to work in such a scenario). And this doesn't make any sense when combined with child packages. Once one allows visibility into the private part in some other unit (like a child unit), it's no longer really separate in any way. Perhaps this would make sense in some Ada-like language, but not for Ada. Randy.