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-09 14:30:44 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!news-out.visi.com!petbe.visi.com!news.lightlink.com!news.mv.net!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: In-Out Parameters for functions (was: Re: Certified C compilers for safety-critical embedded systems Date: 09 Jan 2004 17:30:43 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <3fe00b82.90228601@News.CIS.DFN.DE> <5802069.JsgInS3tXa@linux1.krischik.com> <1072464162.325936@master.nyc.kbcfp.com> <1563361.SfB03k3vvC@linux1.krischik.com> <11LvOkBBXw7$EAJw@phaedsys.demon.co.uk> <3ff0687f.528387944@News.CIS.DFN.DE> <1086072.fFeiH4ICbz@linux1.krischik.com> <3ff18d4d.603356952@News.CIS.DFN.DE> <1731094.1f7Irsyk1h@linux1.krischik.com> <3ff1b8ef.614528516@News.CIS.DFN.DE> <3FF1E06D.A351CCB4@yahoo.com> <3ff20cc8.635997032@News.CIS.DFN.DE> <3ff9df16.30249104@News.CIS.DFN.DE> <3FFC0201.6020303@noplace.com> <3FFEAE10.3070209@noplace.com> NNTP-Posting-Host: pip1-5.std.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls4.std.com 1073687443 32702 192.74.137.185 (9 Jan 2004 22:30:43 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Fri, 9 Jan 2004 22:30:43 +0000 (UTC) User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:4274 Date: 2004-01-09T17:30:43-05:00 List-Id: Marin David Condic writes: > Yeah, but as far as I can tell C always had "in only" parameters and > everything was a function returning a result. The only way you could get > "in out" mode was passing addresses (indistinguishable to the garden > variety programmer from a 'Access) and of course dealing with all the > errors that resulted from no checking that a parameter actually was an > address. Such a setup didn't seem to hurt C with respect to popularity > or getting Fortran programmers to understand it. I've heard a lot of Fortran programmers complaining about C! > I'm ambivalent about "in out" for functions. I've never found it > difficult to use functions just the way they are and can't think of a > case where in-out would have helped me with a real world problem. The > only example anyone ever seems to cite is the Random Number Generator > leading me to think that maybe this *is* the only instance in which it > is genuinely useful. It's a good example because it's familiar -- it's in the RM. I can think of several other examples. How about this one: function Get_Line(F: in out File) return String; You can't make that a procedure, because Get_Line itself needs to determine the length of the result, and 'out' parameters don't work that way. And even if they did, it's kind of nice to be able to say: X: constant String := Get_Line(F); >... OTOH, I could see how they might be included and > not impact my life one iota. If you don't need it, you don't use > it. I agree with that philosophy. It is not the job of the language designer to prevent people from doing evil things. It is the job of the language designer to prevent people from doing evil things *by accident*. You're not likely to declare 'in out' parameters by accident, so it's fine to let the programmer decide when to use it. (Probably not very often -- *most* functions should be free of side effects.) Except, as you say: >... Except that possibly it casts into doubt what happens in an > expression loaded with function calls where one used to be able to > assume that the parameters were not being modified. With in-out you'd > have to know the parameter modes before you could interpret what the > expression was doing. That's a good point, too. You can't get any advantage out of having side-effect-free functions unless you (the reader of the program) can somehow *know* that they are side-effect-free. I would be in favor of marking 'in out' and 'out' with some syntax at the call site. I would also be in favor of marking calls syntactically if they have side effects on global variables. But none of that has anything to do with Ada (although there was an *optional* way to mark '[in] out' in Green). > MDC > > Robert A Duff wrote: > > As far as I can remember, this idea was considered, and was generally > > thought to be ugly. I mean, suppose you're trying to convince a Fortran > > programmer to use Ada for numerics stuff. If you start babbling about > > aliased and 'Access when there is no inherent need for pointers, > > they're going to laugh, and rightly so. A: So I know what you're talking about without looking ahead. Q: Why is top-posting a bad idea? ;-) - Bob