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.
Hi Marc, many thanks for the prompt reply! >>>>> "Marc" == Marc Feeley <feeley@xxxxxxxxxxxxxxxx> writes: >> - 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. Marc> That is not true. "cond-expand" has to be built-in. I probably wasn't clear enough. Of course, COND-EXPAND has to be built-in for SRFI-dependent code to be loaded. By implication, SRFI 0 itself is not I feature I'd have to request, therefore. There's no reason why any of the other features would have to be built-in. Marc> So implementors have to add some built-in support in their Marc> implementation to use SRFIs. Some other features also have to Marc> be built-in in a practical implementation of Scheme, for Marc> example, it is hard to imagine how support for Unicode Marc> characters and strings can be loaded on demand (at least with Marc> the Unicode SRFI I talked about at the workshop). And even if Marc> an implementation is able to load on demand Unicode support Marc> (because it uses a character and string representation that is Marc> extensible at run-time), then this ***ability** is a feature of Marc> the implementation which has a global nature (***it*** has to be Marc> built-in). When we first started talking about SRFIs, it was Marc> this latter kind of feature I had in mind Sure. At the very least, this is something that needs to be stated very explicitly in the SRFI. It seems the main communication problem we're having right now is that we see different kinds of SRFIs to be under the purview of SRFI 0. Marc> (as I've said before, other SRFIs such as SRFI 1, should be Marc> handled by a separate mechanism because they are really modules Marc> that any Scheme implementation can support by loading a portable Marc> implementation). Exactly. As it has turned out, all SRFIs proposed so far, except for the uniform-vector proposal, *are* "other" SRFIs. It's not that there isn't a case to be made for differentiating between these kinds of SRFIs---it's just that both the editors' as well as Richard's proposal address both with a minimum of additional overhead. In fact, in an implementation where everything's built-in, explicit import just reduces to a no-op. So why not put it in? Marc> To accomodate implementations that wish to have as little built-in Marc> extra stuff as possible (load on demand systems), some other mechanism Marc> is required such as a separate configuration language (yes, specified Marc> in another SRFI). A separate configuration language seems like an Marc> interesting approach for load on demand systems but it is not the only Marc> one, and I don't feel confident enough in this approach to propose it Marc> in SRFI 0 (remember that I want SRFI 0 to last). Why do you insist on Marc> 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. Marc> I disagree. The present draft of SRFI-0 says nothing about the Marc> existence or absence of a configuration language or similar construct Marc> (e.g. "import-implementation"). If some implementors feel a need for Marc> this, there are plenty of SRFI numbers left for their proposal(s). ;-) Requiring these implementors to add a separate configuration language would entail two things, however: - A user would have to duplicate information, because SRFIs needed by the code would have to be imported elsewhere. - Software dependent on SRFIs can no longer be shipped in a portable way. Admittedly, neither of these is necessary, but I think they're both desirable. Marc> I'm more worried of the inverse situation. A configuration language Marc> gives a **static** structure to the program, and this may be Marc> incompatible with the philosophy of more dynamic Scheme Marc> implementations that allow loading and discarding features over the Marc> course of an interactive session. This is not impaired by a separate configuration language: We cannot really take away SRFIs used by code already loaded because COND-EXPAND is static. We can absolutely take away SRFIs from code loaded in the future. The specification of a separate configuration language in no way requires an Scheme system to actually implement it that way; it just requires a syntactic binding to introduce a program dependent on SRFIs. Richard's suggestion was simply PROGRAM, I believe. Marc> I don't want to force an Marc> implementor to buy into a configuration language or other mechanism if Marc> they just want to support "cond-expand" and a few SRFIs. But the overhead of the configuration language is absolutely trivial for these folks. Everything but COND-EXPAND just reduces into a no-op. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla