🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sw.components
Article #111

Vagueness [was Re: Garbage Collection & ADTs]

#111
From: Thomas Maslen
Date: Thu, 21 Sep 1989 20:00
59 lines
3689 bytes
In the last week or so there has been an interesting, er, discussion on
the desirability of GC in production code.  Bill "ADA is the one true
way" Wolfe and perhaps Anton Rang have argued the negative case, while
Ian Hopper, Scott Henninger, John Gateley, Steve Tynor, Rob MacLachlan,
Stephen Crawley, Ted Dunning and Ralph Johnson have been on the
affirmative [my apologies if I've mis-characterized anyone's position].
No prizes for guessing my biases:  I think the people arguing for GC
have the right idea.

The paragraph above added exactly no technical content to this
discussion.  What we need is something that does.  If we're to have
any hope of convincing the ADAholics that maybe, just maybe, languages
need GC in order to be useful, we need a crisp example of a problem
that:
      -	requires various unrelated parts of a program to use one
	instance of an ADT (either because it's too large to copy, or
	because we really do want updates to apply to the one
	instance),
      -	doesn't have any obvious point at which we can say "we're sure
	we've finished with it now, but we definitely couldn't have
	got rid of it much earlier",
      -	has sufficiently stringent efficiency requirements that we
	can't pass around magic numbers, or whatever it was that
	Bill W was proposing a few days ago, which have to be
	translated before we can actually use the ADT,
      - is sufficiently tricky that we can't rely on the programmer
	magically remebering to "do the right thing",
      -	is arguably representative of a non-trivial class of real
	problems.
I don't have such a problem handy, just a gut feeling that the insides
of real compilers are rich with suitable examples.  Any volunteers?
If nobody has a decent example, then maybe Bill W has a point.

Since this is likely to involve non-negligible volumes of code, and
some of us try to digest lunch while reading this group, I'd like to
suggest that E-mail may be more appropriate than clogging up the
group.

Next, a side bet:

In article <6530@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
[mucho stuff deleted]
>   In keeping with the general principle that application programmers
>   should not be using pointers; appropriate ADTs should be used instead. 
[more stuff deleted]
>   The rule is simple: Leave the use of pointers to ADT implementors,
>   and simply reuse the code they produce.  Exploit to the absolute 
>   fullest the hard guarantees (proper space management, serializability, 
>   recoverability, concurrent processing, etc.) that the ADT implementors
>   worked so hard to provide you with, and thy Manager will be pleased.

My guess is that any ADA solutions we see to my hypothetical problem
will involve auxiliary "appropriate ADTs" which are just limited
private types containing a pointer to the reference-counted real ADT.

Finally, has anyone made use of the (Boehm et al) GC-for-C that was
recently posted to comp.sources.unix?  Any comments?

Thomas Maslen					    maslen@polya.stanford.edu
Technical Details
Message-ID: <11885@polya.Stanford.EDU>
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!watmath!att!dptg!rutgers!apple!agate!shelby!polya!Neon.Stanford.EDU!maslen
References: <900@scaup.cl.cam.ac.uk> <6530@hubcap.clemson.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!utgpu!watmath!att!dptg!rutgers!apple!agate!shelby!polya!Neon.Stanford.EDU!maslen
From: maslen@Neon.Stanford.EDU (Thomas Maslen)
Newsgroups: comp.sw.components
Subject: Vagueness [was Re: Garbage Collection & ADTs]
Summary: Need a real example, not higher-level agruments
Message-ID: <11885@polya.Stanford.EDU>
Date: 21 Sep 89 20:00:40 GMT
References: <900@scaup.cl.cam.ac.uk> <6530@hubcap.clemson.edu>
Sender: USENET News System <news@Polya.Stanford.EDU>
Reply-To: maslen@Polya.Stanford.EDU (Thomas Maslen)
Organization: Stanford University, Computer Science Dept.
Lines: 59