Re: Ada and GC. Was: Re: Ammo-zilla

[Charles Hixson <charleshixsn@mail.earthlink.net>]

Well... I was thinking that within the {Pragma GC} packages at a minimum
the compiler should be able to readily determine which items were
pointers and which were not.  This would put contraints on type casts
(generally a good thing anyway, even if they are sometimes needed), etc.

Actually, I was thinking of imposing even stronger limitations, (only
manage storage allocated within the package, pass return values out as
function values, but no direct access allowed, no publicly visible
access variables, any child packages to be subject to GC constraints,
etc.).  Even if the packages are limited in this manner, most of the
advantages of GC can be obtained.  If they aren't all needed, then so
much the better.

The idea here is, when one wants to make use of an efficient GC, then
one adopts such constraints as are necessary to make it easy and
efficient.  But one is able to freely link it to other sections of code
that don't have those constraints, so that one can do the parts that it
would be difficult to do in the limited framework in a more liberal
environment.  One just needs to be much more careful with allocated
storage when not inside the GC section of the code.  And, yes, their use
of memory would be nearly disjoint.  But this would allow much simpler
algorithms to be used for lattice memory structures, etc.  And would
allow most of the code to be written in the normal manner.  I may feel
that code would tend to migrate to the GC section, but this would not be
a necessity, and certainly the non-GC sections of the code could be
expected to be faster.


Robert Dewar wrote:

> In article <381F7FFA.FFF5A906@mail.earthlink.net>,
>   Charles Hixson <charleshixsn@mail.earthlink.net> wrote:
> > This would allow dynamic constructions that were isolated into
> separate
> > packages to co-exist with their more consicously manipulated
> brethern
> > within the same program.
>
> I don't see how this will help at all unless you partition
> memory into sections that cannot contain mutual pointers ...
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.