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
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a77baf86c187076a
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Garbage collection (was a spinoff of a spinoff of a GA
Date: 1996/10/20
Message-ID: <DzL6J8.JG0@world.std.com>#1/1
X-Deja-AN: 190790140
references: <9610171549.AA07433@most>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-10-20T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <9610171549.AA07433@most>,
W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>You are refuting a claim I didn't make.  My QUERY was, "Since Ada now
>lets us customize garbage collection (or lack of) to each ADT, ...

How do you mean?  GC is, in general, a global issue, and it's not easy
to customize it for particular types.  There are things you can do with
controlled types, but all the schemes I can think of have some major
drawbacks.  Can you explain in more detail what you mean?  (Note: In
most of the programs I write (compilers and the like) there are hundreds
of mutually recursive types -- that is, records containing pointers to
other records and such.)

>...how many
>_Ada_ designers would be willing to pay extra for a reliable transparent
>global GC?" ...

>...I doubt that any would be willing to pay for one that is
>unreliable or non-transparent.

Well, there are a lot of people making a lot of money selling unreliable
software, these days.  :-(

As for non-transparent, well, I want to have some hooks into the GC, so
that I can customize it for particular purposes.  For efficiency, if
nothing else.

>Part of the Ada philosophy (at least for me) is that if something is a
>requirement, I want to see it somewhere in code.  If it isn't a requirement,
>I don't want it cluttering the code AND I don't want it interfering with
>requirements (including cost and schedule requirements).

But memory management is an implementation detail -- it's not likely to
show up in the requirements.  Most programs shouldn't leak storage, or
dereference dangling pointers, despite the fact that the requirements
don't say anything about it.

- Bob