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 Mon, 2010-03-15 at 10:09 -0400, R. Kent Dybvig wrote: > Indeed. This is why an extension in Chez Scheme's list of extensions > includes the "." (if the programmer wants one). It would be great if the > SRFI would go the same way, so that I don't have to support both forms. Okay, I'll adopt that, with the restriction that "." occur only as the first character, to avoid the conflict mentioned in the current draft. (The SRFI previously encoded "." to avoid the conflict, and that was changed in favor of not encoding it, disallowing it in extensions, and using "system-ext" extensions instead of "system.ext".) > > However, it breaks mapping library-file names to library names, which > > has been one of my original goals for this SRFI, because, e.g., > > acme/a%3A%b.ext might be (acme a%3A%b) or (acme a:b), and > > foo/bar/zab.ext might be (foo/bar/zab), (foo bar/zab), (foo/bar zab), or > > (foo bar zab). Being able to programmatically manage/analyze > > collections of library files (as far as what's possible from knowing > > only library names) from only file-name listings has been important to > > me. > > I suppose the rationale for wanting this is in SRFI 104, but I haven't > looked at that SRFI yet. The Design section of SRFI 103 says: This SRFI supports files which each contain only one library. This supports one-to-one mapping library-file names to library names, which supports knowing what libraries are available and where they are located, from only file names. That is useful to humans reviewing/navigating collections of library files and is useful for programmatically working with library files without needing to read file contents (maybe the contents are accidentally malformed but the processing doesn't care, or maybe you don't have access to the files and are dealing with only a package manifest). SRFI 104 is intended to provide ready-made helpers for working with library files. > But there's already ambiguity inherent in the > SRFI 103 mechanism. If foo/bar/zab.ext is in /home/users/bob/libs, it > might already hold libraries (zab), (bar zab), (foo bar zab), (libs foo > bar zab), (bob libs foo bar zab), (users bob libs foo bar zab), or (home > users bob libs foo bar zab). If /u is a link to /home/users, it might also > name (u bob libs foo bar zab). Other links add other possibilities, and > you can't generally enumerate what they are because the links might exist > on external filesystems! 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'm not sure it's the SRFI's place to involve special handling of > > (~ ---) or (/ ---), (c:/ ---), etc. > > Perhaps not, but I'm sure it's my place not to implement a SRFI that > inhibits access to such files. 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. Maybe there should be some brief language saying that systems may have special handling of library names they consider special? I'm seeing this issue as one of those things which should be intentionally left-out because it complicates the specification with exceptional rules and is so dependent on particular platforms, and so should be left to informal conventions. But I'm open to changing my mind if it can be included smoothly (I know that's vague, I need a clearer idea of how that could be done). > ["sls"] has been the extension of choice for r6rs libraries, I feel largely responsible for that, and after concluding that "r6rs-lib" is superior, I feel responsible for rectifying the situation. > and it's more pleasant than r6rs-lib. ("More pleasant" is subjective.) > > "sls" is currently being used for single-library and multiple-library > > files. If "sls" (or any extension) is used for different types/formats, > > we can't programmatically process files based on their name extensions > > because they could be something unknown. "r6rs-lib" says precisely what > > a file is: one R6RS library. "thing-libs" means a file containing > > multiple libraries of dialect Thing. > > 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. > While the SRFI says an implementation > must support files with an r6rs-lib extension that have a single library > as the first datum, it doesn't say that an implementation must not support > files with an r6rs-lib extension that contain multiple library forms. The current draft says: "files conforming to this SRFI have one library per file", and "extensions used for library-file names are encouraged to precisely and unambiguously denote file types". I think you're right, for my intent for "r6rs-lib", I should require that "r6rs-lib" files can have only one library. > If > it did, I'd be trying to change that, because I see no reason to disallow > programmers from putting helper libraries in the same file as the library > directly imported from a program. I don't want to inhibit systems from supporting multiple-library files. For specification/implementation simplicity and for mapping library-file names to library names, this SRFI specifies single-library file formats. Multiple-library files just won't conform to that aspect. I want different file formats to have different extensions, so multiple-R6RS-library files might use "r6rs-libs". How do you think multiple-R6RS-library files should be handled? Like Larceny, or something else? E.g., not a bottom-up tree search like Larceny, but something like: if multiple libraries are in a file located according to this SRFI's current method they're all loaded; which means a primary library can have its helpers occur first and they'll be available for it, but helpers cannot be located if imported from a library outside the file because they're not in a file which can be found via their library name? > There's no reason you can't just change "r6rs-lib" to "sls" and make > exactly the same statement. That doesn't address my other reasons for choosing "r6rs-lib". Why should the SRFI's R6RS library file format get "Scheme library source", when other formats or dialects are also Scheme library sources? What extensions do you think other formats/dialects should use? (If they don't use distinct ones, there are problems and they're not nearly as useful, as mentioned in the current draft.) When the SRFI previously used "sls", I felt compelled to name the environment variables with "R6RS_" prefixes, to avoid having other dialects using "sls" interfere with locating the SRFI's "sls" files. But that's not as useful as one searched-directories configuration which can work for multiple formats/dialects, and I was given the impression that people want the environment variables named as "SCHEME_". -- : Derick ----------------------------------------------------------------