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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a29f6c543c430f19,start X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: GC - again, :-) Date: 1997/04/29 Message-ID: #1/1 X-Deja-AN: 238376283 Distribution: world Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-04-29T00:00:00+00:00 List-Id: Robert Eachus sez: > > I strongly agree with this. Of course (as you all know by now) I > > would go further and say that GC is really the only good solution > > here. Even if it were only for strings. Finalization and user > > defined assignment are typically going to be rather more expensive. > > The cost of finalization and user defined assignment are > implementation concerns. But in what sense is Ada.Strings.Unbounded > not exactly the "Even if it were only for strings," functionality? Oh, I meant that to apply to GC, as in the only place where GC was actually used. I agree that F/UDA are impl. concerns, but those are still valid concerns. The best that F/UDA can do here is RC and RC is inherently more expensive than tracing style GCs. Even if you avail yourself things such as "non recursive freeing" and deferred counting techniques. > Robert Dewar said: > > > What I think would be a nice compromise is to have a storage pool > > specially for unbounded strings (or similar gizmos) where you got > > GC in that storage pool -- something to keep looking at ... This is definitely something to pursue. What is more, I think you can generalize this notion. I'm working on this sort of thing right now. > This is definitely an area where the language can and should > evolve. Ada.Strings.Unbounded is a nice package to have, but a > generic which exported a Garbage_Collected type would be even more > useful in places: Absolutely. I am working on a whole set of these (related in subsystem hierarchies) which will offer wide ranges of GC options. While you can't do this completely transparently *within* the language (i.e., without compiler support), it is surprising how close you can in fact get. What is more, it is very efficient and very flexible. > generic > type Data(<>) is private; > type Reference is access all Data; > package Garbage_Collected is > > type Collected is private; > > function Create(Contents: in Data) return Collected; > > function Get_Ref(Item: in Collected) return Reference; > > function Contents(Item: in Collected) return Data; > If done right, Get_Ref would probably be a type conversion... In some cases that is exactly correct. In particular, when the collector will work across a class of types this is the most natural approach. Collected needs to be limited as well (OTOH, with proper compiler support that could be relaxed). /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com