[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: unbroken naming conventions

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

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

The (srfi :6) naming convention wouldn't make that any
worse than it already is.