Re: Two ideas for the next Ada Standard

[jsa@alexandria (Jon S Anthony)]

In article <323153E7.2CDA@joy.ericsson.se> Jonas Nygren <jonas@joy.ericsson.se> writes:

> 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.

Yes, but it still doesn't get at what seems the very odd situation that
you are having to do this sort of thing a lot - even a little is odd.

But, as long as this particular case was used, I actually have a question
for Bob (if he is reading this...)  Why didn't the generic signature for
System.Address_To_Access_Conversions include the access type?  What subtle
or even obvious thing am I missing?


> > >        generic
> > >            type Object(<>) is limited private;
Why not this?:   type Object_Pointer is access all Object;
> > >        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;


> 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.

Hmmm, I have never had this sort of problem.  So far, the Ada95 work
I've been doing does not seem to have this weakness either.  So, I
guess I just don't understand what you are doing...


> 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:

I _think_ Bob Duff would agree with you, but I still don't see this
as a problem so would not agree with it.  In fact, I see the current
situation of not having this as a _good_ thing not just a "shrug".


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com