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

Re: five problems with this draft SRFI

This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.

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

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