Re: 'constant functions' and access constant params (was Re: Array of Variant Records Question...)

[Mark Lundquist <mark@rational.com>]

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.

<whew!>...   :-) :-)

> 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