On Tue, 20 Sep 2005, Michael Sperber wrote:

> 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.

Ah, I see.  In the early submission, I didn't realize that the intended
meaning of "library status" was that the facilities were optional.

Is there established terminology for portions of SRFIs that are optional?
SRFI-0 doesn't really handle optional features... how could a program test
for such a thing?  SRFI-0 does allow for a "SRFI registry" that allows for
feature identifiers other than SRFI-nn.  I could imagine having the SRFI
itself specify the associated sub-identifiers, and so that, e.g.:

   (if-implements SRFI-76/reflection
     (do-my-reflective-thing)
     (fake-out-reflection-support))

would work.

Of course, this SRFI is R6RS-track.  Since as far as I know there is no
intention to assign optional features of R6RS to feature identifiers, I
guess the "optional parts of SRFIs" issue is moot anyway.

> This SRFI will be withdrawn anyway, so splitting up the SRFI document
> itself doesn't seem to bear any particular advantage.

-- Donovan Kolbly                    (  xxxxxx@rscheme.org
 				     (  http://www.rscheme.org/~donovan/