comp.lang.ada
 help / color / mirror / Atom feed
From: "Alex R. Mosteo" <devnull@mailinator.com>
Subject: Re: Ada OOP alternatives?
Date: Wed, 23 Jul 2008 11:25:30 +0200
Date: 2008-07-23T11:25:30+02:00	[thread overview]
Message-ID: <6eobluF83aejU1@mid.individual.net> (raw)
In-Reply-To: 87vdyxftrb.fsf@ludovic-brenta.org

Ludovic Brenta wrote:

> Adam Beneschan writes:
>> On Jul 16, 6:36 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
>> wrote:
>>> "(see below)" <yaldni...@blueyonder.co.uk> writes:
>>> > On 17/07/2008 01:05, in article wcc3am9gytt....@shell01.TheWorld.com,
>>> > "Robert A Duff" <bobd...@shell01.TheWorld.com> 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.




  reply	other threads:[~2008-07-23  9:25 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-15 20:38 Ada OOP alternatives? raould
2008-07-16  0:15 ` Robert A Duff
2008-07-16  6:33   ` Georg Bauhaus
2008-07-16  9:54     ` Alex R. Mosteo
2008-07-16 13:03       ` Dmitry A. Kazakov
2008-07-16 14:07       ` Robert A Duff
2008-07-16 18:11         ` (see below)
2008-07-17  0:05           ` Robert A Duff
2008-07-17  0:43             ` (see below)
2008-07-17  1:36               ` Robert A Duff
2008-07-17 11:07                 ` (see below)
2008-07-17 16:45                   ` Robert A Duff
2008-07-17 12:00                 ` Dmitry A. Kazakov
2008-07-17 16:50                   ` Robert A Duff
2008-07-17 18:56                     ` Dmitry A. Kazakov
2008-07-18 12:54                       ` Robert A Duff
2008-07-18 13:36                         ` Dmitry A. Kazakov
2008-07-17 23:27                 ` Randy Brukardt
2008-07-18 12:45                   ` Robert A Duff
2008-07-18 23:22                     ` Randy Brukardt
2008-07-22 20:32                 ` Adam Beneschan
2008-07-22 22:18                   ` Ludovic Brenta
2008-07-23  9:25                     ` Alex R. Mosteo [this message]
2008-07-22 23:35                   ` Randy Brukardt
2008-07-23  7:56                   ` Dmitry A. Kazakov
2008-07-23 21:04                     ` Robert A Duff
2008-07-24  7:07                       ` stefan-lucks
     [not found]                       ` <5ob7w7usrc74$.kms2e1vqs4k0.dlg@40tude.net>
     [not found]                         ` <48883529$0$18826$9b4e6d93@newsspool2.arcor-online.net>
     [not found]                           ` <ygdmhl22lzh4$.1dx98hja6p2o6.dlg@40tude.net>
     [not found]                             ` <48883f41$0$18829$9b4e6d93@newsspool2.arcor-online.net>
     [not found]                               ` <6i1s0y8eeka.121ek9qcgunha$.dlg@40tude.net>
     [not found]                                 ` <48885757$0$18818$9b4e6d93@newsspool2.arcor-online.net>
2008-07-24 12:48                                   ` Dmitry A. Kazakov
2008-07-25  8:47                                     ` Georg Bauhaus
2008-07-25 13:28                                       ` Dmitry A. Kazakov
2008-07-25 16:24                                         ` Georg Bauhaus
2008-07-25 17:55                                           ` Dmitry A. Kazakov
2008-07-26  5:05                   ` Jeff Koftinoff
2008-07-16 14:03     ` Robert A Duff
2008-07-16 14:29       ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox