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,ce0900b60ca3f616 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-05 13:58:40 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!supernews.com!easynews!sjc-peer.news.verio.net!news.verio.net!sea-read.news.verio.net.POSTED!not-for-mail Newsgroups: comp.lang.ada From: Brian Rogoff Subject: Re: Side-Effects in Functions [Rosen Trick] In-Reply-To: Message-ID: <20011105134531.P817-100000@shell5.ba.best.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 05 Nov 2001 21:58:35 GMT NNTP-Posting-Host: 206.184.139.136 X-Complaints-To: abuse@verio.net X-Trace: sea-read.news.verio.net 1004997515 206.184.139.136 (Mon, 05 Nov 2001 21:58:35 GMT) NNTP-Posting-Date: Mon, 05 Nov 2001 21:58:35 GMT Organization: Verio Xref: archiver1.google.com comp.lang.ada:15864 Date: 2001-11-05T21:58:35+00:00 List-Id: On Tue, 6 Nov 2001, Alexandre E. Kopilovitch wrote: > dewar@gnat.com (Robert Dewar) wrote: > >That's the whole point here. Functions in Ada DO allow > >side effects quite freely, and what seems odd is the > >Ada rule in this case: > > > >Functions are allowed to have side effects, providing that > >there is no trace of this in the function specification :-) > > Well, but if we allow the side effects within the function specification, > what will be the essential difference between the functions and the > procedures? Functions return values. There is no "void" or "unit" (ML) type in Ada. > Why should we have both notions instead of one? Hysterical raisins. What happened with Wirth's post-Pascal languages? FWIW, I agreed with everything Robert Dewar wrote in his excellent post, and *if Ada could be redesigned from scratch* I personally would prefer no distinction between functions and procedures, but rather a void or unit type. However, it is more likely that monkeys will suddenly fly out my butt than it is that we'll have an incompatible new version of Ada. > We may easily follow the C view, on this subject, and have the > functions only, permitting 'null' for the return type. It's called void, not null. The problem with C is that it ignores returned value types so even though it has void it doesn't really use it. I imagine a reworked Ada would only allow void returning function/procedure values to be ignores, and so wouldn't lose type safety. > >The real issue here, and the point at which this becomes > >significant, is that we use functions in Ada for interfacing to > >foreign languages and there the restriction > >is quite onerous, as anyone who has designed bindings to > >C knows. Yes, access parameters help, but the requirement > >that access parameters be non-null means that this usage > >often is inapplicable. > > I think that if we are going to retain "function" and "procedure" as separate > entities in the language, then introducing vector results is more consistent > way than permitting OUT parameters. I disagree. I think allowing "in out", NOT OUT, parameters for functions would be the best upwardly compatible fix. As Dr. Dewar wrote, it is unlikely to happen, so Ada fans just have to tolerate this annoyance or go elsewhere. -- Brian