Abdulaziz Ghuloum wrote:
> 1. The naming convention promoted by this SRFI author is incompatible
> with R6RS.
>
> 2. The author of the SRFI rejects one strawman alternative on the ground
> that it violates the *recommendation* of the R6RS, and because it cause
> some ugliness ...
>
> So, I am to break *conformance* with R6RS because of what exactly?
> Because there exists another naming convention that happened to violate
> the *recommendation* of R6RS?  I would rather violate the recommendation
> than violate the requirement.  Or better yet, I would rater adopt some
> third convention that satisfies both.
>
> Now I have previously urged Dave to reconsider the naming convention
> before publishing this SRFI so that we don't get into a bike shed
> argument about `Oh but I like these names' or `I really hate those
> names'  (which is what this thread may degenerate into unfortunately).
> My position here is not about liking or hating any specific naming
> convention.  My position is simple: I am not going to break conformance
> with R6RS just because Dave Van Horn likes to use unsigned exact
> integers instead of identifiers for his library names.
>
> I think my point is clear, and I'll leave it at that.

I am open to other suggestions for the naming convention.  In
particular, I think srfi-N is good alternative to the current
specification.  It trades the property that all SRFI libraries live
within the `srfi' library space for the property that library names
strictly conform to R6RS.

On the other hand, nobody has made an argument for why strict
conformance to R6RS is compelling.  What justifies the severe
restriction on the set of library names?  If the R6RS restriction has no
justification, I am not inclined to conform to it.  If I were to change
the document at this point, the rationale would be "because I like
R6RS," which I hope Aziz wouldn't find satisfying.

The rationale for the current naming scheme is that it is hierarchical,
fair, unique, and includes mnemonics.  By using natural numbers, it
reflects the structure of the SRFI process and is a natural fit for
indexing SRFI libraries.  But R6RS disallows this.  The burden should be
on R6RS to justify the restriction.  If it's compelling, it's worth
changing this SRFI.  If it's not, it's not.  (The title of Aziz's post
is misleading: this naming convention is perfectly consistent; more
accurate would be to say R6RS is broken in that it doesn't support a
natural indexing of perhaps the largest widely supported set of Scheme
libraries.)

David