On Wed, 2009-10-07 at 15:05 +0300, Abdulaziz Ghuloum wrote:
> On Oct 7, 2009, at 8:51 AM, Derick Eddington wrote:
>
> > I'm going to revise this SRFI as follows, unless someone thinks
> > something should be discussed further.
> >
> > Remove all design related to versioning.  Add a comment about why
> > versions are not in file names: it's too controversial.
>
> Good.
>
> > Require encoding the set of characters: #\%, #\., #\x0 to #\x1F, #\<,
> > #\>, #\:, #\", #\/, #\\, #\|, #\?, and #\*.  Require not encoding all
> > other characters.
>
> I think this is fine though the list looks pretty arbitrary.
> (for example, why are #\{, #\}, #\[, #\], #\(, and #\) not
> encoded?)

#\%, #\., #\/, and #\\ are because thi SRFI use them specially.  They
need to be encoded to avoid conflict.

#\x0 to #\x1F, #\<, #\>, #\:, #\", #\/, #\\, #\|, #\?, and #\* are
because Window say so (i.e. they are not allowed on Window).

No other character are encoded because prevalent file system allow all
other character.  The only reason for encoding other i because of shell,
but there are so many different shell with differing nuisance character,
and modern shell have auto-completion which doe escaping, so the
justification for encoding other character i not much nor clear.

> If you have reasons for picking these chars for
> encoding and not others, you probably need to say why, in a
> footnote or endnote perhaps.

Yeah, I wa planning on saying why it' these character.

> > State that implementations must support implementation-specific files
> > with the same format as cross-implementation files, but
> > implementations
> > may also support other formats.
>
> The "must" should be "may".  I can imagine an implementation that does
> not wanting to provide implementation-specific files.

Okay.

> > (Because of other parts of this SRFI,
> > there are implied restrictions that implementation-specific files
> > conforming to this SRFI must have only one library per file and that
> > such files' path name must represent the name of the contained library
> > (excluding the version).)
>
> I don't know what you're referring to exactly

If thi SRFI say that file conforming to thi SRFI must have only one
library, and say that the path name of file correspond to the name of
the contained library, and say that implementation-specific file are
part of thi SRFI, then, therefore, implementation-specific file
conforming to thi SRFI must contain a library and only one library, and
the name of such file correspond to the path name of the contained
library.

> but I don't think you
> should say much (or anything) about what goes in implementation-specific
> files.

I thought about thi, and I think thi SRFI should imply (or maybe state)
that implementation-specific file conforming to thi SRFI must have only
one library, and imply (or maybe state) that the path name of such file
correspond to the name of the contained library, and thi SRFI should say
that i implementation support implementation-specific file then they
must support implementation-specific file with the same format a
cross-implementation file.

The reason thi need to be i because there need to be a specified
portable format for implementation-specific file because many use of
such file are only for dealing with implementation-specific binding but
are otherwise not implementation-specific, and I think it' obviou thi
format should be the same a that for cross-implementation file.

Otherwise, if there wa not a specified portable format for
implementation-specific file, peoples (heeheehee) would not be able to
refer to thi SRFI to know how to make implementation-specific file and
they would have to find (hoping it exist) some other
implementation-specific document describing the format supported for
implementation-specific file.

> > Rename SCHEME_LIBRARY_SEARCH_PATHS to SCHEME_LIBRARY_PATHS.
>
> SCHEME_LIBRARY_PATH, yes. :-)

Bah humbug.  How do y'all like my missing last "s"? :)

--
: Derick
----------------------------------------------------------------