Richard Kelsey <xxxxxx@s48.org> 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