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.
> No, because file-name strings are inherently platform specific. Library > names (for portable libraries) are supposed to be completely abstracted > from any platform, and that's why I'm convinced allowing them to be > determined by the flaws of platforms is unacceptable. I don't want to push the analogy too far, but library names (like strings) are platform independent as long as they are internal to a Scheme system. They become platform dependent (like strings naming files) as soon as you try to tie them to a file system, which is what the SRFI is all about. > That's not portable and SRFI 103's purpose is supposed to be portability > across prevalent OSs, so it's not supposed to be concerned with that. > That can be portably accomplished with libraries named like > (personal ---) and (for unixes) placing the "personal" directories in > home directories and doing > SCHEME_LIB_PATH=$HOME/wherever:$SCHEME_LIB_PATH. The SRFI's purpose is portability, but it shouldn't prevent the naming of other files in import forms. In particular, it shouldn't prevent a programmer from (unportably) specifying ~/.myappinit, but the proposed encoding requirement does just that. Your proposed workaround is cumbersome and not very unixy. (BTW, I'm thinking of creating a SRFI that specifies that ~ be treated as it is by most shells, at which point ~/.myappinit will become portable, in the sense that anything defined in a SRFI and not in a revised report or standard is portable.) > Actually, the joining of relative library-file names with > searched-directory names is what prevents that (assuming I'm > understanding what you mean). Without the encoding, a library named > (/ foo), with SCHEME_LIB_PATH=/exploit, will be found > at /exploit///foo.ext. That's true with the SRFI as defined, but it is common to ignore search paths when absolute pathnames are used, so (/ foo) should be found in / and (c:/ foo) under Windows should be found in c:/ no matter what the search path contains. The cause of our differing views on encoding might be a difference in perspective regarding the purpose of library names. From my perspective, library names serve as an abstract way of specifying file names, which is, in fact, one reason why they are structured as they are. There shouldn't be any restriction on the file names we can specify with a library name, and there's no need to be able to specify file names that don't exist. For libraries intended to be used on two or more platforms, there's no need to be able to specify file names that don't exist on both. Kent