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