GC - again, :-)

[jsa@alexandria (Jon S Anthony)]

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