Re: Reading a line of arbitrary length

[bobduff@world.std.com (Robert A Duff)]

In article <JSA.97Mar4154951@alexandria>, Jon S Anthony <jsa@alexandria> wrote:
>In article <dewar.857447653@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>
>> Jon said
>> 
>> <<Because there are areas and cases where the GC should not be simply
>> "transparent".  That it should have some explicit programmer control
>> available.>>
>> 
>> Well there is a contentions statement. I strongly disagree that GC
>> should not be simply transparent, and I do not like the idea of
>> standardizing explicit programmer control, whatever that might be.
>
>Yes, it is.  These are merely points that have been made in GC
>circles.  I'm not _advocating_ them, just trying to point out various
>reason why a "defined standard minimal interface" may be needed.

Well, there are lots of useful performance-tuning hooks that are
supported by many existing garbage collectors.  If one were
standardizing the existence of GC, it's not clear whether (some) such
hooks should be standardized as well.  Probably performance-tuning hooks
are "transparent" in Robert's view, and I would agree, but the
programmer would still like to know how to spell the "Please GC now"
command, for example.

There are some interesting interactions between finalization and GC.
The simplest answer is that any object with controlled parts is "live",
so the GC can't collect it.  But that's not what people want, I think.
At least not all the time.  (Maybe only for non-limited controlled
things?)  People probably want the GC to finalize things just before
reclaiming their storage.  But this opens up various issues: What if the
Finalize routine takes an otherwise-dead object, and resurrects it by
planting a pointer to it somewhere?  What if the Finalize routine calls
a non-reentrant procedure, and the GC decides to call Finalize at an
embarrassing time?  Are there any constraints on the order in which
Finalize routines get called in a case where several heap objects become
dead at the same time?  A standard for a GC'ed Ada would certainly need
to address these issues.

Somebody else mentioned the other area in which GC is not transparent:
interfacing to other languages.  Garbage collection is a global problem,
so if just one small part of your program is written in, say, C, then
the programmer needs to know whose responsibility it is to deal with
pointers from the C side to the Ada side.  Is the GC conservative?  Or
does the user have to ensure that any such pointer is duplicated on the
Ada side?

The above is talking about an imaginary universe in which Ada 95
requires garbage collection.  There's also the issue of what it means to
"require" GC -- one would need a much more specific (and complicated)
model of storage usage.  Or else one would need to rely on untestable
"requirements", which has worked fine for Lisp and Eiffel and lots of
others.

- Bob