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.
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. The R6RS does not specify any portable semantics for versions, which was indubitably silly but had the virtue of allowing implementations to ignore versions altogether. Implementations that support this draft SRFI would not be able to ignore versions altogether. They would be required to implement *some* semantics for versions. In particular, they would be required to implement a semantics that is arguably inconsistent with the intent of the R6RS editors. Yet this draft SRFI still stops short of requiring any portable semantics for versions. That sounds like the worst of all possible worlds. In addition, the inclusion of versions changes the mapping from library names from a one-to-many mapping to a one-to-infinite mapping. I understand that it's implementable, but it changes the nature of the beast. In particular, it would be harder for humans to map library names to file names, which goes against one of the the alleged goals of this draft SRFI; in particular, it goes against the alleged rationale for discarding all but the first library in a file (see below). 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. 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. 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. 3. Failure to specify which characters are encoded. If you don't specify which characters are encoded, then one of two things will happen. (I don't yet understand the draft SRFI well enough to understand which of the following disasters it would require, but it would require one of them.) One possibility is that different implementations will require different sets of characters to be encoded, so moving files of portable libraries from one implementation to another will continue to involve wholesale renaming of files. Removing that necessity, it seems to me, is the main thing this SRFI should accomplish. The other possibility is that every implementation must support all possible sets of rules for encoding characters, so the mapping from library names to file names becomes one-to-infinite instead of the one-to-many mapping that most implementations must already support. That makes implementations more complex and more fragile. It also makes collections of portable code more complex and more fragile. In particular, it would be harder for humans to map library names to file names, which goes against one of the the alleged purposes of this draft SRFI; in particular, it goes against the alleged rationale for discarding all but the first library in a file. 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. 5. Implicit file names. If the reduction of clutter to be gained from implicit file names were truly worth increasing the number of files that must be examined in order to locate a library, then this SRFI would allow more than one library per file. Allowing more than one library per file would actually reduce the number of files, instead of just allowing a small number of special cases to be moved into a different directory. I'm not arguing that this SRFI should require implementations to allow more than one library per file so much as I'm arguing against implicit file names. If you won't consider the more useful feature (which this draft SRFI would outlaw), then it's silly to consider a much less useful and less general special case. Will