Re: A (Low-Level) Opaque Object Proposal for R5RS

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

|   Date: Mon, 29 Apr 96 01:13 EDT
|   Cc: rrrs-authors@martigny.ai.mit.edu
|   Reply-To: jaffer@ai.mit.edu
|   From: Aubrey Jaffer <jaffer@martigny.ai.mit.edu>

|   OPAQUE data seems to be related to weak pointers.  If the key for some
|   OPAQUE data has been lost, then, subject to the reconstructability of
|   keys, all OPAQUE data with that key can be collected, because it
|   cannot be ELUCIDATEd again.  If it were collected, then EQ?-ness
|   (different data being not EQ?) of OPAQUE data would then not be
|   guaranteed.  That is not necessarily bad -- it might make OPAQUE data
|   more secure if unauthorized pointers to it were subject to change.

Opaque data can be implemented in terms of weak-pointers, disjoint
types, and the opaqueness we currently have in procedures.

A module/fragment that wants an opaque type can implement it as a
disjoint record type type whose only element is an integer (a bignum).

The bignum indexes into a hash table, implemented with weak pointers,
to produce the "real" data.

The hash table is lexically visible only to the exported interface and
internal procedures.

If a hash-table lookup fails, it means that someone is trying to fake
a reference and the interface routines can signal an error.