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,ab66185f2bca0483 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-18 14:02:43 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!news.uunet.ca!nnrp1.uunet.ca.POSTED!not-for-mail From: "Eric" Newsgroups: comp.lang.ada References: <2dbd76f3.0211130203.7d2d14fd@posting.google.com> <2dbd76f3.0211140126.5d233e41@posting.google.com> <3vb7tug4h99mmalcn0l5ul18cu0ui6i458@4ax.com> <6bd9tuc40p68a86rlur3hai1qlv54i8985@4ax.com> Subject: Re: Extension of non-limited type needs limited component X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <7sdC9.202520$C8.508654@nnrp1.uunet.ca> Date: Mon, 18 Nov 2002 17:48:18 -0400 NNTP-Posting-Host: 24.224.162.12 X-Trace: nnrp1.uunet.ca 1037656963 24.224.162.12 (Mon, 18 Nov 2002 17:02:43 EST) NNTP-Posting-Date: Mon, 18 Nov 2002 17:02:43 EST Organization: WorldCom Canada Ltd. News Reader Service Xref: archiver1.google.com comp.lang.ada:31075 Date: 2002-11-18T17:48:18-04:00 List-Id: "Robert A Duff" wrote in message news:wccbs4q8oys.fsf@shell01.TheWorld.com... [SNIP]> > By the way, have you read the AARM annotations that explain why we > didn't allow user-defined ":=" procedures? We certainly wanted to, > but we couldn't figure out how to make it work, so we invented Adjust, > which is not as powerful. I'd be interested in hearing better ideas > (even though it's probably too late). > > - Bob Hi, (I have reproduced the relevant annotation at the end.) The following solutions come to mind (I haven't gone through all the possible ramifications and potential problems): 1. (The example in the AARM specifically refers to mutable, unconstrained record targets.) Consider an 'operator' "<-" (which is the current Ada implemented 'move of value') to disambiguate the procedure ":=". So the present non-limited controlled implementation of procedure ":=" looks like: procedure ":="(Target : in out TYPE; Source : in TYPE) is [anonymous_object : TYPE <- Source;] begin Finalize(Target); Target <- anonymous_object; [Finalize(anonymous_object);] Adjust(Target); end ":="; Since finalization should (must) always be done before the target is overwritten, Finalize and "<-" (plus any other constraint checks) can be combined into the attribute Uncontrolled_Assign so that the above looks like: procedure ":="(Target : in out TYPE; Source : in TYPE) is [anonymous_object : TYPE <- Source;] begin Target'Uncontrolled_Assign(anonymous_object); [Finalize(anonymous_object);] Adjust(Target); end ":="; Thus: a user defined implementation of ":=" could be: procedure ":="(Target : in out TYPE; Source : in TYPE) is New_Source : TYPE [<- ...]; -- Finalized on procedure return begin -- Fiddle with New_Source based on both Target and -- Source (and constraints) Target'Uncontrolled_Assign(New_Source); -- Fiddle with Target (probably unneeded) end ":="; Note that this use of Uncontrolled_Assign would probably require a recheck of any constraints. The only problem of significance that I see is the initiation of New_Source and how to prevent an infinite loop if it is initiated (using ":=") to Source. Also, as ":=" is defaulted to call Adjust, current code would not need be rewritten. 2. Change the assignment sequence from: anonymous_object <- Source Finalize(Target) Target <-anonymous_object; Finalize(anonymous_object) Adjust(Target) To: anonymous_object <- Source other_anonymous_object <- Target Finalize(Target) Target <- anonymous_object; Finalize(anonymous_object) Adjust(Target, other_anonymous_object) -- ***** Finalize(other_anonymous_object) with Adjust taking a second 'in' argument. This would allow Adjust to make use of the original value of Target. Not as useful as the above, but I have already met code where it would be useful. Here is the annotation (reformatted from Section 7.6 of the AARM): Reason: An alternative design for user-defined assignment might involve an Assign operation instead of Adjust: procedure Assign(Target : in out Controlled; Source : in out Controlled); Or perhaps even a syntax like this: procedure ":="(Target : in out Controlled; Source : in out Controlled); Assign (or ":=") would have the responsibility of doing the copy, as well as whatever else is necessary. This would have the advantage that the Assign operation knows about both the target and the source at the same time - it would be possible to do things like reuse storage belonging to the target, for example, which Adjust cannot do. However, this sort of design would not work in the case of unconstrained discriminated variables, because there is no way to change the discriminants individually. For example: type Mutable(D : Integer := 0) is record X : Array_Of_Controlled_Things(1..D); case D is when 17 => Y : Controlled_Thing; when others => null; end D; end record; An assignment to an unconstrained variable of type Mutable can cause some of the components of X, and the component Y, to appear and/or disappear. There is no way to write the Assign operation to handle this sort of case. Forbidding such cases is not an option - it would cause generic contract model violations. Michael Borek "Death before Dishonour; Beer before Lunch" Michael Borek Software Services http://users.eastlink.ca/~borekking/professionalhome.html