This page is part of the web mail archives of SRFI 0 from before July 7th, 2015. The new archives for SRFI 0 contain all messages, not just those from before July 7th, 2015.
> Many thanks, Marc, for the new draft. It's a definite improvement. Good... forward progress! > >From a first look (I'll have a second look tomorrow), > I'd still like to suggest two things to be addressed: > > - Import of feature implementations (IMHO) *needs* to be made > explicit. Scheme implementations which load additional features > on-demand (such Scheme 48) would *have* to say NO to any feature > requested. That is not true. "cond-expand" has to be built-in. So implementors have to add some built-in support in their implementation to use SRFIs. Some other features also have to be built-in in a practical implementation of Scheme, for example, it is hard to imagine how support for Unicode characters and strings can be loaded on demand (at least with the Unicode SRFI I talked about at the workshop). And even if an implementation is able to load on demand Unicode support (because it uses a character and string representation that is extensible at run-time), then this ***ability** is a feature of the implementation which has a global nature (***it*** has to be built-in). When we first started talking about SRFIs, it was this latter kind of feature I had in mind (as I've said before, other SRFIs such as SRFI 1, should be handled by a separate mechanism because they are really modules that any Scheme implementation can support by loading a portable implementation). To accomodate implementations that wish to have as little built-in extra stuff as possible (load on demand systems), some other mechanism is required such as a separate configuration language (yes, specified in another SRFI). A separate configuration language seems like an interesting approach for load on demand systems but it is not the only one, and I don't feel confident enough in this approach to propose it in SRFI 0 (remember that I want SRFI 0 to last). Why do you insist on having this in SRFI 0? > In the present form, there's little chance that Scheme > implementations with such a design philosophy will adopt the present > draft. I disagree. The present draft of SRFI-0 says nothing about the existence or absence of a configuration language or similar construct (e.g. "import-implementation"). If some implementors feel a need for this, there are plenty of SRFI numbers left for their proposal(s). ;-) I'm more worried of the inverse situation. A configuration language gives a **static** structure to the program, and this may be incompatible with the philosophy of more dynamic Scheme implementations that allow loading and discarding features over the course of an interactive session. I don't want to force an implementor to buy into a configuration language or other mechanism if they just want to support "cond-expand" and a few SRFIs. > - By now several Scheme implementors have expressed their preference > for a separate configuration language. Richard, of course, Will, > Donovan, and the Rice folks. Is there a strong reason *not* to do > it this way? Yes, freedom of implementation. Marc