Re: Redefinition of Equality (Long)

[ka@socrates.hr.att.com (Kenneth Almquist)]

> 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.  [snip]

That's the goal.  It is not fully achieved because if the "in"
parameter is a pointer or a record containing a pointer, the thing
pointed to can be 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.

How about the following?  Borrowing the term from C++, we define

    pragma Mutable(T);

which causes "in" parameters of type T to be passed using "in out"
conventions and prevents constants of type T from being stored in
read-only storage.  Now we allow "in" parameters to be modified,
but only if

  1)  The type is mutable.

  2)  The full type is visible.  In other words, an "in" parameter
      of a type declared "private" cannot be modified by a function
      or procedure which is outside the package declaring the type.

The purpose of the second rule is to allow the compiler to ensure
that the abstract value of an "in" parameter cannot be modified
unless the implementer of the abstract data type provides a function
that does this.

Following the tradition of making dangerous Ada constructs as ugly
as possible, we could require an attribute to be used when a
modifiable version of an "in" parameter is required:

    function Lookup(Tree : Splay_Tree) return Item is
       ...

       Tree'Variable.Root := ...;

This last suggestion may be overkill, since most abstract data types
will not require pragma Mutable.  Self-ordering data structures such
as splay trees are one example.  Data structures which cache the
results of recently performed queries are another.  Data structures
which are implemented using other data structures whose access methods
contain state is a third.  (In this regard, Dave's example of a Set
data type using a List data type seems to have been misunderstood by
some people.  The point of his example was that his List type did
not allow you to determine which elements were in the list without
modifying the list.)  None of these three types of data structures are
common, so the support that the language provides for implementing
them is not critical.  What is important is the ability to separate
interface from implementation.  I want to be able to take a table
package and replace a hash table with a splay tree--without modifying
the public part of the package specification.
				Kenneth Almquist