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,bd40601768eaf8fd X-Google-Attributes: gid103376,public From: Mark Lundquist Subject: Re: 'constant functions' and access constant params (was Re: Array of Variant Records Question...) Date: 1999/09/22 Message-ID: <37E95E14.DF911A2F@rational.com> X-Deja-AN: 528420258 Content-Transfer-Encoding: 7bit References: <7r5vh3$imu1@svlss.lmms.lmco.com> <37d6a45c@news1.prserv.net> <37d6ccb6@news1.prserv.net> <7r77i8$i08$1@nnrp1.deja.com> <37d7c116@news1.prserv.net> <7r8t21$ov5$1@nnrp1.deja.com> <37d822a1@news1.prserv.net> <7reg02$t83@dfw-ixnews6.ix.netcom.com> <37DE8D09.C863CBC9@rational.com> <7roohh$s6r@dfw-ixnews7.ix.netcom.com> <37e01168@news1.prserv.net> <7rp86o$c6h@dfw-ixnews3.ix.netcom.com> <37E18CC6.C8D431B@rational.com> <7rs8bn$s6@dfw-ixnews4.ix.netcom.com> <37e2e58c@news1.prserv.net> <7s9nd0$cbe@dfw-ixnews17.ix.netcom.com> Organization: Rational Software Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-09-22T00:00:00+00:00 List-Id: I've been trying to clarify things here, but it feels like I'm trying to put out a fire with gasoline! Why isn't it working? :-) :-) Richard D Riehle wrote: > >> I do subscribe to the idea of ensuring that the client of a query is > >> guaranteed that the query will not have side-effects. That, to my mind, is > >> not extreme. > > > >It's not extreme, it's just wrong. > > We will have to agree to disagree on this. It is a simple proposition. Permit > a designer to designate an access parameter to be constant. You mean, permit the object designated by a formal access parameter to be constant, correct? (Formal access parameters are already constant). If that is all you mean, then it's precisely what Matt proposed, so whatever you're agreeing to disagree on, it isn't this. > The client has a > guarantee there will be no change to the incoming data. Unless you're proposing something more than just "access constant" parameters, it has no such guarantee, in view of unchecked programming and also the "Rosen Trick" (respectively, the crude and the elegant forms of what I've been calling "covert modification"). > I am not sure why this > is so difficult. It's difficult for two reasons. First, because you keep on adding the excess baggage language about side-effects and guarantees and so forth. If all you mean is "constant", then just stop there while the meaning is clear! You say "all I want is X, why is that so difficult", and then you add something that X doesn't entail. Secondly, if you do want to preclude covert modification, then it's not clear what it especially has to do with access parameters -- don't you care about the same thing for normal "in" parameters, and if so what do you propose to do about them? > We would be taking away nothing in flexibility and adding something > in terms of the contract. True if you just mean "access constant" parameters. If in addition you mean to preclude covert modification (implied: for limited private types) then the opposite is true: we would actually be taking away from flexibility (in the implementation of the subprogram) and adding no value to the contract (since the object type is limited private). > There are no postconditions in Ada, as mentioned earlier. Instead of a post- > condition, we can guarantee the immutability of the data, in the specification of > the subprogram, by making an access parameter constant. Making the designated object constant (the parameter itself already is). Once again, if all you mean is "constant", then don't add the incorrect "immutability" verbiage, everyone knows what constant means and there is no disagreement! OTOH if you really mean the "immutability stuff, then there is disagreement, and you also shouldn't claim that all you want is to have access-to-constant parameters. > > > >The other issue is, how should a client use this information? How does > >knowing that a selector function returns a value without changing internal > >state benefit the client? > > The information is useful at many different levels. Not the least of those is > the original specification a function before the code is implemented. As to > the client, knowing that an access parameter to an integer or a floating point > value (as an example) is not modified in the function can be a useful thing. Agreed. > Not > every access value is a limited type. True. > > > >(And remember, I'm only talking about internal state changes to limited > >private, by-reference types. Objects that are limited are always variables, > >never constants.) > > I am actually not objecting to you notion regarding limited private, by-reference > types. So there's hope! > > > >Consider an analogy: people who believe in ESP. When you confront them with > >studies that indicate no testing success beyond what's predicted using > >probability theory, they say "Well, ESP only works sometimes, and it's hard > >to tell when." > > I am not sure what this means in this discussion. I am certainly not suggesting > anything remotely approaching ESP. ... :-) :-) > Another correspondent noted > that const is required in C++ to offset a language problem. That would be me... :-) > We are not talking > here of C++. No, but if the idea of a "constant function" was conceived by analogy to C++'s "const member function", then it was fair to discuss why they are required in C++ as part of the explanation for why they are not needed in Ada. > We are all agreed that the problem of modifying an access value > can occur in Ada. Yes (but note, the actual cannot be a constant view [RM 3.10.2(25)]). > We simply do not agree that it is worth closing the loophole > created by this feature. > Two points: 1) The access-to-constant parameter proposal is what you at times have been saying is the "simple" thing that it's "all you're asking for". If that's really true, then nobody is disagreeing with you. 2) The real loophole is created by unchecked programming, and also by the "Rosen Trick". But that has nothing to do with access parameters. > Richard Riehle BTW -- I've enjoyed and learned from your articles and posts over the years, so it's with the utmost respect that I'm disagreeing, or agreeing, or whatever the heck it turns out to have been... :-) :-) -- Mark Lundquist Senior Software Engineer Rational Software Development Solutions Business Unit UNIX Suites Group Aloha, OR, USA