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.
> I think we editors have pretty much adopted Richard's view that the > whole feature business should happen in a separate configuration > language. His message is at: > > http://srfi.schemers.org/srfi-0/mail-archive/msg00020.html I've looked at Richard's proposal and, generally speaking, the idea of a separate configuration language for programs is compatible with the cond-implements form as I see it but it is not the only way to go. I don't want to discuss the specifics of Richard's proposal at this point because I think this would be premature. The fundamental problem is that we want a way to express the fact that a certain piece of code in our program (a "chunk" so as to not use the term "module") is dependent on some SRFI. Richard's proposal places this information outside of the chunk. It seems to me that the only reasons for doing this is that we don't have a formal notion of what a chunk is (i.e. a scope) and a way to define chunks and the things it is dependent on (other chunks, SRFIs, etc). This cries out **MODULE SYSTEM** to me. Yes I know that we don't currently have a module system, but this is clearly where such information should be placed. Note that I'm not saying that a configuration file for programs (such as the one suggested by Richard) doesn't have a place. In fact, I'm pretty sure such a thing is useful to glue the various modules together. All I am saying is that, for modularity reasons, the SRFI dependency information should be put on the module, not in the program configuration file. As an example (intentionnaly naive), if we defined a "module" to mean a source file, then we could say that the first couple of forms in that file declare the dependency information and the scope of these declarations extends to the end of the file. Matthew Flatt's variant of Richard's external configuration language is a more modular approach, closer to what I have in mind. However, I think this should not be part of SRFI-0 and the reason is simply that we need something **NOW**. Agreeing on a module system will take a long time. So what I want to propose for SRFI-0 is simply a cond-implements form that tests for the presence of a feature. Future module system SRFIs or configuration language SRFIs can provide mechanisms for requiring that the Scheme implementation provide a particular feature, possibly limited to the scope of a particular module or whatever. Until such module SRFIs surface (!) it will be up to the user of a piece of code to add whatever is needed for their Scheme implementation to satisfy the cond-implements forms that are found (in fact I can easily imagine an automatic tool, supplied with each Scheme implementation, that would do this automatically... i.e. the tool tries to load the program and, if it bombs at load time because some SRFI hasn't been put in the configuration file, it adds this dependency to the configuration file, and tries to load the program anew). What isn't obvious to me is how to word SRFI-0 so that it will be compatible with future module SRFIs (in my original proposal feature identifiers had global scope, i.e. a particular feature either is available in all parts of the program or is not, but the notion of a not-necessarily-global "feature identifier scope" has to be part of SRFI-0). Marc