This page is part of the web mail archives of SRFI 97 from before July 7th, 2015. The new archives for SRFI 97 contain all messages, not just those from before July 7th, 2015.
Matthew Flatt wrote: > Beware that ":" isn't normally allowed in a file/directory name under > Windows. Although the mapping between library names and files (if any) > is up to an implementation, it might be simpler to avoid characters > that tend to be special. The real problem here is that "the mapping between library names and files (if any) is up to an implementation." Indeed, R6RS-conforming implementations are allowed to map every nonstandard library name to /dev/null, and to complain that /dev/null doesn't contain any code for the library. Although that may seem far-fetched, we are likely to see implementations of the R6RS that disallow certain library names that do not easily map to file names. In the current version of Larceny, for example, top-level R6RS programs can define libraries with any R6RS-conforming name, but libraries whose names contain strange characters (from the file system's point of view) must be defined within the same file that contains the top-level program. David Van Horn wrote: > Is it important to the implementors that the naming convention avoid > such characters? Not really, because implementors can easily adapt their chosen file-naming conventions to deal with any special characters that might be chosen by SRFI 97. If SRFI 97 were to use the (srfi :6) naming convention, for example, then we would certainly adjust Larceny's mapping from library names to file names so SRFI libraries that use the SRFI naming convention could be defined in separate files, even on Windows. The real problem is with the R6RS: Mappings from library names to file names are completely implementation-dependent. This creates a problem for public repositories of SRFI reference implementations: What naming convention should they use? As it is, every public repository of SRFI code and other ERR5RS/R6RS libraries is likely to use a different naming convention. That means we're going to have to write m*n renaming scripts, where m is the number of public repositories and n is the number of R6RS-compatible implementations. The (srfi :6) naming convention wouldn't make that any worse than it already is. Will