Re: Better support for garbage collection

[Brian Rogoff <bpr@shell5.ba.best.com>]

Sorry for the late reply, there's just no telling when messages arrive on
my news server :-(

On Fri, 16 Mar 2001, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> > IMO, just tacking on GC to an existing language doesn't make it very 
> > much better.
> I think it does. 

I disagree, oh well. 

> >... When the language designers design a language with the 
> > expectation of GC, they may then support some higher level features, 
> > like first class functions, which do make the language much better. 
> 
> I don't see the huge advantage of first class functions.

How about the fact that I can build functions by partially parameterizing
a given function? I assume you know what I mean here, I have a function
with n arguments and I can build a new function by calling that function
with some arguments fixed? I do that all the time. I can use that trick to
defer evaluation and simulate lazy evaluation in an eager language. 

> I *do* see the advantage of downward closures.

Well, at least you're half right ;-).

> Whenever I have asked for examples showing the usefulness of full
> closures, most folks produce examples of downward closures.
> (I've had this argument here, and also on functional language
> newsgroups, where you would expect to find more knowledge about
> closures.)

The most mundane (and convincing) is just parameterization. I must have 
missed your posts on the FP newsgroups. 

> I also see a *disadvantage* of full closures: Information that is local
> to a procedure can "escape", which seems to make code harder to
> understand.  It seems to me that if you want to pass a function (plus
> its environment) outward, you should instead explicitly create a tagged
> object on the heap, to make it clear that this thing survives after the
> end of the current procedure.

I disagree again. This kind of heavyweight simulation dissuades anyone 
from using upward funargs at all!

> In any case, surely GC is useful independent of closures: it can go a
> long way toward getting rid of dangling pointer bugs and storage leak
> bugs.

Yes, I just said I didn't see "very much" gain from GC, not "no gain". 

> > Ada is far less leaky than C family languages, so the win of just 
> > adding a GC seems smaller for Ada. 
> 
> I would say "somewhat less leaky".

IME, *far* less leaky. 

> > Of course, you still have designers who blow it by putting in GC and 
> > omitting such features, but then after a few years they realize they 
> > screwed up and hack in such things. Java and Eiffel are good examples 
> > of such screw ups (nested/anonymous classes and "agents"). 
> 
> Tell us about the Eiffel case.  The version of Eiffel I know had no such
> thing.

ISE is still working on it. Check out their web page, look up "agents" and 
"iterators". 

> > > (I find the idea of conservative collection somewhat distasteful,
> > > but it does seem to work in many cases.)
> > 
> > Maybe if it were called a "probabilistic garbage collector" you wouldn't 
> > mind? ;-)
> 
> ;-)
> 
> > Didn't Norman Cohen have a proposal for a storage pool extension that 
> > provided some support for garbage collection? I thought so, but my neural 
> > garbage collector seems to have reclaimed that hunk of my brain...
> 
> I don't remember that.
> 
> I do remember Norm participating in the above "are full closures useful"
> argument.  He's the only one I recall who produced an example that
> wasn't "downward".  I was only half convinced by his example.

That was not a convining example (Ackerman?) though it was very pretty. 

-- Brian