Re: Ammo-zilla

[Robert Dewar <robert_dewar@my-deja.com>]

In article <38189268.43EB150F@mail.earthlink.net>,
  Charles Hixson <charleshixsn@mail.earthlink.net> 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.