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 yet read the newer posts since the one responded to below, which might influence my views, and I could probably spend more time editing what I've written below, but I think it's good enough to give an accurate conveyance of the reasons I've had for the decisions I've made which shaped the current draft. On Fri, 2009-09-25 at 21:20 -0400, 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. > > 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. I wish R6RS's versioning were more clear also, but my current perspective makes me understand why it wasn't specified in more detail. One of my intents for this SRFI is to try to make some progress towards supporting versioning. Given the complications involved (IIUC), which implementations need to handle in differing ways appropriate to their particular natures and ideals, SRFI 103 wants to support both people who want versioning and people who don't. > Implementations that support this draft SRFI would not > be able to ignore versions altogether. They would be > required to implement *some* semantics for versions. That's true, and I think if enough people want versioning in library names and references, then it's worth requiring implementations which want to support portability to at least understand a file naming scheme which involves versions and to at least prevent libraries which do not meet version constraints from being used. My intent for this SRFI is to not require implementations to do any version handling beyond loading the first-processed-import-clause's library which is a match according to that import clause's version reference constraint (with matching extended in the one additional way this SRFI describes), whatever version it may be, nor any version handling beyond failing if other library references, to the same library but with version constraints which are not compatible, are encountered in other import clauses. If subsequently-processed (in whatever implementation-dependent order) import clauses of the same library but with a different version reference constraint which is not compatible with the version of the first-processed and already-chosen version of the same library occurs, then implementations are free to just immediately fail and say "incompatible version references for library (foo bar) ...". However, if the combined versions are compatible, meaning that whatever implementation-specific loading-order did not fail, then the versions used do meet all the given version constraints and so are supposedly okay according to the given version references. Having at least this degree of portable version handling allows the file naming scheme to be portable for users on opposite sides of this issue, and it ensures programs will not run with versions of libraries which do not match the version constraints. Implementations are free to just bail and say "My implementors don't like versioning so I won't do anything more to help you deal with using all these libraries with their version reference constraints". And other implementations are free to provide additional external-from-library-references mechanisms of specifying which exact version of a library to use to deal with the inherent problem of how to satisfy all the combined version constraints. My current understanding is that this is as good as it can get if we simultaneously want to support portability for people who want versioning and to support implementors who don't want to deal with the complexities of versioning. I agree it's not a beautifully simple nature, but if people want enforced versioning in library references, and I can understand why, then why can't we go so far as to at least require that implementations understand a file naming scheme supporting versions (which I think is simple) and at least honor the version reference constraints by not using a library which violates them (which I think is relatively simple)? > In particular, they would be required to implement a > semantics that is arguably inconsistent with the > intent of the R6RS editors. What do you mean exactly? I don't know all the details of the history. Do you mean that their intent was to allow implementations to be unsupporting and oblivious to R6RS's versioning? If some people want versioning, how is being unsupporting and oblivious to their versioned libraries helping portability? > Yet this draft SRFI still > stops short of requiring any portable semantics for > versions. It intends to support portability to the extent that it's required that libraries which do not match all the combined version constraints will not be used, and whatever ways the issue of incompatible imports occurs and is dealt with is implementation-specific. > That sounds like the worst of all possible worlds. To me, it sounds better than excluding the people who want to use versioning. I have a few libraries I've put versions in their names and referenced them with version constraints because not all the versions of the libraries, created and originally-distributed by others, will work. I want to make clear that I can see why some people desire version constraints to be in import clauses' library references and why some people desire being able to have multiple versions available for use by different programs which require different versions. > 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. If you consider the version to be part of a library name and require that library file paths exactly represent the library name, and therefor the files for libraries with versions are required to have the versions in the file names, then it is not a one-to-infinite mapping and it is a one-to-many mapping just as like for libraries without versions. > 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; Why is that? A library name with a version maps to a file name with the version just as easily as a library without a version maps to a file name without a version. > in > particular, it goes against the alleged rationale > for discarding all but the first library in a file > (see below). I don't understand why this is, even after analyzing your below comments. My rationale for single-library files is primarily to be able to have one-to-one mapping of library file paths to library names. [------------------------------------------------------------------------------] > 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. I thought #!identifier lexical tokens are considered comments at a level below "syntactic datums". I, of course, meant the first thing the standard read procedure would return. I thought calling that a "datum" was the normal terminology. Whatever is the most recognized way to say that, I'll change it to. > 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 agree it can reduce clutter and be convenient. But it sacrifices the ability to have a one-to-one mapping of library file path names to library names. Having that ability is my main reason for promoting single-library files (more below). The other reasons I tried to succinctly describe in the current draft are secondary, and, IMO, important additional benefits. > 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. It wasn't my intent to prevent Scheme implementations from supporting multiple libraries in a file. The intent of this SRFI having only single-file libraries is so path names can be mapped to library names, and, secondarily, so finding a library's file when you don't know where it's located does not involve as much hunting-down. I think the simpler and one-to-one mapping nature of single-library files is the better option to make the portable requirement. > 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. That is how I wanted it to be. I thought my saying: Library files are files which contain one library form as the first syntactic datum, and they are files whose path exactly represents the name of the contained library. Any additional contents after the first datum are ignored by this SRFI. was clear enough to mean that the ignoring of additional things-`read'-would-see is only applicable in the context of conformance to this SRFI. I'll gladly reword it to what is the best way to convey that. [------------------------------------------------------------------------------] > 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. Because of certain OSs' and shells' nuisance-character prevalence, I agree this SRFI should encode the characters which allow files to be exchanged between the contemporary platforms without transcoding their path names. That bothers my notions of idealistic design, but I'm willing to compromise. Note, however, that transcoding (renaming) path names might still be necessary when exchanging between platforms other than the prevalent ones. I tried to make this SRFI, and its companion, SRFI 104, able to easily transcode path names in the event platforms which have incompatible sets of allowable path name characters are desired to be used. However, one might say, non-prevalent platforms might have a notion of naming persistent objects so different from this SRFI's assumptions that trying to take them into consideration is too speculative to not just go with the current flow. > 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. I think I've been convinced that I agree this SRFI should specify a set of characters which is encoded and therefore a set which is not encoded. Just to mention it, I had been assuming it was better to leave this to a more informal convention or to another SRFI than to require a set which might (hopefully) not be applicable in the future, or which might not be applicable to some platforms now, and that because transcoding path names of the nature of current SRFI 103, assisted by current SRFI 104, is relatively easy, it was okay to leave it to other conventions. [------------------------------------------------------------------------------] > 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? The point is that there's an ordering which implementations, which want the freedom to deal with the versioning in different ways, can refer to when they might say something like: "This implementation has such and such opinion of versioning support, and when it processes imports, it will attempt to handle version constraints by choosing the first-ordered matching library file, according to SRFI 103's ordering, which matches the first-processed import clause, according to the particular way this implementation processes import clauses and deals with separately-compiled libraries' assumptions about what versions they were compiled against." Or another implementation might say: "This implementation likes supporting versioning more than others, so it goes to greater efforts to help you use versioning, and it does this in such and such ways which involve the ordering SRFI 103 offers." Yeah, that's a mouth- and head-full to consider when trying to use all implementations which differ in multiple ways even though they refer to SRFI 103's ordering -- but I'm trying to support both sides of people who don't like the versioning and people who do. I personally don't care very much about this SRFI's ordering or versions support. I thought it was a step towards supporting my goal of supporting portability with people who want versioning and people who don't. I personally have no problem ditching it. But I'll be left wondering why people who do not like versioning can't work with people who do. > 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'm individually okay with dropping versions. But I want to make clear I'm still not entirely convinced it should be dropped and that I can see why some people desire versioning to be in import clauses' library references. As I said above, I have a few libraries I've put versions in their names and referenced them with version constraints because not all the versions of the libraries will work. If implementations can at least guarantee they won't use libraries which violate the version constraints, then why shouldn't some people be able to use that portably? Additionally, if multiple versions of libraries exist, which I don't think we should ignore that reality, then there might be a program A which cannot use the same version of a library as program B, and you want to be able to run both programs on the same computer. Isn't that a reasonable thing to move towards supporting? You can accomplish that by making the search paths used by each program be differently configured, but that's a big hassle because it involves additional actions to be managed. SRFI 103 is designed to support both a one-to-one mapping of library file paths to library names and to support having multiple versions of a library be located in the already-configured-don't-have-to-reconfigure search paths, which means probably in the same directory. Both these are accomplished by requiring library files' paths to exactly represent their contained library, and therefore be single-library-only and always contain a (possible) version in the file name. [------------------------------------------------------------------------------] > 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. In some cases what I believe is your desired scheme for multiple libraries per file could reduce the number of files, but at the expense of losing the ability to one-to-one map a library file path to a library name, and at the expense of being able to place "main" files in the same directory as their related files, when you definitely want the related files separated from each other and all in the same directory. With multiple libraries possible per file and without the implicit file name, for a library whose name is only the shared name prefix of related sub-libraries with the same name prefix but longer names, and these sub-libraries are desired to be organized as separate files in a directory, the file for that library must unavoidably be placed outside the directory collection of the other files in its conceptual collection. It's my perspective that the ability to one-to-one map a library file path to a library name, and the ability to place "main" files in the same directory as their related files, is worth not supporting multiple-library files as the portable conformance to this SRFI. I recognize that implicit file names increase the number of possible file locations which might be examined in order to locate a library, but it increases it differently, and I think no worse, than the multiple-libraries per file scheme; and it also gains the ability to one-to-one map a library file path to a library name, and the ability to have implicit file names. Multiple libraries per file has an I-don't-see-why-it's-better possibilities-growth nature, and it loses that mapping ability. With the current draft of SRFI 103, the number of paths where a library reference's file might be satisfied from is: (* 4 number-of-search-paths) because for each search path, a library's file might be located at four possible sub-paths: 1) no implicit file name and no implementation-specific file name extension, 2) no implicit file name and an implementation-specific file name extension, 3) an implicit file name and no implementation-specific file name extension, and 4) an implicit file name and an implementation-specific file name extension. With multiple libraries per file as per Larceny's current support (IIUC), with versioning totally ignored, and with an optional implementation-specific file name extension, and without implicit file names, the number of possibilities where a library reference's file might be satisfied from is: (* 2 number-of-library-name-symbols number-of-search-paths) because for each search path, a library's file might be located at as many sub-paths as there are symbols in the named library, multiplied by the possibility of being at an implementation-specific file or not. Which for libraries with more than 2 symbols in their name, is larger than the number of possibilities for SRFI 103 as it currently is. If the multiple-libraries-per-file scheme didn't also have implementation-specific file name extensions, it would be: (* number-of-library-name-symbols number-of-search-paths) which for libraries with more than 4 symbols in their name, is larger than the number of possibilities for SRFI 103 as it currently is. You might say: but in practice, libraries with names that long or longer will not be common, and I'd mostly agree. But then I'll say: that also in practice, the difference between the numbers of possibilities of the two schemes is quite small (because of the common lengths of library names), and so if there are additional useful properties (i.e., the one-to-one mapping and the files-in-the-same-directory) which one has and the other does not, then the one with those properties should be the portable convention. [------------------------------------------------------------------------------] > 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. I hope I've explained why I think implicit file names aren't that bad and explained that I think sacrificing (in the context of current portability) multiple-library files is better in order to support a one-to-one mapping and to support files-in-the-same-directory. I hope my previous posts also help explain why I think implicit file names are desirable enough to support. I do not want the implications of SRFI 103 to outlaw multiple files per library, but to make its standard for portability involve only library file paths which exactly represent library names and so involve only single-library files. I imagine one of the main points of your response might be: why is a one-to-one mapping of library file paths to library names so important. I'm ready to engage that topic, and whatever else you think is appropriate, next, after I'm recharged. -- : Derick ----------------------------------------------------------------