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.
In both Marc Feeley's original SRFI 0 and in the SRFI editors' revised version, programs and their configuration (e.g. what SRFI's they use) are intermixed. I think that this is a mistake for a number of reasons: - I have found that more than minimal use of C's #ifdef construct, which is similar to IF-IMPLEMENTS and COND-IMPLEMENTS, makes code extremely hard to read. - Both people and programs need to read the entire source to see which SRFI's might be needed. In the revised SRFI 0, ambiguities can arise if an identifier appears before the IMPORT-IMPLEMENTATION form that defines it. Does the entire source have to be read before evaluating the first form? Does it all have to be macro expanded before evaluating the first form? - It may be difficult to implement either version of SRFI 0 in the presence of a module system. This is certainly the case with Scheme 48. I would like to propose that we have a separate configuration language, one that is not embedded in Scheme. Below is a suggestion for such a language. It is not quite as flexible as either version of SRFI 0, in that features can be tested only at top level, and not in nested expressions. I doubt that this would matter much in practice, given the ease of writing both procedural and syntactic abstractions in Scheme. In return we get a very simple and portable configuration language that avoids any confusing interaction with the underlying Scheme's syntax and semantics. -Richard Kelsey ---------------- Configuration language syntax: <program> --> (program <program clause>+) <program clause> --> (requires <feature-identifier>+) --> (reader-syntax <feature-identifier>+) --> (files <filename>*) --> (code <body>) --> (feature-cond <feature-cond clause>+) <feature-cond clause> --> (<implementation requirement> <program clause>+) <implementation requirement> --> as in the SRFI editor's version of SRFI 0 <feature identifier> --> as in the SRFI editor's version of SRFI 0 ---------------- Semantics: Given a set of available features and a configurable reader, a <program> can be read in as a list of S-expressions to be evaluated. No macro expansion is required to read a <program>. Each implementation would provide some way for loading a program. For example, it might have a (LOAD-PROGRAM <filename>) function or a compiler that compiled a program into an executable file. The meanings of the different clauses are given below. The ordering of the clauses in a <program> is significant. It determines both the order of the forms in the final program and which reader is used to read different sections of the program. (requires <feature-identifier>+) The listed features are required by the program. If one or more is not provided by the implementation the program cannot be run. (reader-syntax <feature-identifier>+) The listed features determine the lexical syntax of the program from this point on. If one or more of the features is not provided by the implementation the program cannot be read. [Personally, I do not think changes to the lexical syntax are a good idea. At a minimum they should be restricted to the #... syntax. Scheme programs should have something in common.] (files <filename>*) The listed files are read, using the current lexical syntax, and the forms they contain added to the program. (code <body>) The forms in <body> are read, again using the current lexical syntax, and added to the program. (This requires that the syntax of `)' not be changed by any SRFI). (feature-cond <feature-cond clause>+) The meaning of a FEATURE-COND clause is that of the <program-clause>s in the first <feature-cond clause> whose <implementation-requirement> is satisfied by the implementation. Unlike the proposed COND-IMPLEMENTS, the implementation has no leeway in choosing which clause to use (down with ambiguity!). ---------------- Implementation: Available on request. The portable part of the implementation would be a READ-PROGRAM function that took three arguments: an input port, a list of symbols indicating the features available in the current implementation, and a make-reader function that took a list of symbols representing features and returned a READ-like function that supported those features. READ-PROGRAM would return two values: the forms of the program as a list of S-expressions and a list of the features used by the program. Both this list and any lists passed to the make-reader function would be subsets of the features list passed to READ-PROGRAM.