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

[Richard D Riehle <LaoXhai@ix.netcom.com>]

In article <37e2e58c@news1.prserv.net>,
	"Matthew Heaney" <matthew_heaney@acm.org> wrote:

>Let me preface this discussion by saying that I'm advocating that internal
>state changes be allowed only for limited (private), by-reference types.
>Of course, internally, there are some state changes, but the client doesn't
>know or care about them.  That's because the postcondition is
>
>  function Get_Attr (O : T) return Attr_T;
>  --
>  -- Postcondition: return current value of Attr.
>
>and the postcondition is in fact satisfied.  Whether some internal state
>changes are made in order to satisfy the postcondition is irrelevant.
>
>If you don't want internal state changes to occur as a result of invoking
>Get_Attr, then how do you state that as a postcondition?

Ada does not support post-conditions.  I am not persuaded that a comment will
have any effect on a client of a design.  

>> 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.  The client has a
guarantee there will be no change to the incoming data.  I am not sure why this
is so difficult.  We would be taking away nothing in flexibility and adding something
in terms of the contract.  

>The sine qua non of the object paradigm is that we don't describe an object
>in terms of its representation.  We describe the object in terms of what
>things you can do to it.

No disagreement here. And we describe the the things we can to the object in
the form of a contract.  The better the contract describes what is legal, what
to expect, the better the client understands what to expect of it.

>You seem to be saying:
>
>  Query the object, without changing its state.
>
>But what does that statement really mean?  A client doesn't know anything
>about an object's state -- he only knows about what he can do to the object
>(here, select a value).

The client knows what to expect of a contract by what is revealed.  Also, the
designer of the original function can specify, long before the algorithms for
the function are written, the contractual constraints for that function.  This
could even be useful at the level where a function refers to an abstract class
and sets the standard for all derivations and overriding of that function for
that class.  

>How would you even write a postcondition that says "internal state of object
>hasn't changed"?  You're making a statement about internal behavior, in a
>postcondition that describes external behavior.

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.  

>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. Not
every access value is a limited type.

>(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.   

>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.  On the contrary, I am advocating a contract that
is a little more explicit vis a vis mutability of access parameters.

>OK, fine, but then what would the world look like if there weren't ESP?  If
>an ESP world looks just like a non-ESP world, then what's the difference?
>Why include ESP in the model at all?  Just use Occam's Razor to cut ESP from
>the model, to keep the description parsimonious.
>
>What is the difference in the client's world, between invoking
>
>  constant function Get_Attr (O : in T) return Attr_T;
>
>and invoking
>
>  function Get_Attr (O : in T) return Attr_T;

For an in mode parameter, there is no problem and no need for the constant
designation. The function that raises a potential problem is one with the
specification:
 
      function Get_Attr(O : access T) return Attr_T;

>As far as I can tell, these worlds look exactly the same.

Yes, Matt, yours look exactly the same. But they do not look like mine.

Someone else commented on the quest for purity.  That is not my quest. Mine is
simple and not difficult.   Simply, it would be nice to have a way to sometimes
guarantee in a function specification that an implementation of that function
would not modify the value of an access parameter.  Another correspondent noted
that const is required in C++ to offset a language problem.   We are not talking
here of C++.  We are all agreed that the problem of modifying an access value
can occur in Ada.  We simply do not agree that it is worth closing the loophole
created by this feature.

Richard Riehle