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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,611f4b10cbf9af69
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Redefinition of Equality (Long)
Date: 1996/09/30
Message-ID: <DyKEBH.Gp3@world.std.com>#1/1
X-Deja-AN: 186306961
references: <52hgmoINN7tg@snoopy.cis.ohio-state.edu>
 <DyHzHy.5qA@world.std.com> <324FD267.954@cis.ohio-state.edu>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-09-30T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <324FD267.954@cis.ohio-state.edu>,
Dave Gibson  <dgibson@cis.ohio-state.edu> wrote:
>Why pay the price of making a copy of an arbitrarily large object when 
>it is not necessary??  (Making a few copies of access values will do.)
>"=" should, of course, leave the abstract value of its parameters 
>unmodified. ...

Well, the goal is to make sure that the compiler can *check* that the
abstract value of an 'in' parameter is not modified.  And any time you
want to check things at compile time, you have to put up with rules that
are more pessimistic than they might be.  In this case, the compiler
knows nothing of you "abstract" values.  The language therefore requires
it to check that the concrete values are not modified.

The alternative would be for 'in' mode to just be a comment in the code,
and the compiler wouldn't check anything.  Then you could modify the
concrete value while making sure the abstract value is not modified.
But that would obviously be error prone.

I don't see any way around this.

Consider:

    X: constant Integer := 1;
    ...
    Y: Integer := Read_Data_From_Input_File;
    X := Y; -- Illegal!

Should the above be legal?  After all, if the programmer ensures that Y
is 1, then there's no harm done.

Consider:

    Do_Something("string literal");

If Do_Something is allowed to modify the concrete value of its "in"-mode
parameter, what is the compiler supposed to do with the result?

>...  It should be the responsibility of the person implementing 
>Set "=" to ensure that.  However, I do not see any good reason 
>to prevent the operation from manipulating the value passed in 
>in order to compute the function result - especially if it avoids
>unnecessary copying.  The way I'm writing code, the value passed in is
>always an access value although this is not visible at the client
>level. 

Well, if it's an access value, then you *can* modify what it points to.

>Are you saying that a hypothetical 'in out' mode "=" would only
>overload 
>and not override the automatically generated "=" function?  Or would it
>not even be allowed to overload?  Either way, that would be a problem.

I'm saying it would be illegal.  Consider procedures, which *can* have
'out' parameters.  If type T1 has a primitive:

    procedure P(X: in T1);

And "type T2 is new T1;" and T2 overrides:

    procedure P(X: in out T2); -- Illegal!

The parameters have to be of the same modes, and same subtypes.
Otherwise dispatching wouldn't work -- the caller of
P(T1'Class(something)) doesn't know whether he's supposed to copy
back the parameters, for example.

>Well, I'm almost in agreement with them.  I'd like to write functions 
>which do not have any side-effects at the abstract level.  How this is
>achieved concretely, however, should not be unduely hampered by the 
>compiler.  

Agreed.

- Bob