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 ( d.kolbly@xxxxxxxxxxx ( http://www.rscheme.org/~donovan/