This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.
On Sep 26, 2009, at 4:20 AM, William D Clinger wrote:
I haven't had time to read this draft SRFI carefully, but I want to report several problems that I perceived during my first quick reading: 1. Treatment of versioning. 2. Ignoring all contents after the first datum. 3. Failure to specify which characters are encoded. 4. Specification of ordering but not matching. 5. Implicit file names. 1. Treatment of versioning.
I agree that R6RS versioning should be dropped from this SRFI (though I have not read the text that I just snipped).
2. Ignoring all contents after the first datum. Taken literally, that is a recipe for disaster. For example, the R6RS permits implementations to extend the lexical syntax of Scheme with a datum of the form #!fold-case or #!larceny or similar, and many systems have added such extensions. Requiring all contents that follow a #!fold-case datum to be discarded is silly.
Taken literally, yes, but #!larceny or whatever is not something you'd put in a library intended for running under multiple implementations.
Requiring all contents to be discarded following the first library is silly as well. As demonstrated by Larceny, allowing multiple libraries within a single file reduces clutter. I am not going to argue that this SRFI should require implementations to support multiple libraries within a file, but *requiring* implementations to discard all but the first library within a file serves no purpose other than to ensure that Larceny will not support this SRFI.
I'm sure this is not the intent.
This SRFI should state that files conforming to this SRFI must have only one library per file. This SRFI should not require implementations to ignore all but the first library in a file.
There are systems that conform to this SRFI and there are libraries that conform to this SRFI. If someone puts multiple libraries in a file, then that's outside of this SRFI anyways (and the file should probably have an implementation extension as well in that case). Besides, implementation-specific files need not contain R6RS libraries at all. A PLT file for example might contain a PLT module, but a plain vanilla library file must be something that all implementations understand and that's a single R6RS library. So, I don't know what changes you're asking for here.
3. Failure to specify which characters are encoded.
This is already under discussion.
4. Specification of ordering but not matching. I don't even pretend to understand this issue, but what is the point of specifying a detailed ordering "as the precedence for choosing a match" if the actual matching is going to be implementation-dependent? One thing I *do* understand is that the R6RS pseudo-semantics for versions is part of the problem here. This SRFI would do better to drop versions altogether, as was explicitly urged by six voters as one of the well-informed reasons they gave for voting against ratification of the R6RS in the form that was, unfortunately, approved.
I agree that versioning should be dropped and if there are any unnecessary ordering specifications, we should inspect them then.
5. Implicit file names.
This is already under discussion and I agree that they should be dropped (but not for the reasons I just snipped).