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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no
	version=3.4.4
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!gatech!hubcap!billwolf
From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.lang.ada
Subject: Re: Collective response to := messages
Message-ID: <3733@hubcap.UUCP>
Date: 4 Dec 88 20:41:37 GMT
References: <4125@enea.se>
Sender: news@hubcap.UUCP
Reply-To: wtwolfe@hubcap.clemson.edu
List-Id: <comp.lang.ada>

>From article <4125@enea.se>, by sommar@enea.se (Erland Sommarskog):
> William Thomas Wolfe (billwolf@hubcap.clemson.edu) writes:
>>     What is needed is a completion of the ADT paradigm, support for
>>     which is the fundamental reason for the "limited private" feature.
>>     Given that one must remember to destroy all non-predefined ADTs 
>>     upon block exit, it is clear that the implications of this paradigm 
>>     were not appropriately considered in the Ada 83 design. 
# 
# With other words, what you want is garbage collection.  
# [...]  I think the reason why garbage collection is not required is that 
# in some applications this is not very desireable from the point of 
# view of performance. Typically you may not want it embedded real-time 
# systems... Another thing is of course the implementation issue...

   No, I do NOT want garbage collection.  Since GC cannot handle the
   problems of circular-list garbage without outrageous time expenditures,
   and for all the other reasons you mentioned above, GC is NOT desirable.
   Furthermore, GC encourages sloppy programming.  I'd be very happy to see
   GC explicitly PROHIBITED.


                                       Bill Wolfe

                               wtwolfe@hubcap.clemson.edu