Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!mcsun!ukc!cam-cl!scc
From: scc@cl.cam.ac.uk (Stephen Crawley)
Newsgroups: comp.sw.components
Subject: Re: List ADT example
Message-ID: <928@scaup.cl.cam.ac.uk>
Date: 29 Sep 89 12:16:33 GMT
References: <917@scaup.cl.cam.ac.uk> <6624@hubcap.clemson.edu>
Sender: news@cl.cam.ac.uk
Organization: U of Cambridge Comp Lab, UK
Lines: 35

I wrote:
>> if you insist that I use a different generic list ADT 
>> (say POINTER_LIST), please explain how it does storage management 
>> without pushing the tricky part (in particular the decision about when
>> reference counts should be incremented or decremented) back to application
>> code.  

Bill Wolfe replied:
> This is the price you pay for wanting to store references instead 
> of objects.  An object can only be in one place at a time.

I read this as a tacit admission that you can't come up with
such a list ADT! 
 
If so, all your arguments about applications not using pointers,
and the hard problems storage management being safely and efficiently
handled by generic ADTs fall apart like a pack of cards.  Sure generic 
ADT's may work for simple cases, but for data structures with multiple 
references the generic ADT can be no more efficient than a modern GC.

If the application programmer wants more efficiency, he could try to
do the storage management himself, using special knowledge about the
application in hand.  But this relies on the special knowledge being 
true knowledge (no mistakes, no mythology), and on the application 
programmer not writing incorrect code that leaks store, or leaves 
dangling pointers, or uses heap nodes after they have been freed, etc.

The GC versus non-GC argument boils down to a tradeoff between correctness 
and reliability on the one hand versus potential for efficiency improvement
on the other.  The correctness and reliability of GC'ed storage management 
is ASSURED.  The potential increased efficiency of non-GC'ed storage 
management is vanishingly small in many cases, and in all but simple cases
depends on non-trivial development effort by applications programmers.

-- Steve