This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.
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