From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,b47b15fda2aeb0b2 X-Google-Attributes: gid103376,public From: Jonas Nygren Subject: Re: Two ideas for the next Ada Standard Date: 1996/09/07 Message-ID: <323153E7.2CDA@joy.ericsson.se> X-Deja-AN: 179057132 references: <50aao3$3r88@news-s01.ny.us.ibm.net> content-type: text/plain; charset=us-ascii organization: Ericsson mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 2.0 (Win95; I) Date: 1996-09-07T00:00:00+00:00 List-Id: Jon S Anthony wrote: > > In article <322D6D79.7317@ehs.ericsson.se> Jonas Nygren 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 > /Jon > -- > Jon Anthony > Organon Motives, Inc. > 1 Williston Road, Suite 4 > Belmont, MA 02178 > > 617.484.3383 > jsa@organon.com