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,b8b8a54001adc4d2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Possible Ada deficiency? Date: 09 Jan 2005 15:10:20 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <1104516913.718856.94090@z14g2000cwz.googlegroups.com> <1104544963.930877.75170@c13g2000cwb.googlegroups.com> <1104595073.731663.180100@c13g2000cwb.googlegroups.com> NNTP-Posting-Host: shell01-e.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1105301421 15691 69.38.147.31 (9 Jan 2005 20:10:21 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Sun, 9 Jan 2005 20:10:21 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: g2news1.google.com comp.lang.ada:7591 Date: 2005-01-09T15:10:20-05:00 List-Id: Nick Roberts writes: > Robert A Duff wrote: > > The main thing is that the compiler needs to know the size of a private > > type in order to allocate things, unless it treats all private types as > > dynamic-sized, which would be annoying -- you shouldn't have to pay an > > efficiency cost to get the benefits of encapsulation, information hiding, > > etc. So if the full type were in the body, the compiler would have to > > look at the body (at least in optimizing mode). > > I agree completely. Well, I don't. ;-) I said "at least in optimizing mode", implying that the compiler could choose a compile-time-efficient method of record layout (not looking at the body) or a run-time-efficient one (looking at the body), depending on some optimization switch. But now that I think about it, that might not be a good idea. It might be disconcerting to programmers if record layout changes depending on compiler switches, especially if those records are written to files. Hmm... > I don't think it would have to be that fancy. Well, I don't think incremental compilers are trivial. (I've built them, but not for Ada.) But I agree they are feasible and desirable. The granularity of incrementality need not be very fine in order to get the benefits. >... A simple but effective > strategy would be for the compiler to remember the size of each private type But it's not just the size of private types and a couple of other things. It's any piece of information that affects the generated code. This depends on how much optimization is done, but it could include all kinds of things: alignment, whether a type contains tasks, whether a type has finalization, whether a parameter is small enough to pass in a register, whether the value of a deferred constant is known at compile time, and if so, the value, whether various dope (such as array bounds) is known at compile time, and if so, the values, &c. And if you forget one such item, you've got a very nasty compiler bug: rebuilding misses some changes to your code. The source-based compilation model of GNAT and AdaMagic seems much simpler, although much less efficient at compile time. Another problem with moving private-part stuff into the body would be elaboration order problems. The freezing rules wouldn't work at all. (The freezing rules are an abomination, though, and I wouldn't mind a total redesign of that area.) But the point is, you need to prevent things like creating an object of a given type before its full type has been elaborated. We do run-time checks for subprograms, which is somewhat ugly in my opinion; I suppose that could work for private types, too. Another issue: I wonder if it would wreak havoc with representation clauses. > I suppose it is slightly idle speculation (not that I'm averse to idle > speculation ;-) but I think we all have our own ideas about how the perfect > language should have been. I've got lots of ideas. ;-) And I think programming language design is in its infancy. There may never be a "perfect" language, but we can do a lot better than any existing language. >... (By the way, on a historical note JDI stands for > 'Jean Ichbiah', the leader of the team who developed the Ada 83 standard.) Yes, thank you. I shouldn't have assumed everybody knows that. And Tucker was the leader of the Ada 95 design team, of which I was a member. > One idea would have been to eliminate the principle of having to declare > things in advance of their use. Ada takes this approach to goto labels, in > fact. When something was used, for example a procedure call: > > Foo(Bar,Hum); > > the compiler would simply note the need for an object Bar, and an object > Hum, and a procedure with profile Foo(Bar'Type,Hum'Type). > > At the end of the compilation process, the compiler would say "Was there a > declaration of an object Bar?" Assuming there was, its type must now be > known, let's say T1. The compiler would do the same thing with Hum, let's > say its type was T2. Then the compiler would say "Was there a declaration of > a procedure fitting profile Foo(T1,T2)?" If there wasn't, or if there was an > ambiguity, it could report the error. Nick, I don't know how to say this politely: You're stark raving mad! ;-) If Foo is overloaded, the above mechanism would be complicated beyond belief. And note that Bar could be a parameterless function. If Ada allowed forward references, a two-pass semantic analysis algorithm could work reasonably. But the above-suggested method seems completely infeasible to me. Anyway, I think the main reason for disallowing forward references was to make code more readable, not just to make the compiler's life easier. Allowing forward references also introduces elaboration-order problems, and circularity problems. Probably solvable, but more rules would be needed. For example: type T1 is range 1..T2'Last; -- currently illegal type T2 is range 1..T1'Last; > This way, package specifications wouldn't be needed. You would actually have > a private part in the body, which would contain the declarations of things > not to be exported. > > Of course, this approach didn't fit the prevailing compilation model of > those days (the 1980s). Just an idle thought. Package specs are not (primarily) for the benefit of the compiler. They are there to provide a contract -- a definition of the interface between a package and its clients. The visible part is a Good Thing. It's just the private part that seems kludgy. - Bob