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 Path: g2news1.google.com!news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada OOP alternatives? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <462e0cf4-1d53-4918-b30b-dd3d8df90f1b@p25g2000hsf.googlegroups.com> <487d9636$0$6543$9b4e6d93@newsspool3.arcor-online.net> <6e5uq2F5g7n6U2@mid.individual.net> <18maowv5tf52i$.winpalz4hj7p$.dlg@40tude.net> <138raucqw95gm.4bnfy7y43il7$.dlg@40tude.net> Date: Fri, 18 Jul 2008 15:36:28 +0200 Message-ID: <17tobt9v001dx$.1olg7gsbddl85$.dlg@40tude.net> NNTP-Posting-Date: 18 Jul 2008 15:36:28 CEST NNTP-Posting-Host: 79226391.newsspool4.arcor-online.net X-Trace: DXC=nm@FInSf@;3i6K;>iZ]7634IUK\BH3Y2EBl64:6d[L=DNcfSJ;bb[5FCTGGVUmh?4LK[5LiR>kg2I7> X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:1209 Date: 2008-07-18T15:36:28+02:00 List-Id: On Fri, 18 Jul 2008 08:54:54 -0400, Robert A Duff wrote: > "Dmitry A. Kazakov" writes: > >> There are two problems with that. The first one is that the difference is >> not obvious. Why legality check is less than "full compilation", so that >> the delta cannot be left for the binder/linker. The second one is that if >> the delta is sufficient, then the reader should probably become aware of >> it. In short, it is difficult to drive a margin. > > I don't understand. To (e.g.) determine whether a procedure call is > legal, you need to know its name, parameter types, etc. (Whether "you" > is the human or the compiler.) To generate code, you need to know more > -- which register to put the parameter in, etc But call convention could be a subject of specification (choosing pragmas for that was probably a mistake). Register allocation can be postponed (if the architecture supports renaming) etc. It is not obvious why namely the body shall determine such things. > -- and if inlined, what code is in the body. Inlining should not influence the semantics. Thus if the body is not available, the client should still be compilable. >>> The compiler should check legality without looking at other bodies. But >>> it should look at bodies when generating code (at least if optimization >>> is turned on). >> >> But what would you do with dynamically linked libraries, remote partitions >> and other lately bound stuff? > > I don't see what that has to do with organization of the source code. > These things are implemented using "extra" levels of indirection at run > time. E.g. you can't very will inline a call in an executable, and then > expect that updating a shared library used by that executable will > update the call by magic. So don't inline across such boundaries. I don't want such decisions to propagate into specifications. To me it is an implementation detail. If an ability to compile without the bodies is not constant, then something in the specifications shall tell if it is a pure specification or else that the body will be required. I don't like this. It would mean mixing interfaces and implementations. >>... I think that the time of monolithic systems >> is gone. > > I don't think so. Certainly some embedded systems are monolithic, > and should be. Maybe, though, newer embedded systems have to communicate with other systems in the outer world. Anyway, Ada is a general purpose language. I buy some performance loss if it comes to cleaner separation of interface and implementations. Baked sand is cheap... (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de