Re: Two ideas for the next Ada Standard

[Jonas Nygren <jonas@joy.ericsson.se>]

Jon S Anthony wrote:
> 
> In article <322D6D79.7317@ehs.ericsson.se> Jonas Nygren <ehsjony@ehs.ericsson.se> writes:
> 
> > the following type of code is often found in Ada:
> >
> > generic
> >    type T is private;
> >    type TA is access all T;   -- this is what I mean with carrying
> > package P is....              -- with you
> >
> > Suppose that we after the instantiation of this package
> > need to do some conversion to the access type passed to P,
> > when e g extending an existing application, using:
> >
> > (2)
> >        generic
> >            type Object(<>) is limited private;
> >        package System.Address_To_Access_Conversions is
> >           pragma Preelaborate(Address_To_Access_Conversions);
> > (3)
> >           type Object_Pointer is access all Object;
> >           function To_Pointer(Value : Address) return Object_Pointer;
> >           function To_Address(Value : Object_Pointer) return Address;
> > (4)
> >           pragma Convention(Intrinsic, To_Pointer);
> >           pragma Convention(Intrinsic, To_Address);
> >        end System.Address_To_Access_Conversions;
> >
> > How do we use Object_Pointer together with our existing access type
> > without conversion. Of course we could reorganise all our code
> 
> OK, that is true.  But this is a very strange example.  Are you saying
> that you've got these sort of access<->system.address conversions
> going on all over the place??  If so, that still sounds like a
> basic/fundamental error.

It was an example I put together since I am not that well versed in 
lingua Ada. It apparently served its purpose - you understood what I
was trying to explain.

> 
> > Further how do one end up with one and only one access type
> > if one have to instantiate multiple packages that declare their
> > own access types.
> 
> Why would you _want_ such an access type????  That just leads you down
> the road to having weird reference problems.  Just like in C/C++...

What I am aiming at is that in Ada you have to plan your code very well in
advance to avoid a lot of conversions. This is all very well for 'release 1.0'!
But once you have to make changes or additions to your code your initial 
beautiful plan probably no longer holds. Then you end up with situations 
similar to what I described above. 

One solution to this could be to provide an 'anonymous general 
access-to-variable type', RM6.1(24), for variables to and not only for 
subprogram formals and discriminants. Perhaps one could use a syntax similar
to T'Class and have T'Access denoting this new subtype. With this syntax we could
have the example from above:

       generic
          type Object(<>) is limited private;
       package System.Address_To_Access_Conversions is
          pragma Preelaborate(Address_To_Access_Conversions);

	  subtype Object_Access is Object'Access;
          function To_Pointer(Value : Address) return Object_Access;
          function To_Address(Value : Object_Access) return Address;

          pragma Convention(Intrinsic, To_Pointer);
          pragma Convention(Intrinsic, To_Address);
       end System.Address_To_Access_Conversions;

Subtypes of type T'Access does not cause any dispatching for a tagged T when
used as formals to a subprogram.

Further, it causes the same implicit conversion to a derived access type for T, eg:

	type TP is new access all T;
	P : TP := My_T_Conversion.To_Pointer(Some_Address);

Assuming My_T_Conversion is an instantiation of the conversion package above.

To cover for the 'anonymous general access-to-constant type' case to we
should introduce an attribute T'Constant_Access with similar semantics as
T'Access.

I believe the add-on of the new anonymous subtypes given by the two attributes
T'Access and T'Constant_Access would really benefit the Ada language and 
improve the maintainability aspects of Ada code.

If these constructs have been up to discussion in the standardisation process
I would be interested in hearing the reasons for refuting them.

/jonas

<snipped out discussion on 'access constant'>

> /Jon
> --
> Jon Anthony
> Organon Motives, Inc.
> 1 Williston Road, Suite 4
> Belmont, MA 02178
> 
> 617.484.3383
> jsa@organon.com