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.
Richard Kelsey <kelsey@xxxxxxx> writes: > > 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? I'm unsure what you're actually suggesting---in a typical Scheme system, *some* part of the system (specifically, the implementation of the record system itself) will need to look at the rtd of a record, whether it's opaque or not. I don't see how you could restrict the availability of reflection information in general without severely limiting choices available to implementors. I can imagine "secure" Scheme systems or Scheme systems offering a "secure" mode which don't make the reflection information available for opaque record types in any manner, and other Scheme systems (or modes) that allow their special debugger to look at the stuff. If there's another SRFI, those Scheme systems would have a choice implementing it or not, and the users can make appropriate choices depending on that. > 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. It's been our full intention to allow implementations to leave out the reflection stuff---in fact, we had language to that effect in the submitted draft, but it was deemed to confusing and got dropped in the editorial process. If and when this goes into a SRFI, I expect the reflection stuff will end up in a separate, optional "library module" (or whatever it will be called). So, in essence, I think we're in full agreement here. This SRFI will be withdrawn anyway, so splitting up the SRFI document itself doesn't seem to bear any particular advantage. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla