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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,dd23af7a2f4f9e7c,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-02 09:59:00 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!proxad.net!usenet-fr.net!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Alexandre E. Kopilovitch" Newsgroups: comp.lang.ada Subject: Mutable parameter of a function (long ago was: Re: What evil would happen?) Date: Fri, 2 Jan 2004 20:55:56 +0300 (MSK) Organization: Cuivre, Argent, Or Message-ID: NNTP-Posting-Host: lovelace.ada-france.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: melchior.cuivre.fr.eu.org 1073066185 61620 80.67.180.195 (2 Jan 2004 17:56:25 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Fri, 2 Jan 2004 17:56:25 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: X-Mailer: Mail/@ [v2.44 MSDOS] X-Virus-Scanned: by amavisd-new-20030616-p5 (Debian) at ada-france.org X-BeenThere: comp.lang.ada@ada-france.org X-Mailman-Version: 2.1.3 Precedence: list List-Id: Gateway to the comp.lang.ada Usenet newsgroup List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:4043 Date: 2004-01-02T20:55:56+03:00 Quite long (about a half of year) ago Robert I. Eachus wrote about the rule, which forbids IN OUT mode for parameters of a function: >... > But the rule still won't change, and the reason is not just "politics." > This is just one area of the Ada programming culture that seems to rub > foreigners (to Ada) the wrong way. If you are used to Ada, the current > Ada idioms for the few cases that seem to some people to be problems are > natural to you. > > Since I have done a lot of work on random number generators, the Ada > idiom now seems natural to me: > > function Random(Gen: in Generator) return ... > Local: Generator; > for Local'Address use Gen'Address; > begin > ... > end Random; > > Unlike RBKD, I did strongly argue for an in out parameter mode for > functions in Ada 9X. But in doing so I knew that it would be misused > more than it would be correctly used. By now with good implementations > of Unbounded_String, most of the real needs for functions with in out > parameters have gone away. You can always declare a procedure with an > out parameter of Unbounded_String. So if the question is reraised I > will vote against it. And I will also vote in favor of a generic that > provides the equivalent of Unbounded_String for all array types, > including multidimensional array types. 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 This pragma checks for two things: 1) the parameter to which it is applied is in IN mode; 2) the idiom is used for this parameter, that is, there is a local variable (of appropriate type) in the subroutine, and the Address attribute for this variable is defined and points to the parameter. If this check is failed then compiler should complain with long diagnostic message, which contains these rules (thus effectively explaining the idiom). What is good with this pragma? Two points: 1) it provides explicit reference for the idiom - if not within the language manual then at least within a compiler's documentation (if this pragma will be implementation-defined); 2) this pragma will respond to quite justified Robert Dewar's complaint - that we can modify a parameter of a function, but can't say that explicitly in the function's specs. Certainly, this pragma should be optional, that is, the idiom can be used without this pragma - for obvious compatibility reasons. Although it may be made required for use of the idiom (that is, for assignment to a variable, which address is defined by the Address attribute applied to an IN mode parameter) in subroutines that clearly rely upon Ada0Y features. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia