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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8591be732d0fce98 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!news.osn.de!diablo2.news.osn.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Alex R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Ada OOP alternatives? Date: Wed, 23 Jul 2008 11:25:30 +0200 Message-ID: <6eobluF83aejU1@mid.individual.net> References: <462e0cf4-1d53-4918-b30b-dd3d8df90f1b@p25g2000hsf.googlegroups.com> <487d9636$0$6543$9b4e6d93@newsspool3.arcor-online.net> <6e5uq2F5g7n6U2@mid.individual.net> <87vdyxftrb.fsf@ludovic-brenta.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: individual.net 4rW2QA3lGvmbvgTUFeq8KAVuee700nWi3YLXo+XaY1pNgNYU4= Cancel-Lock: sha1:v7C8Saj3K57G73ZzP0lbyQHuAWU= User-Agent: KNode/0.10.9 Xref: g2news2.google.com comp.lang.ada:7007 Date: 2008-07-23T11:25:30+02:00 List-Id: Ludovic Brenta wrote: > Adam Beneschan writes: >> On Jul 16, 6:36 pm, Robert A Duff >> wrote: >>> "(see below)" writes: >>> > On 17/07/2008 01:05, in article wcc3am9gytt....@shell01.TheWorld.com, >>> > "Robert A Duff" wrote: >>> >> I'd still rather eliminate private parts altogether. >>> >>> > How would you do that while allowing ADT clients to access objects >>> > directly (i.e. not via a pointer a la Java)? >>> >>> I'd have the compiler take a peek at the body when compiling the client. >>> After all, that's what Ada compilers already do for pragma Inline. >>> And I think incremental compilation can be a big win. >> >> You know, I'm still dreaming of the day when we can get rid of our >> current "object file" model of compilation, or whatever it's called, >> in which we assume that the compiler is going to compile individual >> library units into object code almost completely, so that the >> process of building the complete executable from all of its >> compilation units (linking) consists mostly of just patching >> addresses. This technology has been around for a long time, but why >> are we still stuck with it? It seems to me that it ought to be >> possible to have a compiler that compiles individual source files >> into some sort of "intermediate" representation that is not quite >> machine code, and then when the complete executable is built, the >> intermediate code is then used to generate the actual code. This >> final process wouldn't be as fast as a linker that just patches >> addresses; for a large program, when one compilation unit changes, >> the final build would have to reprocess all of the compilation units >> that go into the program. But it seems like it ought to be possible >> to design an intermediate representation that could be converted >> fairly easily with a minimal amount of processing, so that given the >> speed of today's computers (as compared with 1983), this extra >> processing wouldn't be much of an issue. This would make it >> possible to dispense with private parts and put all of the "private" >> stuff into package bodies. And if the language rules make privacy >> leakage impossible, then all legality errors would still be caught >> at "compile" time; there shouldn't be any case where an error isn't >> found until "final build". >> >> But I realize that I'm just dreaming... > > I'm not so sure you're dreaming. Isn't this how LLVM works? And I > think one of the proprietary Ada compilers also works that way with a > somewhat "standard" intermediate representation. Also, the current trend to do inlining at link time I guess is somehow related with this.