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-Thread: 103376,8591be732d0fce98 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada OOP alternatives? Date: Fri, 18 Jul 2008 18:22:18 -0500 Organization: Jacob's private Usenet server Message-ID: References: <462e0cf4-1d53-4918-b30b-dd3d8df90f1b@p25g2000hsf.googlegroups.com> <487d9636$0$6543$9b4e6d93@newsspool3.arcor-online.net> <6e5uq2F5g7n6U2@mid.individual.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1216423386 4079 69.95.181.76 (18 Jul 2008 23:23:06 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 18 Jul 2008 23:23:06 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5512 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 Xref: g2news1.google.com comp.lang.ada:1222 Date: 2008-07-18T18:22:18-05:00 List-Id: "Robert A Duff" wrote in message news:wcc63r3pdi7.fsf@shell01.TheWorld.com... > "Randy Brukardt" writes: > >> "Robert A Duff" wrote in message >> news:wccy741fg0z.fsf@shell01.TheWorld.com... >>> "(see below)" writes: >>> >>>> On 17/07/2008 01:05, in article wcc3am9gytt.fsf@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. >> >> That's what *some* Ada compilers do. Personally, I think that violates >> the >> spirit of Ada (Ichbiah version) by adding unnecessary compilation >> dependencies. Indeed, I think the whole design of pragma Inline is wrong >> in >> Ada. > > Not sure what you mean. In order to inline a call, the compiler has to > look at the body of the callee -- no way around that. And when the body > of the callee changes, the code at the inlined call site needs to be > changed. It's certainly annoying when unrelated changes in the > same file where the inlined body lives trigger recompilation of the > world. And that is avoidable via incremental compilation. > > As to the inline violating spirits, Ichbiah presumably designed whatever > "spirit" you mean, and also designed pragma Inline, so are you saying > Ichbiah violated the spirit of Ada? It's certainly possible... > > Anyway, what's your idea about how the design of inline should be? I believe that pragma Inline should either not exist at all (in favor of a more general way of specifying optimization parameters), or just be a hint to the compiler. It should surely should not have a semantic effect of any kind. And I agree with you about the multiple modes. Indeed, the grand design for Janus/Ada is exactly that. The "conventional compilation" mode is for getting executables fast (for debugging and development). The "production compilation" mode would (it never got built because we didn't have enough memory back then) push all optimization and code generation as late as possible - at least as late as link-time. (Aside: that's effectively what Java does, although Just-in-Time compilation probably is going too far for many uses.) >> ... >>> We're just talking about the size of the type, really -- you say >>> "access objects", but clients can't access the record components >>> of a private type -- all they can do is declare objects and >>> pass them around. >> >> Ugh. That's surely not true, either, unless you insist on allocating all >> objects contiguously. > > I'm confused. I don't see how allocating noncontiguously contradicts > what I said -- which part were you referring to. You need to know a lot more than just the size of the object in order to create a non-contiguous object: for instance, you need to know the dependences of the subparts on the discriminants in order to allocate memory for those subparts. That has to be done before construction, else you won't have anywhere to evaluate the constructor expressions. ... >> There are a lot of different ways to design a compilation system, and one >> thing we've clearly learned from the ARG is that making any sort of >> assumptions about how "everyone" is going to implement something are >> almost >> certainly wrong. > > Well, I suppose so, but "everyone" has to implement whatever language > they're implementing in a way that is correct. (E.g. using a one-pass, > bottom-up overload resolution algorithm is just plain wrong, for Ada.) > > And it is the responsibility of the language designer to make sure that > there is at least one viable implementation strategy -- not to make sure > that every imaginable implementation strategy is viable. Here I think I disagree, at least to a point. A good language (intended to have a long life!) allows a broad array of potential implementation strategies, because things that seemed like a good idea in 1980 aren't today. To take a specific example. You've been talking about incremental compilation. One thing that Pascal always used to harp on is how much that depends on not breaking privacy. It would be trivial to define a language so that incremental compilation wasn't practical; but it surely would still have "one viable implementation strategy". So I think a good language design has to go beyond "one viable implementation strategy" to allow as many as practical. (Of course, there better be at least one implementation available, and knowing the existence of that is important.) Randy.