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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e80a1497a689d8a5 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Ammo-zilla Date: 1999/10/31 Message-ID: <7vhfar$6u1$1@nnrp1.deja.com>#1/1 X-Deja-AN: 542687729 References: <38120FAF.945ADD7D@hso.link.com> <7uutgd$87h$1@nnrp1.deja.com> <19991024.18033546@db3.max5.com> <38189268.43EB150F@mail.earthlink.net> X-Http-Proxy: 1.0 x40.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Sun Oct 31 13:14:04 1999 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-10-31T00:00:00+00:00 List-Id: In article <38189268.43EB150F@mail.earthlink.net>, Charles Hixson wrote: > I am continually attracted to Ada, however: > The Ada approach to memory management reminds me of the PL/1 > approach, only simplified a bit. I suspect you don't remember PL/1 storage management that well, because the comparison is inappropriate. PL/1 expected to have manual storage allocation, and the design was focussed in that area, and PL/1 is better than either Ada or C++ from this point of view, in particular with respect to the AREA management facilities. Yet another instance of the general rule "PL/1 is not as bad as people think it is" :-) > I suppose that you can say that it's better than > C++, but that's *REALLY* faint praise. There are a lot of > details that I don't fully understand, but this is one of > Ada's weaker aspects. Clearly you don't fully understand it if you say: > e.g., garbage collection is eliminated from the language. which of course is quite bogus. Indeed the design of Ada very much assumed that garbage collection would be implemented, and the design specifically allows for this. One of the reasons that Unchecked_Deallocation has the status it does is that the designers expected that GC would be generally used. Of course the language design does not REQUIRE garbage collection, and indeed it is rather hard to require this in a formal definition, because it is not really part of the formal semantics (storage allocation is part of the implementation semantics, not the language semantics). Basically a language "requires" GC by not providing any other alternative for manual deallocation (as in Algol-68). The issue of GC was most certainly discussed during the Ada 95 design. I tried indeed to insert a statement into the information systems annex saying that GC was required for that annex, but I got precisely ZERO support from anyone else even for that minor step. The issue in requiring GC is whether indeed it is practical to require GC in a language that is intended to be used in very high efficiency compiled environments, and in embedded realtime environments (remember that the two general purpose languages to have embraced GC, Algol-68 and Java, have not created a track record here, Java has yet to prove itself in these two respects). As to why GC has not in fact been implemented in the Ada world, with the exception of JVM based systems like GNAT-for-Java, the answer is very simple: lack of demand. For example at Ada Core Technologies, we get many customers wanting many enhancements, but GC has never shown up on the radar screen even as a minor pip in this set of requests. > The second is the syntax used in "object" declaration. Very > clumsy. Well anyone can find anything clumsy, but I must say this is very odd, why you would think that: x : int; is any less clumsy than int x; is peculiar to me! But perhaps you have your terminology wrong and don't really mean object declaration at all???? > Now I *do* understand that the reason for this approach Actually, as described above, you don't understand the reason for the design here, which is to be completely neutral on GC, and leave it as something that the implementation will provide if it is useful to do so. > I feel relativly certain that if the > language were to be designed today that many things would have > been done differently. You may feel certain, but in fact I think VERY little has changed that would have resulted in a change in design. The one area I can think of is the "with type". Indeed the ARG is now discussing possible language extensions, and what is interesting about this is that these are relatively few significant suggestions on the table. Certainly in the case of garbage collection there is nothing at all to discuss. No one in their right mind is proposing *removing* unchecked deallocation from the language, so the only issue is whether implementors will provide GC. The answer to that is simple, they will provide it if they see potential customers who want it enough to make the effort worth while. Sent via Deja.com http://www.deja.com/ Before you buy.