Re: Why would anyone want opacity?

[William D Clinger <will@ccs.neu.edu>]

It appears to me that Jeff Dalton thought I was talking about
some horribly low-level abstraction-breaking facility that
would allow a client to use something analogous to LIST-REF
on arbitrary records.

I was actually talking about the problem of information about
the representations of objects leaking out from the module
that implements them.

Maybe the problem will be easier to see if we talk about C++
instead of Scheme.  One of the many problems with C++ is that
not all values are considered objects.  Although some syntactic
notations can be overloaded, they can be overloaded only for
objects.  Thus every use of those syntactic notations depends
upon a fact about representation (that something is an object),
so every use of those syntactic notations on an instance of an
ADT, outside of the module that implements the ADT, is a
violation of representation independence.

Suppose, for example, that some C++ "module" M is a client of
some ADT T, and that x is of type T.  Then any occurrence
of any of the following expressions within M is a bug:

    x + 1
    x == y
    x.foo
    *x
    x[i]
    x()
    x->foo()

I rarely see C or C++ or Scheme code that does not contain
such bugs.

In Scheme the analogue of the syntactic notations in C++ is
the use of a representation-dependent special form such as
CASE or the use of a representation-dependent predefined
procedure such as EQ?, EQV?, or EQUAL?.  These things are
legitimate for use with appropriate built-in types such as
symbols, but it is a bug to use them on any program-defined
ADTs outside of the module that implements the ADT.

These bugs are insidious, because the program may very well
work for the moment, but it is likely to break if anyone
tries to improve it.

Will