Re: Why would anyone want opacity?

[Guillermo J. Rozas <gjr@martigny.ai.mit.edu>]

|   Date: Tue, 30 Apr 1996 17:55:13 +0000
|   From: William D Clinger <will@ccs.neu.edu>
|
|   It appears that Bill Rozas and I actually hold similar attitudes
|   toward opacity, but express them in different ways.
|
|   I like to provide abstraction-breaking facilities, but to warn
|   that they are not guaranteed to provide any useful information.
|   An abstraction-breaking facility that may sometimes report that
|   it has nothing to report is good enough for heuristic purposes
|   such as pretty-printing and debugging.
|
|   In my implementations the quality of information provided by
|   abstraction-breaking facilities tends to depend upon various
|   compiler switches such as the optimization level and
|   debuggability switches.  It sounds like the same is true of
|   Rozas's implementations.  So what are we arguing about?

Their presence.  Yes, it is possible to provide trivial/null
implementations (as with gc), but an implementation that does this
would be considered a poor implementation.

|   Could we perhaps finesse the opacity conflict by agreeing to
|   agree on interfaces for abstraction-breaking, but also to
|   agree that the reliability of the abstraction-breaking
|   operations will be a quality-of-implementation issue?

The new record proposal is evolving along those lines.  It is
possible/legal to provide a null implementation of the spec, which
would abide by the letter but not the intent.

|   This would allow portable code to use abstraction-breaking
|   facilities, but not to depend upon them.
|
|   For precedent I would point to several flaky, partially
|   implementation-dependent things like RANDOM and EQ? that are
|   already in the language.

Of course.