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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dd23af7a2f4f9e7c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-02 17:56:25 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.mathworks.com!wn11feed!worldnet.att.net!199.45.49.37!cyclone1.gnilink.net!small1.nntp.aus1.giganews.com!border3.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 02 Jan 2004 19:56:24 -0600 Date: Fri, 02 Jan 2004 20:56:23 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Mutable parameter of a function (long ago was: Re: What evil would happen?) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.34.214.193 X-Trace: sv3-JMepjsiEgX3ct8fDw53wKlDJtRFnOVwnttdiO7cY9OlmlXNV5tUPwAWMXT/P7i5dQhIECJ8TD/caeog!LzbMbBHsKPe+eYo1xqPkZ6WyFlRWj/Tvk0qmF7DnYOzZtuRLu/0HahWCi+EU6A== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:4058 Date: 2004-01-02T20:56:23-05:00 List-Id: Alexandre E. Kopilovitch wrote: > While I was generally satisfied with that particular idiom for the need, > as well as with overall explanations given around it, nevertheless a feeling > remained that some final bit is still missing. And now I came to an idea > about that missing bit, that is, which thing is actually missing, and how it > can be provided. > > So, I think that the primary problem with that idiom is that it may be > unknown for a programmer, and the secondary problem is that it isn't always > easily recognizable. In general, the missing thing is a reference point for > this idiom. > > Therefore it seems suitable to introduce a pragma for this purpose - to > provide a reference point. This pragma will not affect the code, it will > merely state that the idiom is used for particular parameter of the > subroutine: > > pragma Mutable(subroutine-name, parameter-name); -- or Mutable_Parameter First, I see absolutely nothing wrong with a project using this idea, even if the compiler doesn't support the pragma. Second, it would be a very useful pragma for portable code that uses "the Rosen trick." But I have a different worry. Cases where the Rosen trick are used are often for performance reasons, and are almost always equivalent to passing an access value instead of a record as the actual parameter. If the fix for constructors of limited types becomes part of the next version of Ada, there will be a better way to deal with the issue. The Generator type in Ada.Numerics.Float_Random, and Ada.Numerics.Discrete_Random is declared limited private, and should be. The same applies to any case where this trick is appropriate. What you will be able to do with constructors for limited private objects in Ada 0Y is to make the object created on the stack of the correct size, and make the actual parameter type an access type. Yeah, I know, this is a different cheat that works out to the same thing, but assuming the compiler supports it, growing the stack to create the actual object and doing the necessary initializations will result in something which is just as efficient as the Rosen trick but results in an access parameter which won't be altered. (Its target will of course.) In case this sounds "over the top," I currently have a package I use that creates per task generators. Of course, in that case you may need to do explicit allocate and free operations to keep the officially per task object small, but from a user perspective what is going on in all cases is the same. I certainly don't know what the correct way to deal with the issue of access constant parameters is. I think I would do it by allowing constant subtypes for access types. Maybe in Ada 1Z? I don't think we know enough to fix that issue yet. To clarify, there are two issues here. One is that you want some access values to be marked as accessing constants, and in other cases you want to restrict the use of the designated object. I feel that there is an elegant solution out there, but I don't know how to fill in all the blanks yet.) Let me give an example (assuming some new syntax where needed: type Foo is ... type Bar is access Foo; subtype CBar is access constant Foo; F: Foo; CF: constant Foo; B: Bar; CB: CBar; procedure Some_Proc(CBP: in CBar); ... begin B := F'Access; --okay CB := CF'Access; -- no problem B := CF'Access; -- illegal? CB := F'Access; -- should be okay? B := CB; -- illegal, or a run-time check? CB := B; -- should be okay. Some_Proc(B); --should be okay, but... ... procedure Some_Proc(CBP: in CBar) is ... begin CBP.Some_Comp := New_Value; -- must be illegal. ... end Some_Proc; Just too many question marks in that prototype. I'd want to prototype this and try to fill in the blanks, but only after some of the bigger pieces of Ada 0Y have been frozen. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush