Re: put of access type

[Adam Beneschan <adam@irvine.com>]

On Aug 20, 5:18 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
> "Martin Krischik" <krisc...@users.sourceforge.net> wrote in message
>
> news:4a8cea9c$1@news.post.ch...
>
>
>
>
>
> > Randy Brukardt schrieb:
> >> "Adam Beneschan" <a...@irvine.com> wrote in message
> >>news:c9aec6d6-4e9b-4bf6-9586-68a237175c9d@i18g2000pro.googlegroups.com...
> >> ...
> >>> Also, there's no rule saying that an access value has to be an address
> >>> at all.  It's certainly conceivable that an access value may be
> >>> implemented as a reference to some storage pool and an offset into
> >>> that pool, allowing for the possibility that the memory management
> >>> system may just decide to pick up the whole pool and move it to some
> >>> other address, without making any of the access values invalid.
>
> >> I think the Ada 95 definition of storage pools would make this
> >> implementation hard to make work. (Which is unfortunate, it would have
> >> worked fine in Ada 83).
>
> > It still works:
>
> I think you missed my point. The definition of the Allocate function for a
> storage pool returns an System.Address. Moreover, there is no notification
> when the access value returned from Allocate is dereferenced or converted to
> another access type. So if Allocate returns an offset rather than an
> address, the compiler generated code to implement .all and to implement
> conversions to anonymous access type is not going to take that into
> account -- it will think it received a System.Address. So this cannot work
> for any user-defined storage pool.

It could still work using a type like Martin suggested---as long as
the compiler sets up an access type with Pool_Access=False whenever it
is using a user-defined storage pool.  It would use Pool_Access=True
only for the default storage pool.  Yes, that makes it less useful.

More generally, though: My comment assumed that there would be a lot
of compiler support required for an access type that is implemented as
a pool reference plus an offset.  There's no reason that a compiler
that has this support couldn't also add its own rule that it supports
this kind of access type only for storage pools that are descendants
of System.Storage_Pools.Movable_Storage_Pools.-
 Root_Movable_Storage_Pool (with this last child package and type
being vendor-defined).  This type would contain additional operations
that the compiler would depend on to get things right; Allocate would
still return a System.Address, but some new operation defined for
Root_Movable_Storage_Pool would convert that address to an offset, and
the compiler would depend on that operation when setting up an access
type with Pool_Access=True.

A lot of work, certainly, and probably not worth the effort unless
some customer has special requirements.  But my original point wasn't
intended to suggest anything practical, but just to get people
thinking a bit about the *possibility* that an access type doesn't
need to be implemented as an address, and thus to start thinking about
things like that in more abstract ways instead of being tied to low-
level concepts that other languages sometimes make you think in.

                                       -- Adam