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

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

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

>In article <7s9nd0$cbe@dfw-ixnews17.ix.netcom.com> , Richard D Riehle 
><LaoXhai@ix.netcom.com>  wrote:
>
>> Ada does not support post-conditions.  I am not persuaded that a comment will
>> have any effect on a client of a design.
>
>Every operation has a precondition and a postcondition, irrespective of
>whether of not it is expressed in the language proper.
>
>For example:
>
>  procedure Push
>    (Item  : in     Item_Type;
>     Stack : in out Stack_Type);
>  --
>  -- Precondition :
>  --    not Is_Full (Stack)
>  --
>  -- Postcondition :
>  --
>  -- Get_Top (Stack) = Item
>  -- Depth (Stack) = Depth (old Stack) + 1
>
>
>If operations don't have postconditions, then what does invoking an
>operation mean?

The question is, what does invoking an operation mean to the caller.  If the
caller has no idea of what the pre-conditions and post-conditions (and invariants)
might be, then part of the actual meaning is hidden.  If pre-conditions were part of
the specification for each operation, the meaning would be more explicit.  
>
>I think we're in violent agreement.
>
>For non-private types, I think we can all agree that letting the caller know
>there will be no state changes is A Good Idea.  Here it's easy to specify a
>postcondition that means "no state change," because the state is a public
>part of the object.

Not too violent, I hope. It is not easy to specify a post-condition.  
The post-condition is implied, and becomes a client's best guess at your intention.
If you could specify a post-condition for the function such as, (pseudocode),

       Ensure(X before call = X after call);

or even

       Invariant(X always = X before call);

the client would have assurance of the stability of X.  This is not part of the
Ada language, for good or bad.   Instead, we have the more conservative approach of
range constraints, parameter modes, etc.  One of those parameter modes makes a
parameter vulnerable to internal modification.  

>However, for private types, there is no such thing as "public state," so
>there is obvious difficulty in specifying a postcondition that means "no
>state change."

Although there is no public state, a primitive operation with an access
parameter can change the internal state of a parameter.  I think the guarantee
of immutability is important for both private and non-private data.

>> 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.
>
>I think we agree that for non-private types, this is a good idea.

Interesting.  I thought you disagreed.  What are we arguing about anyway?
>
>>>(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.)

Ah. Here seems a point of difference.  Consider the following abstract class,

      package Abstract_Level is
          type Abstract_Declaration is abstract tagged private;
          procedure X ( . . .) is abstract;
          procedure Y ( . . .) is abstract;
          function  F (A : access Abstract_Declaration) return some-type
                                     is abstract;
      private
          type Abstract_Declaration is abstract tagged private;
      end Abstract_Level;

Now, anyone overriding function F can do so with implementing code that changes
the internal state of the access parameter.  If, on the other hand, we were able
to code the parameter so it would be a constant access, 

   function  F (A : access constant Abstract_Declaration) return some-type
                                     is abstract;

every overriding would be forced to leave the data in the parameter unchanged.  

Matt, I wrote the following and you replied in agreement with it.  

>> 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.
>
>I think we do agree that it is worth closing this loophole.

Once again, what is our disagreement.  You just agreed with me on the very essence
of my main point.  I am confused about where it is we don't agree.  

Richard Riehle