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 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-04 19:37:20 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!fr.ip.ndsoftware.net!proxad.net!freenix!enst.fr!melchior!cuivre.fr.eu.org!melchior.frmug.org!not-for-mail From: "Alexandre E. Kopilovitch" Newsgroups: comp.lang.ada Subject: Re: Mutable parameter of a function (long ago was: Re: What evil would happen?) Date: Mon, 5 Jan 2004 06:17:18 +0300 (MSK) Organization: Cuivre, Argent, Or Message-ID: References: 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 1073273839 81989 80.67.180.195 (5 Jan 2004 03:37:19 GMT) X-Complaints-To: usenet@melchior.cuivre.fr.eu.org NNTP-Posting-Date: Mon, 5 Jan 2004 03:37:19 +0000 (UTC) To: comp.lang.ada@ada-france.org Return-Path: In-Reply-To: ; from "Dmitry A. Kazakov" at Sun, 04 Jan 2004 13:07:56 +0100 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:4111 Date: 2004-01-05T06:17:18+03:00 Dmitry A. Kazakov wrote: > BTW, this is an example how one error leads to another. The first error was > the design fault of Ada 83, that we had no *procedures* (not functions!) > with return values. The consequent error was to allow access parameters for > functions in Ada 95. The result is completely misleading. Functions > *openly* have side effects, but still have no in-out parameters, forcing > programmers to use pointers (and thus aliased objects). So what your point here - do you mean that the best way was to provide an opportunity for procedures to return value, and then either forbid access parameters for functions entirely or at least limit them to access-constant only? If so, what is your guess, why that was not happened - neither in Ada 83 nor much later - in Ada 95? It was so simple to do (for example, that may be done introducing RETURN mode for a parameter of a procedure), and in fact there is a workaround for that in GNAT - implementation-defined pragma (which first appeared in DEC Ada compiler, I think). This matter certainly was not overlooked by the language designers - there were discussions around that matter (you can see them on AdaIC website) - although they apparently concentrated on another way of dealing with the issue - IN OUT mode for functions. You probably don't think that Ada 83/95 designers were stupid, and before Ada 95 there was substantial experience with Ada 93 - so why they did not went that way? They probably had some arguments against it. Do you think that those arguments were invalid even then? Or you think that they may be valid in 80th and in the first half of 90th, but are dead now? And what I'd like to add here is that those language designers had (and have) one very important thing that you and I have not: real data. We can guess what is error-prone, dangerous etc., but this is only guess, based mostly on our own experience and imagination and on very limited observation; while they had (and have) large customer base, they deal with actual cases and error reports, and see large amount of code produced by real users; so they can *know* what is really error-prone, dangerous, confusing etc., at least in current circumstances. Therefore any strong judgement from our side about their past decisions - like "error" - seems inappropriate... we weren't insiders of that Ada world of the past, and we aren't historians. So, even you dislike some decisions and their apparent consequences, let them still be "decisions", not "errors". Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia