[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 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.)