[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Broken naming convention
Abdulaziz Ghuloum wrote:
1. The naming convention promoted by this SRFI author is incompatible
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