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-08 at 13:42 -0500, R. Kent Dybvig wrote: > The cause of our differing views on encoding might be a difference in > perspective regarding the purpose of library names. That's definitely it, which I'd not known. Thank you for helping explore this. I think I have a pretty good justification of why my perspective is better, explained throughout the below. > 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, In my view, library names specify libraries, which are conceptually different than files even if they're sometimes contained in files, and they are for specifying module interfacing, and they are not dependent on any particular data storage models. I consider that a major improvement over specifying libraries and module interfacing with platform-specific file names. They have compound structure because it's useful, not because they're a representation of a file name. File names should serve the higher purpose of library names. If the desired name for a library, made by a Windows user, includes the Windows-disallowed characters/names, they should be able to use that name. In 100 years when Windows and unixes are long gone, I want that library to be named as desired, and without the hassle of renaming every occurrence of it at some future time. Also, until Windows dies, Windows users should be able to choose the most appropriate library names so we can all benefit from not being confused/frustrated by inappropriate names. I look forward to the future of significantly different OSs and data storage models. I don't want libraries which should have been named the most appropriately to not be because we viewed library names as less than they should be because of the influence of outdated OSs (unixes included). > 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. (... but we're specifying libraries, not files.) Here's an example of a need for supporting arbitrary symbols. I've had an idea for customizing the lexical syntax. If an unknown #!symbol is read, (eval 'handler (environment `(acme custom-handlers ,symbol))) is done at read time to get the handler for the non-standard lexical syntax which follows. Ignoring what I haven't explained and all the details I haven't fully explored, such use of dynamic library names in general seems to clearly be a good reason for supporting arbitrary symbols. I also have another idea which could take advantage of that method of dynamically loading. Clients must be able to give any symbol, and a third party may be responsible for providing the library; so, for the files of all such possible libraries to be auto-loadable on Windows, the special mapping of Windows-disallowed file names is necessary. > > 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. The SRFI is tied to unixes and Windows only so it can define a mapping of library names to those OSs' file names. The compound library names correspond decently with those OSs' file systems, but I've never viewed library names as tied to any platform. File names specify things which are tied to the OS level. Libraries are quite often not tied to any OS, so their names should reflect that. There very well may be OSs with a totally different data storage system, on which our libraries will be used. So, I can't support allowing our libraries' names to be determined by the OSs we're using now, when the appropriate library names should have been used and are resolvable in other OSs' storage systems in a perfect way. > > 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. If you want library names to be a representation of file names, I can understand. (But I strongly don't want them to be that.) > Your proposed workaround is > cumbersome I agree it's not as super-minimal, but I don't think it's cumbersome with one site-wide "rc" login environment-setup script used by multiple users and with users already having collections of other libraries in their home directories. > and not very unixy. IMO, that's often a good thing. Windows is certainly worse, but I'm not a fan of unix either (and I use Linux predominately). > > 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. If you want to override the SRFI to catch such library names, you can also map them to a file name without the SRFI's encoding (maybe just the "absolute path" first symbol). Same for ~. In conclusion, I don't see why considering library names as representations of contemporary file names is proper, and I don't see why it outweighs the importance of abstract unrestricted library names. -- : Derick ----------------------------------------------------------------