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,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-29 15:32:01 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!c03.atl99!sjc70.webusenet.com!news.usenetserver.com!sn-xit-02!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions Date: Thu, 29 Jan 2004 17:30:44 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <101j5upca3t7f2c@corp.supernews.com> References: <5ad0dd8a.0401240721.7682f2e1@posting.google.com> <5ad0dd8a.0401280230.5c800894@posting.google.com> <101ggi3sdf56311@corp.supernews.com> <6fjh109qllmjek7ud2me7k1t40so3ervmk@4ax.com> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:5070 Date: 2004-01-29T17:30:44-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:6fjh109qllmjek7ud2me7k1t40so3ervmk@4ax.com... > On Wed, 28 Jan 2004 17:13:10 -0600, "Randy Brukardt" > wrote: > ... > >This topic is almost a religious war. I'm one of the few who's changed sides > >(even though allowing 'in out' on functions would be such a disruptive > >change to Janus/Ada that it probably would lead to the abandonment of the > >technology), because it is impossible to do good (pointer-less) O-O > >programming without it. > > Would not procedures with return be a minor, non-obtrusive change? No. The problem with Janus/Ada's intermediate code is that it assumes that all calls that return results (and thus can occur in expressions) do not require parameter checking after the call, and thus does not allow access to those parameters. In particular, there is nowhere to hang those checks (called "moss" in the terminology Dan Stock invented to explain our optimizer; "moss" because it hangs on a tree but isn't part of it.) In addition, it doesn't allow parameters to be left on the stack after a value-returning call (which also causes trouble with C varargs functions, but that is a very limited and very rare problem). We could get around some of the problems by using a different calling convention for function calls (passing all in-outs by reference, for instance, making a local copy at the call site), but that would complicate all kinds of code -- currently, parameter passing doesn't depend on the entity to which it is passed. There would be no difference between a procedure returning a value and a function returning a value to the intermediate (and eventually machine) code. As such, I don't see much value in that. Randy.