A (Low-Level) Opaque Object Proposal for R5RS

[Alan Bawden <Alan@lcs.mit.edu>]

   Date: Mon, 29 Apr 96 01:13 EDT
   From: Aubrey Jaffer <jaffer@martigny.ai.mit.edu>

      Date: Fri, 26 Apr 96 12:29:53 -0400
      From: Michael R. Blair <ziggy@martigny.ai.mit.edu>
      Both MAKE-OPAQUE-TYPE and OPAQUE-UP must be reserved identifiers so that
      users cannot re-define them to subvert the abstraction barriers they are
      designed to enforce.

   I agree.  The macro appendix of R4RS (which will presumably be
   incorporated into R5RS) states:

Hmm...  I must have missed this remark on the first reading.  I don't
understand why these two identifiers need to be treated specially.  I don't
understand why all four of your operations can't be ordinary procedures.
So I guess I don't understand your security model.

Exactly what is it that you are trying to defend against?  What is
programmer A trying to hide from programmer B?  Is this intended to be a
method that can be used to protect trade secrets embodied in Scheme
programs that you ship to customers?  Or to protect programmers working on
the same project from each other somehow?  (In that case, does the security
of the rest of the programming environment they share matter?  Does it
matter if they have access to each other's source code?)  Or is this just
to protect a single programmer from himself somehow?  Can you give me a
realistic scenario in which this passkey stuff protects some realistic
thing from some realistic threat?

Once I understand that, then perhaps you can explain to me why allowing

  (let ((opaque-up ...)) ...)

would compromise that kind of security (whatever it is).

				- Alan