[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why would anyone want opacity?
I am sorry it has taken me so long to reply.
>--------------------------------------------------------------------------
> > Dybvig has dug in his heals insisting on full absolute unbreakable
> > opacity.
>
> I haven't dug in my heels or insisted on "full absolute unbreakable
> opacity".
>--------------------------------------------------------------------------
I based my remark on the following:
>Return-Path: <dyb@cs.indiana.edu>
>Date: Wed, 24 Apr 1996 16:44:40 -0500 (EST)
>To: shriram@cs.rice.edu
>Subject: Re: Generative record types
>Cc: rrrs-authors@martigny.ai.mit.edu
>
>1. I am in favor of opaque types, and object to the make-record-type
>proposal on the grounds that it builds into the language support for
>breaking abstractions.
I see that you have since relaxed your objection to ``building into the
language support for breaking abstractions'' through your compromise with
Bill.
>--------------------------------------------------------------------------
> I should also point out that even your assumption that eq? implies
> %passkey-match? is not guaranteed by the wording of your proposal. It
> would certainly be worth adding a guarantee to this effect. As it
> stands, an implementation may define %passkey-match? as follows, for
> example:
>
> (define %passkey-match?
> (lambda (x y)
> (and (not (eq? x y))
> (equal? x y))))
>
> This would be silly, of course, but valid.
>--------------------------------------------------------------------------
Would it suffice to add this second sentence to the original Note from the
formal proposal?:
--------
Note 1 This proposal explicitly does not define what it means for two
-------- <passkey>s to ``match''. However, an implementation's passkey
match mechanism must be reflexive, i.e., for passkeys x and y,
if (EQ? x y) is true then x and y ``match''.
>--------------------------------------------------------------------------
> Have you considered predicates in place of passkeys? This would give
> the programmer control over the matching process rather than the
> implementation.
>--------------------------------------------------------------------------
I thought the following from the original proposal covered that:
--------
Note 1 This proposal explicitly does not define what it means for two
-------- <passkey>s to ``match''. Etc.
--------
Note 2 This proposal is also intentionally silent about what sort of data
-------- structure a <passkey> is. This is so implementors can experiment
with a variety of data, from simple lists to more interesting
encrypted strings to filenames of encrypted key escrow boondoggles
to user-interactive challenge/response procedures, and so on.
Since Note 2 clearly suggests that procedures may be used as passkeys,
coupled with the explicit mention in Note 1 that the passkey matching
mechanism is not specified, I believe this wholly supports the
procedure-based matching you seem to be suggesting.
> > (Aside: I'm going out on a limb on this, but consider this: you could even
> > use as a passkey... the result of a call to MAKE-OPAQUE-TYPE !! Since 1)
> > each new opaque type is specified to not be EQ? to any other datum, and
> > since 2) Kent's kernel-level %PASSKEY-MATCH? could be made to return #F on
> > non-EQ? opaque types, and since 3) one presumably could not crack an
> > OPAQUE-VEILed datum to expose its passkey in Kent's Scheme implementation,
> > using an opaque type as a passkey for your record implementation would be
> > completely system trackable and not user forgeable. This way you would not
> > even need a separate ``make unique object'' hack like the one I posted to
> > the Scheme Digest. Anyway, this was too amusing to me not to mention it.
> > It also dramatizes the comment from my proposal that with MAKE-UNIQUE-TYPE
> > one would need no other additional mechanism for making new unique data
> > types.)
>
> Unfortunately, since this presumes a particular %passkey-match?
> implementation, my analysis would again not be portable.
>--------------------------------------------------------------------------
I have no idea what you mean by ``my analysis would again not be
portable''. What does it mean for an ``analysis'' to be portable. What is
the input domain of an ``analysis''? What is its output domain? What is it
that you want to be portable? The program that implements your analysis?
The output of your analysis as a Scheme program?
Since you have never said a word about this mythical ``analysis'' you keep
alluding to, I have no way to guess what is inside your head. Pointing to
a loosely related thesis in preparation does not help. As long as you
persist in playing this like an invisible trump card, there is no way I
can continue this discussion in any productive or meaningful way.
>--------------------------------------------------------------------------
> Moreover, it
> ruins the orthogonality that you've been working to preserve, since the
> opacity of opaque records depends upon the design of %passkey-match.
>--------------------------------------------------------------------------
Sigh. Once again you have not understood me.
I was merely suggesting that a) you, Kent, as an implementor are allowed to
choose whatever passkey match mechanism you as an individual want to
provide in your Scheme implementation, and b) with a sufficiently
constrained choice of said passkey match you as an implementor could then
choose to layer your implementation of opaque records atop your
implementation of opaque objects.
So, I am not ruining anything. I am merely pointing out design
alternatives. I was trying to hint at what might be possible, not what
should be required. This is why I left such wide latitude in the opaque
object proposal.
Unlike others on this list, I do not seek to legislate style or restrict
people's choices. Perhaps you have confused my motives with those of
others.
As much as I try to permeate my suggestions with disclaimers, I fear I will
never be able to avoid confusing those who seem determined to misinterpret
my posts or those who are intent on routing my efforts to contribute
constructively to this forum.
<< C'est le guerre.>>