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.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no 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 07:57:25 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!hub1.nntpserver.com!nntp-relay.ihug.net!ihug.co.nz!out.nntp.be!propagator-SanJose!in.nntp.be!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9rti6v$hcu$1@news.huji.ac.il> <1EyE7.10050$xS6.13527@www.newsranger.com> <9rue9f$j4t$1@nh.pace.co.uk> <9ruiet$kqg$1@nh.pace.co.uk> <3BE3235D.E292B890@boeing.com> <3BE35498.9F6381A2@acm.org> <9s230d$107b5a$2@ID-25716.news.dfncis.de> <5ee5b646.0111040507.5ca7ea23@posting.google.com> <9s3tl3$111hco$1@ID-25716.news.dfncis.de> <5ee5b646.0111041846.93f3e07@posting.google.com> Subject: Re: Side-Effects in Functions [Rosen Trick] Message-ID: <_EyF7.13225$xS6.16870@www.newsranger.com> X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Mon, 05 Nov 2001 10:56:42 EST Organization: http://www.newsranger.com Date: Mon, 05 Nov 2001 15:56:42 GMT Xref: archiver1.google.com comp.lang.ada:15816 Date: 2001-11-05T15:56:42+00:00 List-Id: In article <5ee5b646.0111041846.93f3e07@posting.google.com>, Robert Dewar says... >No, this is by no means a consensus. Most procedural >languages, including Ada, allow functions to have side >effects. And on the narrower issue of allowing IN OUT C actually does not allow "OUT" parameters in functions either. In fact its even worse than Ada here, in that it doesn't have procedures either, so there is *no* language-defined way to pass values out through a paramter. I does allow one to get around this restriction using pointers, but then so does Ada. >Most people feel that being forced to add aliased keywords >all over the place, just because of odd interfacing requirements for C >functions, is unfortunate. If you find Any C interfacing code is going to be somewhat ugly, not due to any failing in Ada, just because C *is* ugly. That's why "most people" I talk to prefer thick C bindings, to localize the uglyness. Now all this being said, I am beginning to come around to your point of view. Perhaps value-returning procedures should be reconsidered for the next Ada rev? That would let folks keep their no (visible) side-effect functions. I'm also beginning to think that some rethinking needs to be done about Ada's whole parameter-passing scheme. It works well for public types, but blows for private types. For a private type, its quite possible for me to not want to change the users' view of a parameter, but to want to change some internal data in it (eg: cache a location in a structure to speed up the next access if it is liable to be nearby). Labelling such parameters as "in out" misleads the clients (and not so incidentally, prevents use of functions). I'm getting really tired of the gymnastics the language makes me go through to do this. Rosen trick aside, there ought to be a way to specify certian portions of a private record and tagged types as "internal", and thus always updatatable. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced.