[gclist] Language behaviour wrt GC

[Jon S Anthony]

Henry writes:

> > Geert Bosch wrote:
> > > 
> > > It's a little bit sad that a modern language [Ada-95] that actually
> > > *needs* a garbage collector if you don't want to use
> > > Unchecked_Deallocation, has no good [Ada-95] implementations that have
> > > one. As a small survey has indicated the main property of such a
> > > collector would be safety, which is why not m any people are interested
> > > in a conservative collector.
> > 
> > I think the main property would be ease of development and maintenance. 
> > A conservative collector would be quite safe enough for most of the
> > applications I'm interested in.
> > 
> > Your surveyees have tunnel vision, IMHO.
> > -- 
> > Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
> 
> Having spent some time in the Ada world, I tried to understand what their
> concerns were.

Well, as a commercial concern using Ada(95) by choice, I don't really
understand this "old think" either.  But it seems vendors are being
sucked in by only looking at a preexisting customer base.  Not what I
think is actually a rather large potential base.  I only have
anecdotal evidence of this, but one thing that does come up in these
discussions with "potentials" is the lack of implementations with GC.


>  Part of the problem with Ada is that it is no longer conceived by
> the Ada world as a 'general purpose' language (whatever that means),
> but has retreated into being a 'controller' language for embedded
> real-time systems

This is _partly_ what I mean by old think.  In fact, Ada seems to be
used in many other circumstances, but that is irrelevant to the
apparent perception in those circles that GC is irrelevant (at best)
or just plain bad (at worst).

We're certainly not using it for controller stuff (or anything like
that) and a GC would be most welcome.  A fact that I have stated and
used in arguing for GC implementations in "Ada circles".


> (never mind the fact that it isn't particularly good for that
> purpose, either :-).  For example, I understand that some of the
> systems of the Boeing 777 are programmed in Ada, but Boeing and many
> DoD folks use a 'stripped-down' Ada in which dynamic allocation and
> exception-handling are disallowed.

Actually, most of it is.  But it is equally true that in "hard
realtime" cases, the required predictability does not seem to be
available in current GC - despite your papers to the "contrary".  So,
in _any_ such exercise using _any_ implementation language, the
typical thing is to either a) have no dynamic allocation at all or b)
take complete control of it within the application.  So, it is hardly
surprising that this is true in the Ada cases as well.


> In some of other applications, a traditional real-time OS (not
> written in Ada) partitions and manages the memory using
> memory-mapping HW, and a somewhat traditional time-slicing multiple
> process approach, so Ada's vaunted synchronization primitives are
> rarely -- if ever -- used.

This is basically obsolete with Ada95 and simply irrelevant here in
any case.


> If you do a search of the Ada repository, you will find that most,
> if not all, of the 'pretty-printers' for Ada use a C-based parser,
> so Ada cannot even parse itself!

Oh come on - this is silly (and either obviously true: no _language_
can parse itself; or obviously untrue: such parsers written in Ada
exist and are freely available - e.g., just take the GNAT lexer and
parser).  Either way, it is irrelevant to this list.


> The bottom line is that most in the DoD community wish that Ada would
> simply go quietly away, so they could go back to hiring off-the-shelf
> college graduates and use off-the-shelf $99 C/C++ compilers.

Who knows what these people want.  But you can get $99 Ada compilers
too.  Or free ones.  Shrug.  What I would like is to have a high
quality one like ObjectAda or GNAT _with_ a GC.  So, I am with Fergus
on this.

/Jon