From: Anton van Straaten <anton at appsolutions.com>
Subject: Re: [r6rs-discuss] hello.0.4.2.sls vs. hello-0.4.2.sls
Date: Thu, 28 Jun 2007 17:29:26 -0400
> AndrevanTonder wrote:
> > But why is r6rs even wasting its time with these appendices?
> >
> > It seems as if r6rs is simply adding cruft upon cruft for no
> > better reason than that someone did the admittedly hard work
> > of thinking stuff up and writing stuff down and cannot now
> > bring themselves to discard it.
>
> That is not even a minor consideration here. In the case of the library
> to file mapping, there was some concern amongst the editors that without
> some recommendations in this area, implementations will diverge
> unnecessarily, and there will be no portable way for programs or
> programmers to map libraries to files.
IMHO, if the editors really concern about that, R6RS should *define*
the mapping; either limiting the identifiers for library names
so that they can be mapped to pathnames straightforwardly, or
provide a standard escaping rules.
If the editors think that's too much for R6RS, or we don't have
time to get it formally, then just drop the pathname mapping stuff,
and create a SRFI that defines the mapping and/or rules of namings.
The position of "recommendation" of the current draft is very
ambiguous; it is too vague to be taken as some sort of spec,
yet being in the standard document (even in appendix) it sounds
like it has some authority.
> Other appendices, like scripts, are not considered appropriate for the
> language specification proper, but there's nevertheless benefit in
> having a standard that's more consistently usable across implementations
> than SRFIs tend to be for these sorts of purposes.
I value SRFIs much higher. Although their quality largely vary,
there are ones that have been supported by large part of communities,
adopted by most implementations, and depended on by lots of
practical applications. That gives very strong incentive for
the new authors to follow such SRFIs even they are not in
"the standard". A SRFI for library naming convention and file
mapping seems perfectly OK to me, and would work just as other
mainstream SRFIs.
I expect the trend goes on. Even after R6RS, I expect that
most practical libraries and applications will say "comforms
R6RS, SRFI-n, and m; requires SRFI-x, y, and z". Trying to
cover as many things as possible by RnRS alone seems a wrong
attitude.
--shiro
Received on Thu Jun 28 2007 - 20:09:47 UTC