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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9d303864ae4c70ad X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-04-09 05:45:09 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-038-199.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Reprise: 'in out' parameters for functions Date: Fri, 09 Apr 2004 14:44:51 +0200 Organization: At home Message-ID: References: <87brm1pksa.fsf@deneb.enyo.de> <5058369.11AmbRLujt@linux1.krischik.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-038-199.arcor-ip.net (145.254.38.199) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1081514707 95085786 I 145.254.38.199 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:6899 Date: 2004-04-09T14:44:51+02:00 List-Id: Martin Krischik wrote: > Dmitry A. Kazakov wrote: > >> Florian Weimer wrote: >> >>> Stephen Leake writes: >>> >>>> Ada has a wart. Let's admit it, and move on. >>> >>> Can't we fix that one without breaking backwards compatibility? >> >> procedure Has_A_Result (...) return Result; > > This solution would call for precise documentation (advantages, > disadvantages) etc. pp. Plus a quick summary ("functions are faster") for > the beginner. > > Otherwise the same problems as with "access all" will arise. Many > programers use "access all" all the time - even when not needed, ignoring > the diadvantages. This is very true. And there is also a nasty problem with specific access types for beginners: type Root is tagged ...; type Handle is access Root'Class; type Derived is new Root with ...; type Derived_Ptr is access Derived; function Factory return Handle is Ptr : Derived_Ptr := new Derived; begin Prepare (Ptr.all); return Handle (Ptr); -- Error! end Factory; Should cast: function Factory return Handle is Ptr : Handle := new Derived; begin Prepare (Derived (Ptr.all)); return Ptr; end Factory; >>> Or are politics involved? >> >> I think so. But there also is the problem of evaluation order, though >> simply ignored for access parameters of functions. > > See above. Have you heard of GNATs "pragma Pure_Function"? Yes, it is a very good thing. I'd like to see it in the standard and moreover not as a pragma, but as a part of the syntax (in the contract). It could be very useful, for example, to declare an abstract function as pure, to force any implementation to conform. Even more useful would be to allow pure functions in static expressions. The compiler could get an advantage from knowing that a function is pure: while Match (Pattern ("..."), Standard_Input) loop ... -- Pattern is pure, so the result is a constant end loop; > Prehaps making function even more restive plus procedures with return plus > a "functions are faster" statement might do the trick. I think that one should also either 1) fix evaluation order for non-pure functions and procedures with results or, better, but backward incompatible, 2) disallow them where the order is not fixed. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de