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.
> > But there's already ambiguity inherent in the > > SRFI 103 mechanism... > > I've been aware of that. Programmatically-processed library-file names > need to be relative to their searched directory, which is a natural > approach. SRFI 104's specification of 'library-file-name-info' mentions > this. E.g., when programmatically working with collections of library > files, you change the current directory to searched directories and then > work with the recursively-listed file names. I do that often. I don't understand what you're getting at. If you find the file via the library name and the search path, there's no problem with either encoded or unencoded pathnames, but you're talking about going the other way. If you find the file via some other mechanism, e.g., listing the directories specified in the search path, ambiguities can occur with both encoded and unencoded pathnames. The ambiguity arises if one directory in the search path is a subpath of another or if two of the directories link to the same place. > I don't want the SRFI to inhibit it. I meant I'm not sure it's the > SRFI's place to specify or require the special handling. There's nothing special about unencoded pathnames or about requiring implementations to look first for a file named by the unencoded pathname. On the other hand, encoded pathnames _are_ special. If you don't want to require special handling, don't require encoding. As you suggest, you could just allow implementations to look first for a file named by the unencoded pathname without requiring them to do so. It's not as useful, but at least it doesn't prohibit implementations from supporting access to arbitrary files. > > With the current SRFI draft, r6rs-lib can and will be used for > > multiple-library files as well. > > The intent is that "r6rs-lib" will not. Yet, unless I missed it, SRFI 103 does not specify that implementations must reject files that contain multiple libraries, only that a conforming file contains one library and that a conforming implementation must support such files. That's a good thing, since it allows conforming implementations the freedom to support files that don't conform, for whatever reasons. Even if you were to require implementations claiming to support SRFI 103 to reject files containing multiple libraries or even forms other than library forms (which I hope you do not do), there's no way you can prevent them from being created and used in nonconforming implementations. > How do you think multiple-R6RS-library files should be handled? I would not try to standardize on that at this point. > Why should the SRFI's R6RS library file format get "Scheme library > source", when other formats or dialects are also Scheme library > sources? Why should the R6RS library file format _not_ get sls, which is nice and short? And if it does, why can't other formats or dialects use the same extension? You don't really need for arbitrary files using the sls (or any other) extension to conform, just for the ones you happen to find via the search path and want to manipulate in certain ways. Yes, by choosing an unusually specific and long name like r6rs-lib, you can be fairly sure no one will use the extension for some other purpose, but I think an eight-character extension is too high a price to pay. I think I'm not alone, since most of the filename extensions people have chosen over the years range from one to three characters in length. On the other hand, if you do require (against my advice) to require SRFI 103 implementations to reject files containing something other than a conforming library, I hope you keep the r6rs-lib extension and limit the damage to files with an r6rs-lib extension so that others can use .sls files in those implementations without such a restriction. BTW, I don't think I saw in the discussion what you intend for the SRFI to do about the case of the letters in a library name. Windows filesystems in are case-insensitive, as are MacOS X filesystems (at least optionally). So what happens if one has two libraries whose names differ only by case? I do so hope that you don't end up requiring encoding of either upper- or lower-case letters, but that seems to be the only solution that would be compatible with your perspective. Kent