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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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:07:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!213.56.195.71!fr.usenet-edu.net!usenet-edu.net!enst!enst.fr!not-for-mail From: "Alexandre E. Kopilovitch" Newsgroups: comp.lang.ada Subject: Re: Side-Effects in Functions [Rosen Trick] Date: Tue, 6 Nov 2001 00:10:58 +0300 (MSK) Organization: h w c employees, b f Sender: comp.lang.ada-admin@ada.eu.org Message-ID: Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: avanie.enst.fr 1004994429 70555 137.194.161.2 (5 Nov 2001 21:07:09 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Mon, 5 Nov 2001 21:07:09 +0000 (UTC) To: comp.lang.ada@ada.eu.org Return-Path: X-Mailer: Mail/@ [v2.44 MSDOS] Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:15855 Date: 2001-11-06T00:10:58+03:00 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? Why should we have both notions instead of one? We may easily follow the C view, on this subject, and have the functions only, permitting 'null' for the return type. Indeed, Ada frequently uses the common term 'subprogram' for both functions and procedures, but only in the textual part of the language definition. It means that we are permitted to think and speak about 'subprograms', but must differentiate them in our code as either 'functions' or 'procedures'. What is the purpose of that differentiation? >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. Alexander Kopilovitch aek@vib.usr.pu.ru Saint-Petersburg Russia