On Sep 26, 2009, at 4:20 AM, William D Clinger wrote:

> I haven't had time to read this draft SRFI carefully,
> but I want to report several problems that I perceived
> during my first quick reading:
>
> 1. Treatment of versioning.
> 2. Ignoring all contents after the first datum.
> 3. Failure to specify which characters are encoded.
> 4. Specification of ordering but not matching.
> 5. Implicit file names.
>
> 1. Treatment of versioning.

I agree that R6RS versioning should be dropped from this
SRFI (though I have not read the text that I just snipped).

> 2. Ignoring all contents after the first datum.
>
> Taken literally, that is a recipe for disaster.  For
> example, the R6RS permits implementations to extend
> the lexical syntax of Scheme with a datum of the form
> #!fold-case or #!larceny or similar, and many systems
> have added such extensions.  Requiring all contents
> that follow a #!fold-case datum to be discarded is
> silly.

Taken literally, yes, but #!larceny or whatever is not
something you'd put in a library intended for running
under multiple implementations.

> Requiring all contents to be discarded following the
> first library is silly as well.  As demonstrated by
> Larceny, allowing multiple libraries within a single
> file reduces clutter.  I am not going to argue that
> this SRFI should require implementations to support
> multiple libraries within a file, but *requiring*
> implementations to discard all but the first library
> within a file serves no purpose other than to ensure
> that Larceny will not support this SRFI.

I'm sure this is not the intent.

> This SRFI should state that files conforming to this
> SRFI must have only one library per file.  This SRFI
> should not require implementations to ignore all but
> the first library in a file.

There are systems that conform to this SRFI and there
are libraries that conform to this SRFI.  If someone
puts multiple libraries in a file, then that's outside
of this SRFI anyways (and the file should probably have
an implementation extension as well in that case).
Besides, implementation-specific files need not contain
R6RS libraries at all.  A PLT file for example might
contain a PLT module, but a plain vanilla library file
must be something that all implementations understand
and that's a single R6RS library.

So, I don't know what changes you're asking for here.

> 3. Failure to specify which characters are encoded.

This is already under discussion.

> 4. Specification of ordering but not matching.
>
> I don't even pretend to understand this issue, but
> what is the point of specifying a detailed ordering
> "as the precedence for choosing a match" if the actual
> matching is going to be implementation-dependent?
>
> One thing I *do* understand is that the R6RS
> pseudo-semantics for versions is part of the problem
> here.  This SRFI would do better to drop versions
> altogether, as was explicitly urged by six voters
> as one of the well-informed reasons they gave for
> voting against ratification of the R6RS in the form
> that was, unfortunately, approved.

I agree that versioning should be dropped and if there
are any unnecessary ordering specifications, we should
inspect them then.

> 5. Implicit file names.

This is already under discussion and I agree that they
should be dropped (but not for the reasons I just
snipped).