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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!seas.gwu.edu!mfeldman From: mfeldman@seas.gwu.edu (Michael Feldman) Newsgroups: comp.lang.ada Subject: Re: Reference vs. copy semantics in passing parameters Keywords: Ada Message-ID: <2747@sparko.gwu.edu> Date: 18 Feb 91 01:42:57 GMT References: <5572@baird.cs.strath.ac.uk> <1991Feb13.211643.25777@rti.rti.org> <2725@sparko.gwu.edu> <2742@sparko.gwu.edu> Reply-To: mfeldman@seas.gwu.edu () Organization: The George Washington University, Washington D.C. List-Id: In article jls@yoda.Rational.COM (Jim Showalter) writes: >Yes, but you miss my point (I think?). It is not modification of the >POINTER we are trying to prevent. We are trying to prevent modification >of what the pointer points to, and there is currently no way to insure >this in Ada. A doofus can break the rules with impunity. Hmmm.Are you implying that C++, or whatever, can guarantee that an entire linked list could be kept safe from modification by making its head pointer an IN parameter? Neat idea, but how on earth could it be implemented? If you mean only the directly designated value, i.e. the node (say) that the pointer points to but not the other nodes "down the line", I don't really think you've accomplished very much. > >Why would it BE a pointer? Beats me, but these things do happen from time >to time, and when they do it would be nice if the language made them safe. Well, this is a matter of taste. It's impossible (or nearly, IMHO) to make the language safe from people who insist on using side effects. The goal, it seems to me, is to make it difficult to _accidentally_ do stupid things. If people want to do them deliberately, they will find a way no matter how safe we think we are building things. > >One gross thing that people do currently is give IN/OUT semantics to >parameters on functions by passing a pointer and dereferencing it inside >the function to modify what the pointer points to. There is no way to >prevent this egregious behavior at present (note: many many people have >also requested that 9x include IN/OUT's on functions, which would make >the case for performing the trick just described even weaker). A dumb idea, if you ask me. People are trying to make Ada behave like C. If they try hard enough to subvert the safety that Ada provides, they will find a way to succeed. Ada9x is looking at this issue (it's in the requirements document, but I don't recall if it's a requirement or a study topic); I hope they leave this as it is in Ada83. As I recall, the argument for allowing IN/OUT's on functions is that since nonlocal references are allowed on functions, allowing IN/OUT's is a clearer way of doing the same thing. There is a certain logic to this, I must say. But if you encapsulate the function in a package, using the nonlocal reference only to maintain state data, with the client unable to muck with the state variable, then an IN/OUT parameter does _not_ accomplish the same thing, because it exposes the state variable to the client. Mike Feldman