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,92d1af21ade61406 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-12 04:20:26 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.gamma.ru!Gamma.RU!fu-berlin.de!uni-berlin.de!dialin-145-254-037-192.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Problems with 'class, help anyone? Date: Tue, 12 Nov 2002 13:20:00 +0100 Organization: At home Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-037-192.arcor-ip.net (145.254.37.192) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1037103623 13158593 145.254.37.192 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:30756 Date: 2002-11-12T13:20:00+01:00 List-Id: Alexandre E. Kopilovitch wrote: >>> There is another way, with perhaps even less incompatibility: let's >>> introduce third mode for a formal parameter - "return" mode (in addition >>> to conventional "in" and "out"). That "return" may be applied to the >>> procedure's first parameter only, and it means the same as "out" mode, >>> with single exception: if the first parameter of a procedure is in >>> "return" mode then the procedure *may* be called without the >>> corresponding (first) argument, and in such a case it returns value. For >>> example: >>> >>> procedure Two_Fold(Result : return Boolean; Something : in Integer); >>> >>> X : Boolean; >>> Two_Fold(X, 0); -- "return" as "out", procedure does not return value >>> >>> if Two_Fold(0) then -- first argument omitted, procedure returns value >>> ... >>> end if; >> >>But an out parameter and a return value are not the same, i.e. they cannot >>generally be interchanged! >> >>Consider e.g. >> function F return String; >>vs. >> procedure P (S: out String); >>The former has no idea how long the object is that will get the result (if >>any), the latter takes the length from the parameter. > > Well, I was not writing an AI (perhaps, I should?), therefore I did not > look at the details. Surely, you are right - there must be a limitation > for a parameter in "return" mode: if one is of indefinite type then the > currently undefined attributes (Length, First, etc.) cannot be used for > that parameter. If the goal of your proposal is to expose the result as a variable within the body, then some equilibristic is indeed required. For instance, you could require that such a parameter has to be overridden within the body: procedure Read (Item : result String) is Length : Natural; begin Get (Length); -- Get the actual string length declare Text : String (1..Length) renames Item; -- Override begin Get (Text); end; end Read; Honestly, I do not like it. Further, if you go this way, then you should consequently say, OK, let's allow multiple-return functions capable to return more than one potentially unlimited result. Maybe then it will worth the efforts. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de