Re: Why would anyone want opacity?

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

|   Date: Thu, 09 May 1996 14:07:04 +0000
|   From: 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

I agree violently with everything you've said in this message.

[
 Now I'll get a bounce from some random remailer in the list about too
 little new content compared to the old.  Perhaps I should change my
 quoting character.  It worked once.
]

I also like your suggestion of having an addendum to the RnRS with
subprimitives that implementations can agree on, but whose semantics
is not well-enough defined, specified or guaranteed to constrain the
implementation of the semantics of the features in the reports proper.