How to "signal" (or "require") that a certain Scheme implementation provides a certain SRFI Ciprian Dorin Craciun 28 Mar 2018 14:09 UTC
So while indexing the SRFI's available in Chibi scheme (see the other thread), I've observed that there were two SRFI's that although are supported by Chibi are not available to import due to their nature: * SRFI 22 -- the one about running Scheme scripts on Unix; * SRFI 62 -- the one about s-expression comments (which are also required by R7RS); Now indeed, as Alex Shinn pointed out, there is nothing to export from those SRFI's as they are "builtin" in the Scheme interpreter and tightly coupled with it. However it made me wonder why shouldn't there be an actual import, even though it wouldn't do anything? For example in case of SRFI 62, by using `(import (srfi 62))` one explicitly states that one wants the interpreter to support value comments. If the interpreter doesn't support value comments, then the import would fail, and if it does support it it would just import nothing. (Else if the module uses such comments, and the interpreter doesn't support them, the user will end up with a syntax error and not with an explicit message like "SRFI-62 not available".) In case of SRFI 22, a script starting with `(import (srfi 22))` would explicitly state that this file is not a module, and it should in fact be executed as a "script". In case the interpreter was started as such it would succeed, else it would fail. What I am proposing is that for any SRFI, if the interpreter supports it in any way, even builtin, the statement `(import (srfi n))` to succeed. Moreover any "portable" Scheme library or script, if it requires a certain SRFI to function it should always import it. Moreover, there is the `features` (and `cond-expand`) mandated by R7RS, however it doesn't contain anything related to SRFI. Shouldn't there be some standard (as per SRFI) way to use it to flag that a certain SRFI is available? The advantage of doing so would be that one could write "portable" SRFI's in the sense that in the case the SRFI doesn't have a "hard" requirement of a certain SRFI, and that dependent-upon SRFI doesn't exist, the original SRFI could provide some sub-optimal implementation for the required functionality. (I remember reading some SRFI's about records or such, and they state that certain features could be implemented "like so if SRFI-X exists" or alternatively "like so if SRFI-Y exists", etc.) Even the SRFI-0 (which defines the `features`) states: ~~~~ The SRFI registry is used for this purpose. It is expected that features will eventually be assigned meaningful names (aliases) by the SRFI editors to make reading and writing code less tedious than when using "srfi-N" feature identifiers. ~~~~ What I am proposing is that for any SRFI that a particular implementation supports, it should also provide the symbol `srfi-n` in the `(features)` output, just as envisioned by the original SRFI-0. Ciprian.