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,dd23af7a2f4f9e7c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-05 01:49:19 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!tar-atanamir.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Mutable parameter of a function (long ago was: Re: What evil would happen?) Date: Mon, 05 Jan 2004 10:55:26 +0100 Message-ID: References: NNTP-Posting-Host: tar-atanamir.cbb-automation.de (212.79.194.116) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1073296157 5513661 212.79.194.116 ([77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:4115 Date: 2004-01-05T10:55:26+01:00 List-Id: On Mon, 5 Jan 2004 06:17:18 +0300 (MSK), "Alexandre E. Kopilovitch" wrote: >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? I meant anonymous access parameters such as: function Foo (X : access Y) return Z; Which openly contradicts any possible rationale behind forbidding in-out parameters. Alas, there is no anonymous access-to-constant parameters. As for my point, I have only IF-THEN. If the concept of a function as a special sort of a pure subroutine with one distinguished side-effect has to be realized in a language, then that should be made more consequently than we have it in Ada. Which would also pay off, for example, by allowing *true* functions in static expressions. >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? It is a to death beaten issue discussed in c.l.a. over and over again. Guess why? >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. See above. All arguments are known, to almost everybody, I hope. However, that the design was based on an analysis of a large amount of projects and existing code is somewhat new to me. It would be very interesting to know, how such analysis could be done in any scientific manner. I mean precisely: 1. procedures and functions as separate concepts of a subroutine 2. a need to restrict [function] parameters 3. a need to restrict [function] code 4. ways of restricting the parameters and code with nice diagrams and tables of correlations... (:-)) And honestly, provided all the innovations Ada design brought to programming languages construction, what was that "real data", back to late 70s, early 80s? >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". Error is a result of a decision. Though the reverse is not true. Not every decision results in an error. -- Regards, Dmitry Kazakov http://www.dmitry-kazakov.de