This page is part of the web mail archives of SRFI 55 from before July 7th, 2015. The new archives for SRFI 55 contain all messages, not just those from before July 7th, 2015.
campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
There seems to be two parts to the rationale:
- SRFI 7 isn't incremental or linear, so it's not designed to work
interactively.
- SRFI 7 doesn't specify the precise _loading_ of features' code.
I have several problems with this. To the first part, I really don't
see any need for standardizing interactive features. If you're using a
specific implementation's interactor, well, you're going to be doing
stuff that's really implementation-specific anyways, and to make an
attempt to standardize all interactive Scheme features would be simply
silly. And anyways, SRFI 7's clauses could easily be adapted to some
form of interactive declarations.
SRFI-55 is not mainly about interaction. It's one possible application, where `require-extension' would simplify loading/importing of external libraries (SRFIs in this case), but could be used in any other context as well.
The second part of the rationale is more significant. First of all, SRFI 7 defines a language for specifying the dependencies of a Scheme program. SRFI 7's intent is _not_ to specify a program loader -- for example, a SRFI 7 processor for which it would make no sense to perform loading of necessary features might be a dependency analyzer --; but SRFI 7 _does_ suggest that a program loader exist somewhere in a Scheme system that purports to support SRFI 7, and a useful program loader_would_ indeed load the necessary features.
I don't think one should make too much effort interpreting certain features into overly vague specifications. If the author of SRFI-7 did indeed have something like "loading" (in any possible sense) extension libraries into the system, then he could have specified it as such. SRFI-55 specifies what SRFI-7 only (and incompletely) hints at.
If someone wrote a SRFI 7 program loader that didn't actually load the features, why would they write a SRFI 55 program loader that _did_?
Sorry, I don't get the point here.
(Unless that person had the initials FLW and was the author of a Scheme->C compiler based on Henry Baker's Cheney on the MTA garbage collection & compilation system...)
Oh, I know from good sources that this particular compiler will drop SRFI-7 in the next release...
Furthermore, SRFI 7 even suggests that implementations that purport to 'support SRFI 7' provide a front end to their compilers or program loaders for SRFI 7, whereas SRFI 55 doesn't even suggest that!
No, why should it? `require-extension' *is* the front end. What are you talking about?
Now, I am also troubled by the design of SRFI 55. It has the _exact_ same problems that Kelsey argued against in the SRFI 0 discussion list and for which reason Kelsey 'responded' to SRFI 0 with SRFI 7! Specifically, it is embedded in Scheme, which is utterly incompatible with certain module system designs that cleanly separate the metadata that the module system provides about the source and the source data itself; in an example such module system, Scheme48's, it would require absolute contortion to the system to make this operate correctly, and so I can envision the Scheme48 developers to, indeed, _not_ provide a useful program loader for SRFI 55, while it already has a useful one for SRFI 7!
Fine. Then I suggest that the authors of Scheme48 do not support SRFI-55. I don't have a problem with that. In fact, I think that's one of the great properties of the SRFI system.
Now, if all you want is for SRFI 7 to specify that, if a program loader is supported, it should try to load the necessary features, if possible, (way too many conditional clauses there...sorry...), why isn't this SRFI just a brief amendment to the wording of SRFI 7?
Because I find SRFI-7 incredible inconvenient and total overkill (IMHO, AFAICT, etc. etc.). Why do I have to learn a new language just to use `iota'? Please survey the current Scheme implementations, you will be surprised how many of them provide `require-extension' in one form or the other. cheers, felix