User-defined access dereference

["Stanley R. Allen" <u384k@gsde.hou.us.ray.com>]

Language design.

In the last couple of years I've had a number of situations arise in
which it would be very convenient to be able to replace the dereferencing
of a pointer object with a function of my own.  In at least one case, I
was in enough need of doing this and knew that the dereferences were limited
to a single (but very large) package, that I felt it was worthwhile to create
a special 'dereference' function and systematically replace all implicit and
explicit uses of ".all" with a call to my function.  There were about 350
dereferences which had to be changed.  It would have been very nice and less
error-prone if it had been possible to redefine the dereference. (The error-
proneness of this change was due to the fact that, if some derefs were missed
then the code would still compile and execute since the original implicit and
explicit ".all"s were valid Ada text -- you just would not know that it failed
until it was 'too late'.)

This kind of thing has cropped up a number of times in our large, long-lived
project, because we are making heavy use of shared memory.  The package
described above was modified as stated because of the need to define pointer
values which were not really addresses, but offsets within shared memory
segments.  The dereference operation had to do more that retrieve the value;
it was necessary first to compute the actual address using the base virtual
address and the offset.  

Now we are faced with another situation in which it would be nice to replace
".all".  This time, there are over 10,000 dereferences in over a million lines
of code, so it's out of the question to do to this code what was done to the
other code before.  (The latest issue is the need to error-check each reference
because it's possible for 'remote' references to have recoverable point failures
in a what is essentially 'reflected memory' for a Linux cluster.)

I haven't been able to track down the reasons why user-defined dereferencing
was not permitted for Ada 95 (I'm guessing it was considered).  Package
System.Storage_Pools already provides the capability to define your own
storage allocation and deallocation for a particular access type, so it seems
reasonable that a user-defined dereference would also be associated with a
storage pool.

I've been trying to play with this idea for an hour or so, and came up
with this:

    Pool : A_Storage_Pool_Type;

    type Accessor is access Object;
    for Accessor'Storage_Pool use Pool;
    function De_Ref (P : in out A_Storage_Pool_Type; A : Accessor) return Object;
    for Accessor'Dereference use De_Ref;     -- not Ada 95

The compiler would recognize that all dereference operations on this type
would translate into a call to this function.

Any thoughts?

--
Stanley Allen
mailto:Stanley_R_Allen-NR@Raytheon.com