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

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

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


>For private types, the supplier is (or should be) free to make internal
>modifications, to the extent that the postcondition is satisfied.  This is
>where we disagree.

We agree, then, that a designer should be allowed to design a
contract that declares (X : access constant T) as a mode for a 
non-private type. Interesting that we both came to this notion
independently and found ourselves arguing about it.  I have, 
before this little discussion, encountered others in the Ada 
community who have also come to this idea on their own.  

>Agree for non-private data.  Disagree for private data.

Now we are focusing on the precise area of disagreement.  Once again,
we are not so far apart.  If we are to agree that the syntax, 

    function F(X : access constant T) return R;

or something like it (I am not as concerned with the syntax as the
semantics), then it would make sense to extend that capability to
all types, private and non-private.  The designer has the ability 
to overload an operation with a new primitive, though not ability to
override it.  This does introduce a complication in the overloading
rules that requires a compiler to check one additional mode level of
the parameter profile.  However, that is true with both private and
non-private types.

In my earlier example, repeated below, 

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

The class designer is explicitly declaring that overriding of the 
function F prohibits modification of the data components of
Abstract_Declaration. If it becomes useful to introduce a new 
function later with different properties, no problem.  

Returning to the syntax issue for a moment, I am still not convinced 
that, in the absence of explicit pre-, post-, and invariant conditions, 
having the ability to declare a function as constant would not be a
useful feature.  In this case, the constant function would behave 
just like a protected function.  Although you, along with many others,
do not like this syntax,

          constant function F ( ... ) return ...

it would serve the purpose nicely.  Such functions would be only 
useful as queries on the state of data.  I realize that
this notion foments another storm of protest and indignation. 

Richard Riehle
richard@adaworks.com
http://www.adaworks.com