On Sun, 2010-01-03 at 05:23 +0100, Göran Weinholt wrote:
> Derick Eddington <xxxxxx@gmail.com> writes:
>
> > Thank you for the feedback.
> >
> > On Fri, 2009-12-25 at 20:11 +0100, Göran Weinholt wrote:
> >> Derick Eddington <xxxxxx@gmail.com> writes:
> >>
> >> > The new revision of SRFI 103 changes the file name extension for R6RS
> >> > library files from .sls and .IMPL.sls to .r6rs-lib and .IMPL-r6rs-lib
> >>
> >> Why did you make this change,
> >
> > To support multiple Scheme dialects; and to support system-specific
> > files via a more useful general facility instead of a limited odd one;
> > and to not encode the #\. character; and to have the R6RS extension name
> > fit its purpose.
>
> I was under the impression that SRFI-103 would standardize an already
> widely implemented feature and specify all the little details that
> currently differ between implementations. But perhaps a different
> document will be necessary to accomplish that.

.sls and .SYS.sls are flawed and there is an objectively better design
which is very similar, so I cannot in good conscience support the
inferior design.  The new design has the same features: an extension
which describes the file type, and system-specific extensions.  I will
not support the old design just because a handful of people used it for
less than 2 years.  Systems already differ about whether or not they
support an implicit file name or multiple libraries per file, so this
SRFI is already involving aspects which are not the same across systems.
I'm the person who asked a few R6RS systems to support the .sls
and .SYS.sls extensions, and then a few less-popular systems followed.
That's how it became "widely" implemented, and I feel responsible.  If I
had thought more about it, I would have promoted the extensions design
SRFI 103 now has.

> I was going to reply to all your other points (nested file extensions?),

"Nested extensions" is indeed what I said.  I think it's clear what I
meant and that .SYS.sls has the same form as .tar.gz and that that's
semantically inconsistent.

> but I removed that portion of this email, because it was very tiresome.

I guess that implies it wasn't convincing.

> There's nothing wrong with .sls. It's not vague, it's precise.

I said "too vague", and I gave the objective reason why that is.  The
meaning of "Scheme" is not precise, therefor "Scheme library source" is
not precise.  "R6RS library" is precise.

> Nobody
> else uses it (I couldn't find it on filext.com and file-extensions.org),
> so it seems to be unique.

It may be currently unique according to those listings, but it is
objectively much more susceptible to someone else using it because there
are many possible "S.L.S." acronyms.  .r6rs-lib does not have that
problem.

> I just don't think you will convince many
> people to use .r6rs-lib. You will certainly not convince me to change
> until the implementations I use remove support for the old, and IMO
> better, file extension.

I gave objective technical reasons why the file name extensions design
has been improved (and it's still nearly the same).  I hope subjective
opinion is not as persuasive.

> If someone else wants to use .sls in a
> conflicting manner, then that should be their problem, not ours.

I think it's much better to have a design (which is very similar to the
old one) which naturally prevents such problems.

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