I'm testing the waters of the Common Lisp community's willingness to break with the past. The ANSI CL Standard [*] is often touted as a triumph and a great advantage for the Lisp community, and rightly so, I think: it is the result of years of experience of Lisp vendors and developers, and by and large the standardized functionality is harmonious, well-thought-through and consistent.

I've mentioned here before some unintended consequences of the standard, such as arrays specialized to hold nothing, and type upgrading being required to solve the halting problem; while working on a language extension that the standard was careful to permit implementors, I stumbled across another such oddity.

The sequence type in CL is carefully specified not to be necessarily just (or vector list); implementations are permitted to offer non-standard sequence types. However, while tidying up one corner case in the make-sequence function, I believe the standardizers overreached and created another such corner case: forbidding implementations from allowing natural extensions to make-sequence.

Rather than just ignoring this issue, though, or putting it up on the CLiki page, I wrote it up properly and submitted it to the Common Lisp Document Repository where it's been accepted as CDR 3. That's not really to say that I think the CDR has more visibility than CLiki – truth be told, it seems to have somewhat less, at least judging by the mailing list subscriptions. However, maybe the implied permanence of the CDR will encourage more users to demand that their implementors pay attention to it, or the implementors themselves to follow the documents and adopt sensible recommendations.

Why would an implementor support a CDR that explicitly involves no changes to the implementation? Well, one issue is that it warns users that some of the corner cases might change in behaviour (I give an example in the CDR document); but more importantly it can be a statement of intent: a declaration that bugs in the standard will be treated as bugs, and that new material can supersede old where the cost to users and implementors is low.

[*] Don't follow that link; it's just the most authoritative place I can find. Go to the HyperSpec instead.