Re: opaque record types

[Richard Kelsey <kelsey@xxxxxxx>]

   From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
   Date: Tue, 20 Sep 2005 12:34:40 +0200

   Richard Kelsey <kelsey@xxxxxxx> writes:
   > I have several of questions about the 'opaque'
   > option.
   >
   > - Why are its effects limited to the reflective
   >   procedures? 

   Where else could the effects extend?

To any debuggers, portable or nonportable.  Suppose I write
a SRFI that includes a different set of reflective procedures.
Is it okay if the procedures in my SRFI ignore the 'opaque'
option in SRFI-76?

   >   Should implementation-specific debuggers be allowed to inspect
   >   opaque records?

   That seems a philosophical question.  I don't think there's anything
   in the draft that would forbid this, or that there could or should
   be.  The opacity just extends to portable programs.

That is a stronger statement than the one you make above.
Do you mean portable programs that use the reflective
procedures in SRFI-76 or all portable programs?  From
what you are saying it seems that the 'opaque' option
is a restriction on the particular reflective procedures
in SRFI-76 and has no other intent.  This seems very odd.
Why does it matter how the reflective information is made
available?  What is it about these particular reflective
procedures that makes you want to restrict them?

   >   It seems very un-Scheme-like to explicitly restrict programs and
   >   implementations in this way.  A program that runs in an
   >   implementation that implements this restriction will get the same
   >   result in one that ignores it.

   I'm unclear what the Scheme-like position here is.  Procedures are
   opaque, too, and the same people that have argued historically
   that record types must be transparent have argued that procedures
   should, too.

But you aren't making the records opaque, you're just
making them opaque to programs that use these particular
reflective procedures.  I think it would make much more
sense to put the reflective procedures in a separate SRFI.
People who don't like reflection can simply not implement
the SRFI or use implementations that don't have them,
or not use portable debuggers.  Once you say that some
records are transparent and others are not you enter the
world of information security, something not to be done
lightly.
                                    -Richard