Email list hosting service & mailing list manager

Plan for revising Derick Eddington (07 Oct 2009 05:51 UTC)
Re: Plan for revising Vitaly Magerya (07 Oct 2009 08:35 UTC)
Re: Plan for revising Derick Eddington (07 Oct 2009 10:35 UTC)
Re: Plan for revising Abdulaziz Ghuloum (07 Oct 2009 12:13 UTC)

Re: Plan for revising Abdulaziz Ghuloum 07 Oct 2009 12:05 UTC

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.


> 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?)  I think it's fine that if a library name does not
map to a file name accepted by some who-knows-what file system
or operating system, too bad, pick a different name or curse
the system.  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.

> Implicit file name prefix is "main".  Avoid conflicts by mapping
> (--- main) to "---/_main.sls", (--- _main) to "---/__main.sls", and so
> on.


> Ordering of an implicit file name match relative to a non-implicit
> file
> name match is not specified.


> Rephrase to state that files conforming to this SRFI must have only
> one
> library per file.  (Thus allowing implementations which support this
> SRFI to also support files which do not conform to this SRFI.)


> Rephrase to state that cross-implementation files, i.e. those
> without an
> implementation-specific file name extension, must contain the
> library as
> a standard library form as the first syntactic datum which the
> standard
> read procedure would return.

This sounds fine by me.  I'd like to know Will's opinion.

> 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.

> (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 but I don't think you
should say much (or anything) about what goes in implementation-specific



> Remove the restriction that search paths must be independent.  (We
> haven't discussed this.  Thinking about it more, I don't think there
> is
> enough justification for this restriction.)


I believe these changes will make a much better SRFI.  Thanks for all
the effort.