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 Sun, 2010-01-03 at 05:23 +0100, GÃran Weinholt wrote: > Derick Eddington <derick.eddington@xxxxxxxxx> writes: > > > Thank you for the feedback. > > > > On Fri, 2009-12-25 at 20:11 +0100, GÃran Weinholt wrote: > >> Derick Eddington <derick.eddington@xxxxxxxxx> 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 ----------------------------------------------------------------