Date: Sun, 08 Jan 2006 11:30:30 +0100
   From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

   There are many issues here, but I will say this for now: the opacity
   model in the SRFI is not intended to provide any kind of security
   feature.  The Rationale section states this quite clearly.

Right.  I think, though, that security is a real and justifiable
motivation for features, whereas the enforcement of opacity to impose
abstraction barriers, well, goes against the whole point of the
reflection layer in the first place.  There are illegitimate uses of
reflection, but there are also illegitimate uses of source code to
find unintended properties that other code can rely on (and thereby
become very fragile).  If you're worried about violating abstractions,
you shouldn't use reflection -- but if you have a good reason to cross
abstraction boundaries, such as to write an object inspector, then
there is no reason for the implementation of the abstraction to
inhibit this (except security, which is a different issue altogether).

(This all assumes the existence of the reflection layer in the first
place, of course.  What does opacity of record types defined with
DEFINE-RECORD-TYPE mean if there is no reflection layer, which I
assume could be the case if the SRFI were separated into parts and the
reflection layer made optional?)