Re: unbroken naming conventions William D Clinger (22 Jul 2008 18:17 UTC)
Re: unbroken naming conventions Abdulaziz Ghuloum (22 Jul 2008 18:29 UTC)
Re: unbroken naming conventions David Van Horn (22 Jul 2008 18:46 UTC)
Re: unbroken naming conventions Abdulaziz Ghuloum (22 Jul 2008 18:58 UTC)
Re: unbroken naming conventions Elf (22 Jul 2008 20:13 UTC)

Re: unbroken naming conventions William D Clinger 22 Jul 2008 18:17 UTC

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