Re: Why would anyone want opacity?

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

Responding to Mitch Wand, Bill Rozas wrote:

> As Jeff has argued, your example does not argue for opacity.  It
> argues for disjointness of new types.

Yes, that is what I want.  (Mitch too, probably.)  I didn't
realize that Jeff wasn't arguing against disjointness of new
types.  Perhaps I should have changed the subject line when
I responded to Alan Bawden's question.

Although there exist applications for which the security of
absolute opacity is needed, it is not altogether unreasonable
to tell people that those applications should be programmed
in Java or Standard ML instead of Scheme.  In the Scheme world
there is much less demand for security than for the ability to
link to arbitrary (that is, hopelessly insecure) C/C++ code.

Users of MacScheme+Toolsmith may recall that I do not hesitate
to provide horribly low-level abstraction-breaking facilities,
provided everyone understands that the precise result of a call
to %%RECORD-PEEK (e.g. "Application unexpectedly quit: ID = 1"
or "segmentation fault; core dumped") will depend upon the
implementation.

Michael Blair has been banging the drum for a compiler
optimization that would be incorrect in the presence of a
well-defined OPAQUE-THINGY-POKE!, so he and/or Kent Dybvig
might have a contrary attitude.

On the other hand, the need for Blair's optimization would go
away if we made a couple of minor changes to his proposal.
More to the point, Blair's optimization would still be valid
so long as the semantics of OPAQUE-THINGY-POKE! and its ilk
were left sufficiently unspecified.

If we try to specify really low-level abstraction-breaking
facilities, then even straightforward code generation will
break.  Connoisseurs of abstraction-breaking will enjoy

  Andrew W Appel.  Intensional equality ;=) for continuations.
  ACM SIGPLAN Notices, Volume 31, Number 2, February 1996,
  pages 55-57.

Will